ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <j_a_fernan...@yahoo.com>
Subject Re: SUMMARY: loading tasks from jars for Ant 1.5 summary feedback
Date Mon, 15 Oct 2001 12:36:03 GMT
From: "Tim Dawson" <tdawson@wamnet.com>

> > From: Jose Alberto Fernandez [mailto:j_a_fernandez@yahoo.com]
> > 
> 
> 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



Mime
View raw message