ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antoine Levy-Lambert <>
Subject Re: Ant source structure and ant*.jar build products
Date Fri, 14 May 2010 22:56:57 GMT
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).
> 2. Use a particular classpath, including binary outputs of upstream
> roots plus any third-party library dependencies.
> 3. Produce the contents of one JAR in the distribution.
> 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.



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

View raw message