ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen McConnell" <>
Subject RE: debian packaging related tasks - sandboxable?
Date Fri, 25 May 2007 16:53:17 GMT

> -----Original Message-----
> From: Bruce Atherton [] 
> 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.


View raw message