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 Fri, 14 May 2010 20:00:16 GMT
Personally I think that there should be only one ant.jar file (as
was the case in ant 1.5 - well two)
and not loads of itty-bitty ones.


On Fri, May 14, 2010 at 7:08 PM, 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.
> 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.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message