On 2010-05-14, Jesse Glick <jesse.gl...@oracle.com> wrote: > Would be much easier to manage (and possibly more friendly to IDEs) if > classes were split into several physical source roots.
I'm not a fan of such a source file set up but wouldn't block it either. > I would also like a clear explanation of what ant-nodeps.jar is > supposed to be, as distinct from ant.jar. Initially there was ant.jar and ant-optional.jar with ant.jar holding the core and all tasks listed as "core tasks" while ant-optional.jar contained all tasks listed as "optional tasks". There has never been a clear rule as to what task should be put into optional and which into core if the task didn't depend on an external library (if it did, it was optional). Then we decided to split ant-optional.jar to help people to manage their classpath for the optional tasks that do require an external library. ant-nodeps.jar is the bunch of tasks that used to ship in ant-optional.jar but didn't have any external dependencies. If you wanted to merge ant.jar with ant-nodeps.jar (which would be fine with me) we should probably move all tasks included from optional to core inside the manual as well since the distinction would make even less sense after that. > 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), I think we already do the later implicitly. > or move the corresponding tasks to an antlib if nonfree JARs are > involved. Even though I like the idea, I'm afraid we won't manage to split out Antlibs that stood any chance of getting three +1s when it comes to a release. We've tried so for VSS and some other of the SCM tasks and failed. I doubt we'd be able to manage a JAI or NetREXX Antlib. > But perhaps there are special considerations here for Linux packagers. It's more about "historical reasons". If we want to distribute the things that we can - legally and following ASF policies - we may still consider creating a leaner distribution without those libraries. Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
