ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse Glick <jesse.gl...@oracle.com>
Subject Ant source structure and ant*.jar build products
Date Fri, 14 May 2010 18:08:34 GMT
In relation to <https://issues.apache.org/bugzilla/show_bug.cgi?id=49287>:

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: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message