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.
Peter On Fri, May 14, 2010 at 7:08 PM, Jesse Glick <jesse.gl...@oracle.com> wrote: > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
