ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kuiper, Arnout" <Arnout.Kui...@nl.origin-it.com>
Subject RE: Ant Principles (Taskdef storage)
Date Thu, 20 Apr 2000 11:13:07 GMT
> From: Stefan Bodewig [mailto:bodewig@bost.de]
> Either you have misunderstood Tom's question or I don't understand
> your answer.

Your right, I was sleeping probably...
At least we got the task scanning order extended with optional tasks;-)

> I think Tom is talking about something like a zip and an unzip
> task. Those would be in zip.jar and in unzip.jar in any one of the
> first three paths. Both share - say - ZipEntry. 
> 
> Where should that go? Put them into the CLASSPATH or into yet another
> ext-directory for "non task JARs"? The second one sounds like your 4.
> but I think it also applies to tasks not distributed with Ant.

Just some brain output:

Put all the required classes of a task in the tasks jar-file.
This prevents the problem of missing classes when a shared class
is not copied by accident. So ZipEntry in your example will be
packaged both in zip.jar and unzip.jar. This redundancy is
compensated for by the ease of use of the distributed version;
You just have the ant.jar and one jar for each tasks.

I think this makes it very easy for the end user. When he/she
needs a specific task, just download the jar and your done.

It is possible that certain tasks in the distribution may have
different versions of the same class (because a task was downloaded
with a newer version of the "shared" class). This won't be a problem
because each task will be run using it's own classloader, as discussed
elsewhere on the list.

So version management is also easier. Suppose we have 2 "task-vendors",
for respectively task A and B. Also suppose that both A and B use class
FooBar (v1.0). When vendor B fixes some bugs in his task B, and also
changes FooBar (to v1.1), and vendor A is on vacation or whatever,
then we have a break down when a user needs both A and the patched B,
and they share the same physical class. Packaging FooBar with the
task itself, and using separate classloaders solve this problem.

How do you think about this?

  Arnout

Mime
View raw message