From: "Tim Dawson" <[EMAIL PROTECTED]> > > From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED] > > > > ok... then how do we get the DD? (I've only ever used getResources() > to grab a resource other than a properties file from a jar) > > I'm gonna need a few implementation pointers here...
You could just extracted from the library using the Zip classes.
>
> I can agree with that 100%. Is using "Class-Path" controversial?
> I haven't read any threads related to that.
>
The problem that I see here is that ANT is using its own 1.1 able ClassLoader
which do not understant Class-Path. Which it is a problem. I think we would
have to
retrofit the details of the 1.2 spec into AntClassLoader to make it work right.
Notice that 1.2 provides URLClassLoader which knows how to do all the work.
I think.
> I could see how it would be for the optional jar, because there
> are so many different dependencies locked up in there, you'd have
> to break it out into many smaller jars or else I'd have to have
> the starteam.jar even though all I want is to use the junit task.
>
In my understading, not everything in Class-Path needs to exest. Same as with
CLASSPATH.
I think though that is would be a very good idea to break up optional.jar into
a bunch of
smaller libraries for each particular usage. For example an AntCVS.jar,
AntPCVS.jar, AntJunit.jar
ans so on. Each with its limited dependencies. So in your buildfile you would
say:
<antlib library="AntJunit.jar"/>
and we will just need to have junit.jar is you want this library to work.
> >
> > But that would mean there is no way to start ANT, just because
> > you put one too many jars in the system. That sounds really bad to me.
>
> ah, I see what you mean. if I dropped the jar file in I'd still get an
> error whether or not I was planning to use it. that would be confusing.
>
> the best approach is just to unsupport autoloading. I'm in support of that,
> but can we get consensus around it?
>
Agreed.
Tim, I have been working on an implementation which I think is all coded but I
have not tested yet.
Before sending a patch submission I also want to have an <antjar> task to
package
the libraries and verify the descriptor. Only after that, I would try to submit
a patch of core to
reorganize it in libraries, and adopt it during initial loading.
I am attaching the code I have to hear your suggestions or anyone elses on the
code I have.
My goal at the end of the day is for the core to load its core tasks by just
executing the equivalent of
<antlib library="ant.jar" />.
One of the problems I am trying to dealt with is how to bootstrap ANT in this
new model.
During bootstrapping (when building from scratch) there is no "ant.jar" and
hence the problem.
If there is no /org/apache/tools/ant/defaults.properties, but instead one of
several META-INF/antlib.xml
we will need some way to tell ANT to use the unjared file located somewhere.
I was thinking on adding a property during bootstrap:
-Dant.bootxml="filename"
which will be used by the core instead of the <antlib> mentioned above. You
will see some methods in the code
providing what it is needed for this to work.
I would like your opinionsand improvements. This code depends on the patch for
project-level tasks (DeclaringTasks) that I sent last week.
Hope to hear comments, concerns, additions, etc.
Jose Alberto
Antlib.java
Description: Binary data
Antlib-V1_0.dtd
Description: Binary data
