[GitHub] ant pull request: Improve functionality of the classloader task wh...
Github user bodewig commented on the pull request: https://github.com/apache/ant/pull/4#issuecomment-64855476 Personally I'd prefer to have the discussion about this pull request in a single place - see https://issues.apache.org/bugzilla/show_bug.cgi?id=47003 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
classloader task
Based on the 1.8 planning guide http://wiki.apache.org/ant/Ant18/Planning, it seems like the classloader taskhttp://enitsys.sourceforge.net/ant-classloadertask/was planned for 1.8. But, I do not see this in the ant manual. Does this mean it is planned for a future release Thanks, Venkatesh
DO NOT REPLY [Bug 28228] - classloader task
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28228. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28228 [EMAIL PROTECTED] changed: What|Removed |Added Version|1.7.0RC1|1.7.0 -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28228] - classloader task
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28228. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28228 [EMAIL PROTECTED] changed: What|Removed |Added Version|1.7.0Beta3 |1.7.0RC1 -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28228] - classloader task
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28228. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28228 [EMAIL PROTECTED] changed: What|Removed |Added Version|1.7.0Beta2 |1.7.0Beta3 -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28228] - classloader task
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28228. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28228 [EMAIL PROTECTED] changed: What|Removed |Added Version|1.7.0Beta1 |1.7.0Beta2 -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28228] - classloader task
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28228. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28228 [EMAIL PROTECTED] changed: What|Removed |Added Version|1.7Alpha (nightly) |1.7.0Beta1 -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28228] - classloader task
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28228. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28228 --- Additional Comments From [EMAIL PROTECTED] 2006-05-18 10:03 --- 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 -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28228] - classloader task
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28228. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28228 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2005-10-28 14:54 --- *** Bug 37223 has been marked as a duplicate of this bug. *** -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28228] - classloader task
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28228. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28228 --- Additional Comments From [EMAIL PROTECTED] 2005-09-05 22:14 --- 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 -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 28228] - classloader task
On Mon, 6 Jun 2005, Rainer Noack [EMAIL PROTECTED] wrote: From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Well, at least it compiles on Kaffe, so those classes seem to get used by others as well. Do they work? No idea. The Kaffe Gump runs (currently disabled) used to build them, but don't have any unit tests so it's hard to tell. However, referring sun.* classes is not a good practice in general. Absolutely. 2) the task could check if a jar or directort is already in a in the classpath Yep. +1 but IMHO this behaviour should be switchable as there a imaginable cases where it is not desired. However, if we want to have this feature, we should use the getBootstrapClasspathUrls-functionality (see 1) for this feature too. I see. On Sun VMs using sun.boot.classpath is probably as reliable as using the sun.* classes. The should state that this task will cause many issues no matter how you run Ant - unless you really know what you do ;-) ... sometimes it is helpful to know what you do ... (A former collegue) ;-) Let me stretch the really in my sentence above. 8-) Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 28228] - classloader task
On Thu, 2 Jun 2005, [EMAIL PROTECTED] wrote: 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. Well, at least it compiles on Kaffe, so those classes seem to get used by others as well. A solution to this would be make the report function a seperate optional task. If we really only use them for reporting, then splitting the task is the best option, I agree. 2) the task could check if a jar or directort is already in a in the classpath Yep. 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 should state that this task will cause many issues no matter how you run Ant - unless you really know what you do ;-) Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: DO NOT REPLY [Bug 28228] - classloader task
Peter, Stefan, sounds reasonable. -Original Message- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: Monday, June 06, 2005 9:44 AM To: dev@ant.apache.org Subject: Re: DO NOT REPLY [Bug 28228] - classloader task On Thu, 2 Jun 2005, [EMAIL PROTECTED] wrote: 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. Well, at least it compiles on Kaffe, so those classes seem to get used by others as well. Do they work? I've not much experience with non-Sun jvms/jres. However, referring sun.* classes is not a good practice in general. A solution to this would be make the report function a seperate optional task. But isn't moving report-function to the optional category just a cosmetic operation? What do you think about moving the functionality getBootstrapClasspathUrls into JavaEnvUtils and do it there via reflection. If it fails, the util-method should return null. The calling application has to check this and log it as warning. We can also add tests for the both classes in JavaEnvUtils.getJrePackageTestCases. Or is there a better location for this functionality? If we really only use them for reporting, then splitting the task is the best option, I agree. see next comment. 2) the task could check if a jar or directort is already in a in the classpath Yep. +1 but IMHO this behaviour should be switchable as there a imaginable cases where it is not desired. However, if we want to have this feature, we should use the getBootstrapClasspathUrls-functionality (see 1) for this feature too. 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 Absolutely! The should state that this task will cause many issues no matter how you run Ant - unless you really know what you do ;-) ... sometimes it is helpful to know what you do ... (A former collegue) ;-) Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28228] - classloader task
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28228. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28228 --- Additional Comments From [EMAIL PROTECTED] 2005-06-02 16:08 --- 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 -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: DO NOT REPLY [Bug 28228] - classloader task
Peter, sounds reasonable. ad 1) I've not much experience with non-Sun jvms/jres. However, referring sun.* classes in a task might not be a good practice. But isn't moving report-function to the optional category just a cosmetic operation? What do you think about moving the functionality getBootstrapClasspathUrls into JavaEnvUtils and do it there via reflection. We can also add tests for the both classes in JavaEnvUtils.getJrePackageTestCases. Or is there a better location for this functionality? ad 2) I've also made this experience. Some times ago I've had a version with this feature but in the present version i abandoned it to make things easier. However, this behaviour should be switchable as there a imaginable cases where it is not desired. ad 3) Absolutely. (Something, I've never thought about.) I'm working on it but it may take a while (I've started a new project/contract yesterday). Cheers Rainer -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, June 02, 2005 4:08 PM To: dev@ant.apache.org Subject: DO NOT REPLY [Bug 28228] - classloader task (snip) --- Additional Comments From [EMAIL PROTECTED] 2005-06-02 16:08 --- 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 -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28228] - classloader task
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28228. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28228 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] ||it --- Additional Comments From [EMAIL PROTECTED] 2005-02-02 10:49 --- 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. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28228] - classloader task
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28228. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28228 classloader task --- Additional Comments From [EMAIL PROTECTED] 2004-05-15 10:15 --- Created an attachment (id=11562) again: new files for proposed patch. replaces attachment from 04/07/04 21:22 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28228] - classloader task
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28228. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28228 classloader task --- Additional Comments From [EMAIL PROTECTED] 2004-05-15 10:42 --- Created an attachment (id=11563) modified diff (if also required), replaces attachment from 04/06/04 11:19 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28228] - classloader task
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28228. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28228 classloader task --- Additional Comments From [EMAIL PROTECTED] 2004-05-14 00:29 --- oops. peter, you're right. sorry, I didn't noticed that. may i send you the 3 files as a zip? regards, rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28228] - classloader task
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28228. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28228 classloader task --- Additional Comments From [EMAIL PROTECTED] 2004-05-14 09:59 --- Just attach them to the bugzilla report. Cheers, Peter. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28228] - classloader task
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28228. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28228 classloader task --- Additional Comments From [EMAIL PROTECTED] 2004-05-11 08:27 --- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28228] - classloader task
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28228. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28228 classloader task --- Additional Comments From [EMAIL PROTECTED] 2004-04-07 21:22 --- Created an attachment (id=11179) new files for proposed patch (last try with now - hopefully - correct mime-type) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28228] New: - classloader task
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28228. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28228 classloader task Summary: classloader task Product: Ant Version: 1.7Alpha (nightly) Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Core tasks AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] 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-devm=108055794609605w=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-devm=106389211508059w=2 and http://marc.theaimsgroup.com/?l=ant-devm=104080215031773w=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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28228] - classloader task
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28228. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28228 classloader task --- Additional Comments From [EMAIL PROTECTED] 2004-04-06 11:17 --- Created an attachment (id=11152) new files for proposed patch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28228] - classloader task
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28228. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28228 classloader task --- Additional Comments From [EMAIL PROTECTED] 2004-04-06 11:19 --- Created an attachment (id=11153) changes (diff) for proposed patch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28228] - classloader task
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28228. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28228 classloader task --- Additional Comments From [EMAIL PROTECTED] 2004-04-06 11:40 --- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What do you think about a classloader task ?
Rainer Noack wrote: Hi Steve Your security issues sounds very reasonable for me. I've never thought of this, as I've used the URL option rarely in practice and only for LAN access where security was irrelevant. Another reason is, that I've no experience with this stuff. Do you think, it could be a blocker? What is the best solution in the case, there is nobody who is more familiar with this stuff and implements the security issues now? a) Contribute as is and document this issue in the task documentation until it's hopefully implemented later or b) Change the task, so that it does not accept non-file URLs (should be no big deal) or accepts only the original Path type instead of the extended one. Regards, Rainer I think for a build process you are taking your own risks. The danger is that if people do bind to remote URLs for stuff, they create a new back door. We should document that :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
What do you think about a classloader task ?
Hi Ant developers, After taskdef supports the loaderref attribute, I've written a task 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. I've posted it some time ago - a little rash (sorry) - to this list. However, as classpathes can completely managed from inside the build.xml, this task has helped in several projects 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) was helpful to debug some classpath problems and understand classloader behaviour ;-) When I found a similar Classloader task in Ant's CVS (originally from Costin Manolache), I was wondering that it was never advanced and released. IMHO, a classloader task would be a pretty helpfull extension to the existing alternatives for some usage. Are there reasons for not releasing it? I would be grateful for a short annotation (found nothing in the list archive). Otherwise, I would be proud to contribute the task to Ant if you find it helpful too. Regards (and excuse me for the long mail), Rainer P.S. Adding this task to the external task list is dissatisfying IMHO, as it shoots the major advantage (1.) down. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: What do you think about a classloader task ?
Hi Rainer, How did you manage to post your code? I tried to do the same awhile back, but apache.org wouldn't accept a zip attachment, and when I attached the java files individually, it stripped them all out of the email - leaving only text files... Cheers, Robert -Original Message- From: Rainer Noack [mailto:[EMAIL PROTECTED] Sent: 29 March 2004 11:59 To: [EMAIL PROTECTED] Subject: What do you think about a classloader task ? Hi Ant developers, After taskdef supports the loaderref attribute, I've written a task 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. I've posted it some time ago - a little rash (sorry) - to this list. However, as classpathes can completely managed from inside the build.xml, this task has helped in several projects 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) was helpful to debug some classpath problems and understand classloader behaviour ;-) When I found a similar Classloader task in Ant's CVS (originally from Costin Manolache), I was wondering that it was never advanced and released. IMHO, a classloader task would be a pretty helpfull extension to the existing alternatives for some usage. Are there reasons for not releasing it? I would be grateful for a short annotation (found nothing in the list archive). Otherwise, I would be proud to contribute the task to Ant if you find it helpful too. Regards (and excuse me for the long mail), Rainer P.S. Adding this task to the external task list is dissatisfying IMHO, as it shoots the major advantage (1.) down. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: What do you think about a classloader task ?
Hi Robert, I've sent the results from patch.xml (CVS-repository): a patch.txt file (the diff output) and a patch.tar.gz with the new files. However, sending a patch or enhancement to the list without prior agreement, seems to be a breach of the rules and will be ignored. I'm currently a bit insecure about the appropriate form. Regards, Rainer -Original Message- From: Robert Smith [mailto:[EMAIL PROTECTED] Sent: Monday, March 29, 2004 1:20 PM To: 'Ant Developers List'; [EMAIL PROTECTED] Subject: RE: What do you think about a classloader task ? Hi Rainer, How did you manage to post your code? I tried to do the same awhile back, but apache.org wouldn't accept a zip attachment, and when I attached the java files individually, it stripped them all out of the email - leaving only text files... Cheers, Robert -Original Message- From: Rainer Noack [mailto:[EMAIL PROTECTED] Sent: 29 March 2004 11:59 To: [EMAIL PROTECTED] Subject: What do you think about a classloader task ? Hi Ant developers, After taskdef supports the loaderref attribute, I've written a task 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. I've posted it some time ago - a little rash (sorry) - to this list. However, as classpathes can completely managed from inside the build.xml, this task has helped in several projects 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) was helpful to debug some classpath problems and understand classloader behaviour ;-) When I found a similar Classloader task in Ant's CVS (originally from Costin Manolache), I was wondering that it was never advanced and released. IMHO, a classloader task would be a pretty helpfull extension to the existing alternatives for some usage. Are there reasons for not releasing it? I would be grateful for a short annotation (found nothing in the list archive). Otherwise, I would be proud to contribute the task to Ant if you find it helpful too. Regards (and excuse me for the long mail), Rainer P.S. Adding this task to the external task list is dissatisfying IMHO, as it shoots the major advantage (1.) down. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: What do you think about a classloader task ?
Open a bug (enhancement request) and attache the patch and zip files to it. I gues you should put the text of your previous message as the body of the bug. Jose Alberto -Original Message- From: Rainer Noack [mailto:[EMAIL PROTECTED] Sent: 29 March 2004 12:54 To: [EMAIL PROTECTED] Subject: RE: What do you think about a classloader task ? Hi Robert, I've sent the results from patch.xml (CVS-repository): a patch.txt file (the diff output) and a patch.tar.gz with the new files. However, sending a patch or enhancement to the list without prior agreement, seems to be a breach of the rules and will be ignored. I'm currently a bit insecure about the appropriate form. Regards, Rainer -Original Message- From: Robert Smith [mailto:[EMAIL PROTECTED] Sent: Monday, March 29, 2004 1:20 PM To: 'Ant Developers List'; [EMAIL PROTECTED] Subject: RE: What do you think about a classloader task ? Hi Rainer, How did you manage to post your code? I tried to do the same awhile back, but apache.org wouldn't accept a zip attachment, and when I attached the java files individually, it stripped them all out of the email - leaving only text files... Cheers, Robert -Original Message- From: Rainer Noack [mailto:[EMAIL PROTECTED] Sent: 29 March 2004 11:59 To: [EMAIL PROTECTED] Subject: What do you think about a classloader task ? Hi Ant developers, After taskdef supports the loaderref attribute, I've written a task 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. I've posted it some time ago - a little rash (sorry) - to this list. However, as classpathes can completely managed from inside the build.xml, this task has helped in several projects 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) was helpful to debug some classpath problems and understand classloader behaviour ;-) When I found a similar Classloader task in Ant's CVS (originally from Costin Manolache), I was wondering that it was never advanced and released. IMHO, a classloader task would be a pretty helpfull extension to the existing alternatives for some usage. Are there reasons for not releasing it? I would be grateful for a short annotation (found nothing in the list archive). Otherwise, I would be proud to contribute the task to Ant if you find it helpful too. Regards (and excuse me for the long mail), Rainer P.S. Adding this task to the external task list is dissatisfying IMHO, as it shoots the major advantage (1.) down. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What do you think about a classloader task ?
+1 Rainer Noack wrote: Hi Ant developers, After taskdef supports the loaderref attribute, I've written a task 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. I've posted it some time ago - a little rash (sorry) - to this list. However, as classpathes can completely managed from inside the build.xml, this task has helped in several projects 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) was helpful to debug some classpath problems and understand classloader behaviour ;-) When I found a similar Classloader task in Ant's CVS (originally from Costin Manolache), I was wondering that it was never advanced and released. IMHO, a classloader task would be a pretty helpfull extension to the existing alternatives for some usage. Are there reasons for not releasing it? I would be grateful for a short annotation (found nothing in the list archive). Otherwise, I would be proud to contribute the task to Ant if you find it helpful too. Regards (and excuse me for the long mail), Rainer P.S. Adding this task to the external task list is dissatisfying IMHO, as it shoots the major advantage (1.) down. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What do you think about a classloader task ?
There was some discussion about Costin's classloader task for the 1.6 release: http://marc.theaimsgroup.com/?l=ant-devm=106389211508059w=2 Peter Rainer Noack wrote: Hi Ant developers, After taskdef supports the loaderref attribute, I've written a task 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. I've posted it some time ago - a little rash (sorry) - to this list. However, as classpathes can completely managed from inside the build.xml, this task has helped in several projects 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) was helpful to debug some classpath problems and understand classloader behaviour ;-) When I found a similar Classloader task in Ant's CVS (originally from Costin Manolache), I was wondering that it was never advanced and released. IMHO, a classloader task would be a pretty helpfull extension to the existing alternatives for some usage. Are there reasons for not releasing it? I would be grateful for a short annotation (found nothing in the list archive). Otherwise, I would be proud to contribute the task to Ant if you find it helpful too. Regards (and excuse me for the long mail), Rainer P.S. Adding this task to the external task list is dissatisfying IMHO, as it shoots the major advantage (1.) down. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What do you think about a classloader task ?
Rainer Noack wrote: Hi Ant developers, After taskdef supports the loaderref attribute, I've written a task 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. I've posted it some time ago - a little rash (sorry) - to this list. However, as classpathes can completely managed from inside the build.xml, this task has helped in several projects 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). This all seems useful, and is the logical extension of the -lib option to insert new stuff into the base classloader. I am currently busy doing classpath stuff and ant integration with our deployment framework (see http://cvs.sourceforge.net/viewcvs.py/smartfrog/core/extras/ant/doc/ant_tasks.sxi). One thing smartfrog does is lets you specify a codebase when describing a new app to host/deploy; that codebase takes URLs. now in security on mode, only signed and sealed URLs are allowed, but ignoring that detail, being able to spec URLs to where jars come from is very, very slick. Security does matter; you dont want to have build files that go codebase add url=http://gump.apache.org/latest/junit/dist/junit.jar; / codebase without something saying 'is this a trusted release of junit'. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: What do you think about a classloader task ?
Hi Steve Your security issues sounds very reasonable for me. I've never thought of this, as I've used the URL option rarely in practice and only for LAN access where security was irrelevant. Another reason is, that I've no experience with this stuff. Do you think, it could be a blocker? What is the best solution in the case, there is nobody who is more familiar with this stuff and implements the security issues now? a) Contribute as is and document this issue in the task documentation until it's hopefully implemented later or b) Change the task, so that it does not accept non-file URLs (should be no big deal) or accepts only the original Path type instead of the extended one. Regards, Rainer -Original Message- From: Steve Loughran [mailto:[EMAIL PROTECTED] Sent: Monday, March 29, 2004 3:35 PM To: Ant Developers List Subject: Re: What do you think about a classloader task ? Rainer Noack wrote: Hi Ant developers, After taskdef supports the loaderref attribute, I've written a task 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. I've posted it some time ago - a little rash (sorry) - to this list. However, as classpathes can completely managed from inside the build.xml, this task has helped in several projects 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). This all seems useful, and is the logical extension of the -lib option to insert new stuff into the base classloader. I am currently busy doing classpath stuff and ant integration with our deployment framework (see http://cvs.sourceforge.net/viewcvs.py/smartfrog/core/extras/ant/doc/ant_task s.sxi). One thing smartfrog does is lets you specify a codebase when describing a new app to host/deploy; that codebase takes URLs. now in security on mode, only signed and sealed URLs are allowed, but ignoring that detail, being able to spec URLs to where jars come from is very, very slick. Security does matter; you dont want to have build files that go codebase add url=http://gump.apache.org/latest/junit/dist/junit.jar; / codebase without something saying 'is this a trusted release of junit'. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
classloader task
After taskdef supports the loaderref attribute, I've written a task,
that is able to explicitely create classloaders, append classpath
entries to existing classloaders and put the actual path of a
classloader into a property.
In several projects, this avoids some of the annoying constraints and
workarounds occasionally reported in bugzilla and the mailing lists.
I've merged it with Costin's sleeping classloader task and I think
it could be a helpful enhancement.
Currently it supports URLClassLoader and AntClassLoader and it is
designed to simply support custom extensions for any arbitrary
ClassLoader.
Regards,
Rainer
? docs/manual/CoreTasks/classloader.html
? src/etc/testcases/taskdefs/classloader
? src/main/org/apache/tools/ant/taskdefs/classloader
? src/main/org/apache/tools/ant/types/LoaderHandler.java
? src/main/org/apache/tools/ant/types/LoaderHandlerSet.java
? src/main/org/apache/tools/ant/types/URLPath.java
? src/main/org/apache/tools/ant/types/LoaderRef.java
? src/main/org/apache/tools/ant/types/LoaderParameters.java
? src/main/org/apache/tools/ant/types/AntLoaderParameters.java
? src/main/org/apache/tools/ant/util/URLUtils.java
? src/testcases/org/apache/tools/ant/taskdefs/ClassloaderTest.java
? src/testcases/org/apache/tools/ant/types/URLPathTest.java
Index: CONTRIBUTORS
===
RCS file: /home/cvspublic/ant/CONTRIBUTORS,v
retrieving revision 1.2
diff -u -r1.2 CONTRIBUTORS
--- CONTRIBUTORS13 Mar 2004 08:29:26 - 1.2
+++ CONTRIBUTORS13 Mar 2004 16:21:17 -
@@ -146,6 +146,7 @@
Pierre Dittgen
Raphael Pierquin
R Handerson
+Rainer Noack
Richard Evans
Rick Beton
Robert Anderson
Index: docs/manual/coretasklist.html
===
RCS file: /home/cvspublic/ant/docs/manual/coretasklist.html,v
retrieving revision 1.53
diff -u -r1.53 coretasklist.html
--- docs/manual/coretasklist.html 12 Mar 2004 15:11:35 - 1.53
+++ docs/manual/coretasklist.html 13 Mar 2004 16:24:03 -
@@ -26,6 +26,7 @@
a href=CoreTasks/pack.htmlBZip2/abr
a href=CoreTasks/checksum.htmlChecksum/abr
a href=CoreTasks/chmod.htmlChmod/abr
+a href=CoreTasks/classloader.htmlClassloader/abr
a href=CoreTasks/concat.htmlConcat/abr
a href=CoreTasks/condition.htmlCondition/abr
nbsp;nbsp;a href=CoreTasks/conditions.htmlSupported conditions/abr
Index: src/etc/testcases/taskdefs/classloader.xml
===
RCS file: /home/cvspublic/ant/src/etc/testcases/taskdefs/classloader.xml,v
retrieving revision 1.2
diff -u -r1.2 classloader.xml
--- src/etc/testcases/taskdefs/classloader.xml 24 Dec 2002 18:09:39 -
1.2
+++ src/etc/testcases/taskdefs/classloader.xml 13 Mar 2004 16:28:14 -
@@ -1,23 +1,119 @@
-project name=classloader-test default=main basedir=.
+project name=classloader-test default=test-system2prop basedir=.
- target name=init
+ target name=test.system2prop
+classloader loader=system property=test.cl.system2prop /
+condition property=test.system2prop
+ isset property=test.cl.system2prop/
+/condition
+ /target
+
+ target name=test.report
+classloader report=true/
+ /target
-path id=myJars
- !-- both ant-junit.jar and junit.jar must be loaded from the same path
--
- pathelement path=${ant.home}/lib/ant-junit.jar /
- pathelement path=${junit.jar} /
-/path
+ target name=test.system2prop
+classloader loader=system property=test.cl.system2prop /
+condition property=test.system2prop
+ isset property=test.cl.system2prop/
+/condition
+ /target
-classloader classpathRef=myJars
- reverse=true
-
+ target name=test.createURL
+classloader loader=test.cl.createURL
+ classpath
+ urlpathelement location=http://my.domain/my.1st.jar/
+ urlpathelement
path=http://my.domain/my.2nd.jar;http://my.domain/my.3rd.jar/
+ /classpath
/classloader
-junit /
-
+classloader loader=test.cl.createURL property=test.cl.createURL/
+condition property=test.createURL
+ equals
arg1=http://my.domain/my.1st.jar;http://my.domain/my.2nd.jar;http://my.domain/my.3rd.jar;
+ arg2=${test.cl.createURL}/
+/condition
+
+ /target
+
+ target name=test.updateURL
+classloader loader=test.cl.updateURL
+ classpath
+ urlpathelement location=http://my.domain/my.1st.jar/
+ /classpath
+/classloader
+classloader loader=test.cl.updateURL property=test.cl.updateURL
+ classpath
+ urlpathelement location=http://my.domain/my.2nd.jar/
+ /classpath
+/classloader
+condition property=test.updateURL
+ equals arg1=http://my.domain/my.1st.jar;http://my.domain/my.2nd.jar;
+ arg2=${test.cl.updateURL}/
+/condition
+
+ /target
+
+ target name=test.createAnt
+classloader loader=test.cl.createAnt
