On Fri, May 14, 2010 at 11:56 PM, Antoine Levy-Lambert <anto...@gmx.de> wrote: > 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.
Yes, this is a problem. Peter > > Regards, > > Antoine > > --------------------------------------------------------------------- > 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
