> -----Original Message----- > From: Bruce Atherton [mailto:[EMAIL PROTECTED] > What do people think about Ant supporting a way to install > and remove antlibs from the command line into a standard > antlib directory that is automatically added to the classpath > on startup? That would support the creation of separate > debian packages for individual antlibs. Installed antlibs > could be made automatically available to any build file.
This would change the classpath content used across any Ant build and would ultimately lead to conflicting classes. A better approach is to load required facilities into classloaders as close as possible to the source of the requirement. In the case of a task the classloader should be established relative to the task definition. In the case of a project the classloader should be established relative to a project definition. The only time you should be dropping down to ant wide extension is when you need to work around the absence of support for the above capabilities. I take care of more than a hundred project with lots of interdependencies. I don't use the ant command (except on a very small number of bootstrapping projects). Instead I use a build system [1] that handles automatic resolution of build sequencing, automatic creation of project classloaders, and automatic deployment of task-relative classloaders. This ensures minimal classpath pollution backed by all of the benefits of repository-based resource loading. But the real kicker for debian packages would be related to a custom repository that links a dabian package with a classloaders and for that you should be tracking the JSR 277 [2]work. Cheers, Steve. [1] http://www.dpml.net/util/depot [2] http://openjdk.java.net/projects/modules/
smime.p7s
Description: S/MIME cryptographic signature
