ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Reilly <>
Subject Re: Ant source structure and ant*.jar build products
Date Sat, 15 May 2010 10:17:27 GMT
On Fri, May 14, 2010 at 11:56 PM, Antoine Levy-Lambert <> wrote:
> Hello Jesse,
> Jesse Glick wrote:
>> In relation to
>> <>:
>> Ironically enough, I find the Ant build script to be a poor example of
>> an Ant script. The system of compiling certain classes and not others
>> according to classpath availability, and then packing classes to
>> different JARs, is difficult to understand and debug, and it is too
>> easy to accidentally put a class in the wrong JAR.
>> Would be much easier to manage (and possibly more friendly to IDEs) if
>> classes were split into several physical source roots. Each root would:
>> 1. Compile all classes beneath it (if the root is compiled at all).
> +1
>> 2. Use a particular classpath, including binary outputs of upstream
>> roots plus any third-party library dependencies.
> +1
>> 3. Produce the contents of one JAR in the distribution.
> +1
>> What do other committers think about such a change? Is there some
>> advantage to having all (non-test) sources mixed together in one tree,
>> other than to provide an advanced demo of <selector>? (Since we are
>> using Subversion, losing file history after a move is no longer a
>> consideration.)
>> I would also like a clear explanation of what ant-nodeps.jar is
>> supposed to be, as distinct from ant.jar. Both include tasks that we
>> have always shipped and which do not need any third-party libraries.
>> So what's the difference? The include set seems to be rather
>> arbitrary. Some things that require newer Java Platform APIs are also
>> in there, which you would expect to be in their own ant-jdk5.jar or
>> ant-jdk6.jar.
> ant-nodeps.jar contains classes belonging to so-called optional tasks.
> There are some tasks such as for instance propertyfile which are only
> using the JDK and ant's own classes and are  categorized as optional
> tasks. In ant 1.5, there was just ant.jar and ant-optional.jar. When
> ant-optional.jar was broken up, the classes without any external, non
> ant, library dependencies were added to ant-nodeps.jar.
>> It also seems unpleasant to make parts of the build work only
>> conditionally. I think that for any third-party libraries needed by
>> the build, we should either include them in lib/optional in the
>> Subversion tree (or download from a well-known repository on demand),
>> or move the corresponding tasks to an antlib if nonfree JARs are
>> involved. But perhaps there are special considerations here for Linux
>> packagers.
> there is a problem with some libraries such as NetRexx or jai which have
> non BSD licenses. I think nearly all other dependencies can be
> downloaded using ant -f fetch.xml.
> I would not check in jars under lib/optional. I am not sure what we can
> do about NetRexx and jai. How to contact IBM to get them to publish the
> NetRexx jars to a public repository with a BSD license ? Same for
> Oracle-Sun concerning jai.

Yes, this is a problem.

> Regards,
> Antoine
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message