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]
