Hello Jesse,
Jesse Glick 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). +1 > > 2. Use a particular classpath, including binary outputs of upstream > roots plus any third-party library dependencies. > +1 > 3. Produce the contents of one JAR in the distribution. +1 > > 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. Regards, Antoine --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
