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

Reply via email to