I would like to check in the (updated) <classloader> and <import> tasks into the MAIN branch.
Costin,
I haven't had time to review this in-depth but I would like to provide you with some quick feedback since I'm going offline for a while.
1. The use of ProjectHelper2 in the ImportTask
As I understand it, ProjectHelper2 is an implementation of the ProjectHelper plugin. As such, I don't think Tasks, such as ImportTask, should have a direct dependency on this class. Someone should be able to use another ProjectHelper without requiring ProjectHelper2 to be around.
It seems this is there just for the AntXmlContext class. Can this be made a top level class and moved out of the helper package.
2. Classloader
For the classloader task, you stated "It'll create a new loader or add paths to an existing loader." I'm not sure that modifying a classloader is safe after it has started serving classes. The scenario I'm considering involves a child loader and the following steps
1. Class A is requested from the child loader. The child loader first tries the parent loader which cannot find class A. The child loader then tries to load class A and succeeds.
2. The parent class loader is modified to add a path containing class A.
3. Class B is requested from the child loader. The child loader delegates to the parent which finds Class B.
4. Class B has a dependency on Class A which the VM attempts to load through Class B's class loader. Since this loader has been modified, Class A is found.
5. Class A has now been loaded by a class loader and its child loader. This will most likely lead to violation of loader constraints and mysterious failures.
Since you are proposing this to allow modification of the core loader, I think it may cause problems.
Thoughts?
Merry Christmas. Conor
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
