Peter Reilly wrote:
If it is not a little too late, I would like to get a vote
on including classloader into ant 1.7.
+0.5 I guess, if someone is testing it carefully (URLClassLoaderAdapter
in particular is a little unnerving). Really the advantage #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"
is a workaround for Ant's inability to autoload antlibs from a defined
classpath. Would be better to be able to say e.g.
<target name="init">
<antlibs>
<fileset dir="lib" includes="**/*.jar"/>
</antlibs>
</target>
<target name="whatever" depends="init" xmlns:f="antlib:org.foo">
<f:stuffWorks/>
</target>
where the <antlibs> call just registers a fileset (or, internally,
ClassLoader) and any later attempt to use a namespace automatically
checks for a matching antlib.xml, without touching the startup class
loader. It's a problem in Ant core that it cannot autodetect antlibs
except in Ant's startup loader.
Another issue is just that people are often intimidated by
ClassLoader's: they work logically once you get it, but getting it is
like math homework. Exposing a <classloader> task for widespread
consumption may make Ant seem for "experts only". Of course you don't
have to use the task if you don't want to, but what if we don't fix the
usability problems that made the task necessary to begin with, and using
<classloader> starts to be considered normal for Ant scripts?
-J.
--
[EMAIL PROTECTED] x22801 netbeans.org ant.apache.org
http://google.com/search?q=e%5E%28pi*i%29%2B1
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
