This is the "formal" enhancement request for a <classloader> task. In it's actual form, it has been introduced in the developer's mailing list. (see: http://marc.theaimsgroup.com/?l=ant-dev&m=108055794609605&w=2) I would like to reactivate and extend the current "sleeping" <classloader> task with a patch that is able to a) append classpath entries to existing classloaders, b) explicitely create classloaders, c) put the actual path of a classloader into a property and d) log a simple report about the currently classloaders. Currently it supports URLClassLoader and AntClassLoader. It is designed to simply support custom extensions for any arbitrary ClassLoader. Advantages ---------- As classpathes can completely managed from inside the build.xml, this task can help 1. to avoid the need to either change Ant's default installation by adding or removing jars to or from Ant's lib dir or manage the classpath in the launching script and 2. to avoid classpath-problems with custom tasks (especially if they should - for whatever reason - be used as jars in the same buildfile as they were created). b) and c) can be used to easily sync other task's classpathes and d) might be helpful to debug some classpath problems and understand classloader behaviour ;-) Disadvantages ------------- The most frequent raised objection is, that adding classpathes to existing parent classloaders in a delegation hierarchy may lead to situations where one class is loaded by two different classloaders in a delegation hierarchy at the same time. This will most likely cause linkage errors and mysterious failures. (See: http://marc.theaimsgroup.com/?l=ant-dev&m=106389211508059&w=2 and http://marc.theaimsgroup.com/?l=ant-dev&m=104080215031773&w=2) Another point is the risk of security loopholes if URLs are used as classpath entries. Both objections are reasonable but IMHO, the advantages outweigh them. * The aforesaid potential risks are described in the task documentation. * As this task is new, it can not endanger existing builds. * Advanced users have the possibility to break the above-mentioned requirements. Regards, Rainer P.S. Adding this task to the external task list is dissatisfying IMHO, as it shoots the major advantage (1.) down.
Created attachment 11152 [details] new files for proposed patch
Created attachment 11153 [details] changes (diff) for proposed patch
oops, i've seen, that the first attachment can not be opened. it's the patch.tar.gz resulting from the patch.xml. how should i contribute it? what is the correct classification/mine-type? sorry, Rainer
Created attachment 11178 [details] new files for proposed patch (with correct mimetype,sorry) replaces attach_id #11152
Created attachment 11179 [details] new files for proposed patch (last try with now - hopefully - correct mime-type)
It looks like some files are missing for the tar.gz file: the classloaders in the o.a.t.a.taskdefs.classloader package: AntClassLoaderAdapter SimpleClassLoaderAdapter URLClassLoaderAdapter
oops. peter, you're right. sorry, I didn't noticed that. may i send you the 3 files as a zip? regards, rainer
Just attach them to the bugzilla report. Cheers, Peter.
Created attachment 11562 [details] again: new files for proposed patch. replaces attachment from 04/07/04 21:22
Created attachment 11563 [details] modified diff (if also required), replaces attachment from 04/06/04 11:19
I added a vote for this enhancement that i find really useful and, at least for my needs, works like a charm. Actually i extracted the patch and built it as a separate package that i plan to use for our internal build system, but i hope to see it soon on afficial Ant release so that i won't have to carry around an additional jar. I'm aware of the security risks that it exposes, but, once well documented, i think the advantages largely override them. I maintained all the code comments and ownership, so i hope Rainer has nothing contrary to what i did. Regards, Gabriele.
I am looking at this again. It would be nice to make a number of changes: 1) the task import sun.import sun.misc.Launcher and import sun.misc.URLClassPath. It would be better not to import sun.* classes in non-optional tasks. A solution to this would be make the report function a seperate optional task. 2) the task could check if a jar or directort is already in a in the classpath I found when testing that it is easy to get into a situation where the classpath will have the same jar file many times - due to calls to <classloader> with using netbeans 3) the doc could state that use of this task in ides that do not have a separate jvm for a run of ant will cause issues - the classpath will be retained by the ide and used in the next ant build run
A new version of this functionality is available as an external task for trial purposes on http://jtools.org/ant-classloadertask/ This version solves some delegation hierarchy problems (see http://issues.apache.org/bugzilla/show_bug.cgi?id=35436) and follows peter's suggestions. The report functionality is removed into a separate task. Because I've also used the functionality in other contexts, I've separated the customisation framework from the Ant specific classes to increase it's reusability. As I'm not perfectly happy with this implementation (a little bit too sophisticated IMHO) I will think about some simplification before providing an updated patch. Any comments welcome! Cheers Rainer
*** Bug 37223 has been marked as a duplicate of this bug. ***
What are we going to do with this. Something for Ant1.7? Being able to patch the classloader can screw up IDEs, but its nice for adding antlibs on the fly
*** Bug 8722 has been marked as a duplicate of this bug. ***
I came across this request while trying to solve a problem I was having with the ftp task: the class implementing the task itself is loaded, but a library on which the task relies is not found. I am executing a ant.jar (java -jar ant.jar) so I can't specify the classpath (I know I can invoke the Main class from that jar adding all jars I need to the classpath, but I like the compact invocation form). I tried the classloader thing described here (actually the version in SVN) but it does not do much about my issue, at least not until I add some code that would hack the global classpath, adding the jars there, not the ant classloader. would it be an idea to add an option (maybe a reserved name?) to have this task alter the global classpath? a working way to alter the classpath (it's what I've been successfully using) is described here: http://forums.sun.com/thread.jspa?threadID=300557&start=49
I've tried to integrate this patch with current master, the result is here: https://github.com/gagern/ant/compare/28228-classloader I've noticed this while working on bug #47003. I must say, however, that this is a rather big change in this patch here. So far I haven't gotten it to compile yet. And I don't fully understand it either. (In reply to Mario Frasca from comment #17) > a working way to alter the classpath (it's what I've been successfully > using) is described here: > http://forums.sun.com/thread.jspa?threadID=300557&start=49 Unfortunately that page is not available any more.