ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject ClassLoaders ( was: Re: We need to stop the lies)
Date Mon, 25 Feb 2002 17:33:50 GMT
Based on the discussion so far, what I understand is:

- we agree some enhancements are needed to reduce the need to
put things in classpath and improve flexibility

- some people disagree with relying on ant/lib hierarchy.

- it seems that 'named' loaders are ok ( or nobody so far 
gave any argument against it ). By named loader I mean
a mechanism to define new loaders ( and their classpaths),
and a mechanism to use specific loader for different purposes
like taskdefs or task execution

- what we alleays knew - class loaders are tricky and 
multiple possible implementations are possible.

I would like to add one requirement to the mix:

- the loader solution should support 'embeded' usage of 
ant. For example, if ant is plugged into NetBeans or VAJ,
it should be possible for the IDE to plug in and provide
access to it's own implementation of loader ( which may
be backed by a non-file based repository, etc).
Or ant used inside tomcat should be able to use 
the tomcat class loader mechansims to locate extensions.

My proposal, as a first step ( to be implemented in ant1.5):

1. Add a mechanism to define ClassLoaders based on some classpaths and 
associate them with a name. I propose an extension to the 
<classpath>, for example 'loaderId'.
Alternatively, the classpath id can be used to automatically 
construct ClassLoaders.

<classpath loaderId='fooLoader' id='foo' />
LoaderManager {
   ClassLoader getClassLoader( Project p, String id );


The loader manager will construct a ClassLoader from the 
path specified in the classpath.   

Q: How to specify the parent ? A parentId attribute seems the simplest

2. Add a mechanism to request a particular loader to be associated
with a task. 

2.1. <taskdef loaderRef='foo' > will associate the task with a 
particular loader. 

2.2. It should be possible to specify a 
 <taskdef name='junit' 
          loaderRef='loader_with_junit.jar_in_a_random_location' />

2.3. add an attribute in Task that would allow a particular classloader 
to be used when executing that particular task.

2.4. ( Peter's request ) The LoaderManager should be able to
control the loader used for each task:

 Loader getTaskLoader( Project p, String targetName, String taskName )
Or even 
 Task getTaskInstance( ... )

A particular loader plugin could return a separate loader per task,
if it needs so ( or based on some settings ).

3. The default loader manager will implement the current policy
and behavior. Maybe with some fixes to not load the optional 
tasks from the main loader if an explicit declaration is found.
( in a taskdef that declares a specific loader ). This is
completely backward compatible ( an old file will not have 
the <taskdef loaderId> so old behavior will be in effect allways),
and will allow ( IMHO ) the user to fully control the loader 

4. Independetly of ant1.5 we could have one or many LoaderManager 
supporting various policies and environments. ( for example 
a NetBeans plugin using it's own mechanisms, or a tomcat4 
plugin using it's jndi/war loader )

5. As usual, (independent) tasks could define their own 
loaders, using the current ref mechanism.  One example
would be one that uses ant/lib/ hierarchy that was originally
proposed to define a loader for each directory. Or any
other combination. In time we can include ( or not ) 
some of those in the official ant.

Most of this proposal is very easy to implement and represents
small ( and natural, IMHO ) extensions to the current 
model, with full backward compatibility and ( again IMHO )
full control and flexibility for the user.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message