ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <>
Subject Re: ClassLoaders ( was: Re: We need to stop the lies)
Date Tue, 26 Feb 2002 08:18:32 GMT
From: <>
To: "Ant Developers List" <>
Sent: Monday, February 25, 2002 5:33 PM
Subject: ClassLoaders ( was: Re: We need to stop the lies)

> 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
Hope so ;-)

> - 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.

This is a very contentious subject :-)
The last time we push too much on this side (i.e., usage of classloaders for ANT core)
blood run on ANT's shire. 

One thing that is overlooked over and over and that I think needs to be stressed
in ANT's guidelines on how to write well behaved tasks is that:

    - Users should not assume ANTs code is in the classpath.
    - At a minimum, any classloader created by tasks should have Project.getCoreLoader()
      as its parent. Or use AntClassLoader which takes care of that.

otherwise the task will not be guaranteed to work correctly inside IDEs.

As for IDEs, they should call ANT passing the ClassLoader to use for CORE
as specified in Main.start() signature. That should be the ClassLoader to use
as the Core loader and it should contain the Core classes in it.

Finally, we need to make a better job at consistently setting the CoreLoader
when a project instantiates another. We keep on having bugs in this regard.
On my proposal I added as default CoreLoader the on that loaded the
particular Project instance

I will discuss the rest of your proposal later...

Jose Alberto

> 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
> solution.
> 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 
> hierarchy.
> 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.
> Costin 
> --
> To unsubscribe, e-mail:   <>
> For additional commands, e-mail: <>

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

View raw message