ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Splitting up optional.jar
Date Wed, 17 Jul 2002 17:17:15 GMT
On Wed, 17 Jul 2002, Steve Loughran wrote:

> 1. I understand why you are breaking it up by dependency, but IMO it should
> be broken up by functionality, and each jar can have its own dependencies
> (or not)

That's a good argument...

In my opinion ant-junit is just the ant 'adapter' for junit.jar ( which is
an external and well defined package ). 

Since <junit> won't work without junit.jar, I think it would be much 
better if the task would be included in junit.jar in the first place
( and maintained by junit people ). Same for bsf, etc.

I think 'by functionality' organisation should be used for most 
'standalone' or 'generic' tasks ( like ant-xml ), but 'by dependency'
should be used for all tasks that are very specific to a particular

ant-weblogic should have all tasks that are specific to weblogic,
while ant-jspc would be a good place for jsp-related tasks ( and
that may have a soft dependency on jasper, weblogic, resin, etc ).

> 2. we need ant version numbers in the jar titles, of course, to stop version
> confusion. The risk is we introduce a new bugrep "I am running ant1.7 but
> the task <DavPut> doesnt support the option authmode="liberty""; the cause
> being they have the ant1.6 version of this (hypothetical) task on the cpath.


And eventually have independent release cycle for 'task packages' - most 
of those can work very well in ant1.5, and it would be very valuable
for users to get updates and fixes for the current version instead of
waiting for 1.6 to get the whole thing.


> 3. we need a manifest to handle versions and dependencies; it could be
> the normal manifest, or it is our own XML descriptor.


With a very strong -1 on using (only ) a XML descriptor for things that 
are well-defined for the normal manifest - it is important that generic
tools are able to manipulate the jar.

So I think all dependency, version, etc should go to MANIFEST.
The task=classname should go in a properties file ( and I think
we should settle on a default location and name - like
 META-INF/ ). Everything else should go to the 
XML descriptor ( like docs, etc ).

It would be fine if all the information are put in the XML descriptor
as long as the packaging process will generate MANIFEST and from the XML.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message