ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <>
Subject RE: [DISC] details of task library concept
Date Thu, 24 May 2001 02:26:08 GMT
> From: Conor MacNeill []
> Jose Alberto,
> Let me firstly say that we are not trying to prevent users
> from reusing
> code. We are trying to correctly manage the
> classpaths/classloaders in Ant-2
> properly. The Ant-1 approach is to place all jars in
> ANT_HOME/lib into the
> classpath before starting Ant. I think there are problems
> with that approach
> since those classes share classes with all other tasks, with
> Ant, with Ant's
> JAXP parser. There have been problems caused by this
> approach, especially in
> the JAXP area.

I agree with you on this. The jar in the process classpath should contain
little more than the Main class. That class should go and load the real code
using its own internal classloader. By doing that we can isolate the code

> > -----Original Message-----
> > From: Jose Alberto Fernandez []
> >
> > I agree completely with you here. createTask() is the wrong
> way of doing
> > things.
> > And that was exactly my point. For example, I was planning on
> > writing a task
> > that syncronizes two directories. That is it make certain
> that both ar
> > exactly the same.
> > Well this is just an application of the <copy> task (to pudate
> > anything that
> > exists,
> > and the application of the <delete> task on those thing
> that do not exist
> > anymore.
> >
> OK, lets say the tasks you want are in the corefile.tsk jar
> provided with
> Ant. I believe you will just have to put a classpath
> reference into your
> jar, deploy into Ant's task area and away you go. You will
> automatically
> have access to these classes in your task. I haven't tried
> that but I will
> tonight.

Now, this also has to work if instead of corefile.tsk is other.tsk that I
create as part of my project, or that comes with some other product. That
is, the approach should not be based on assuming the .tsk file needs to be
installed on ANT_HOME some place.

Otherwise, it is impossible to manage different buildfiles each requiring a
different conflicting version of a particular library.tsk.

> > The way to write (in Java) this task. Is to is to
> internally create an
> > instance of the class defining the Copy task (not using
> createTask) but
> > doing "new Copy()" which is the class I want. fill up the
> > parameters for it,
> > using its well known API. And calling its exec() method
> which is also well
> > defined.
> You are assuming that you can create a Copy task. Even in Ant-1 it is
> difficult to properly create a task in isolation. Did you set
> the Project,
> the tasktype, the task name, the location, etc. This will be even more
> difficult in Ant-2 since we don't want to open up the whole
> core to the
> tasks.

Half of the task in Ant one either do that or use some supporting class
designed for some other task. The tipical example are the classes belonging
to <exec>. <java> uses them for the fork=yes option, and many others do the

Others need to manufacture or fill-in parameter types to pass to other
classes and those parmameters have different custom types (not just

> >
> > All because we are actively trying to forbid people on
> using the code
> > written by others (so much for the concept of reusability and not
> > reinventing the wheel).
> As I have said above this is not what we are trying to do and
> I believe we
> should be able to do what you want as described above.
> However it is better,
> IMHO, to provide services that can be reused by many tasks rather than
> trying to reuse tasks directly.

So, what sort of services are you talking about? will making a copy of a set
of files be a service? Will compiling files be one? Will executing
something? Will deleting?

If they are, what differentiates them from the tasks? Why do we need both?

> >
> > Take a look at half of the tasks in Ant-1 and think about
> how they would
> > look like if every individual task had to reinvent everything or use
> > reflection to be able to access the capabilities already
> offerend by other
> > tasks. That is what you are asking for library code and there is
> > no reason
> > whatsoever to treat core tasks any different.
> In Ant-2 I do not expect any tasks to be invoking services in the core
> through other task's interfaces. This is not that common in
> Ant-1 and is the
> wrong approach anyway, IMHO.
> >
> > The only thing I am asking is for tasklibs to be able to specify
> > a classpath
> > with dependencies and such.
> >
> I'm not sure how that is going to work. Show me the syntax
> you see. We are
> talking about the automatic deployment of tasks here, right?
> The classpath
> can be specified as a relative classpath in the Jar's manifest.

Not necessarily automatic loading of tasks. (I do not beleive I want on
every execution of a buildfile for project A to load every single task ever
written that I think I may ever some day need. so, first let me give you
examples of manual loading:

	<tasklib name="A" file="lib/A.tsk">
		<classpath path="....."/> <!-- the path to add to classloader -->

alternatively, we could add multiple .tsk files on the same classloader:

	<tasklib name="B" >
		<classpath path="....."/>
		<fileset dir="lib">
			<include name="*.tsk" />

Now, the automatic deployment of tasks is done by the implicit application
of the following:

	<tasklib name="" >
		<fileset dir="${ant.home}">
			<include name="lib/*.tsk" />
			<include name="ext/*.jar" />
			<include name="ext/*.tsk" />

What and from where the rule is including things, exactly, is another
question. But the point is that all get loaded using the same classloader
and hence they all see each other. If I have conflicting libraries I just do
not put them in the ANT_HOME library but specify them manually.

Finally, you could envision having <tasklib> declarations as part of the
antlib.xml in the .tsk file. That way a task can specify internal
dependencies, that is why I was saying that maybe ${ant.home}, ${basedir}
and maybe some others should be available inside antlib.xml (or whatever we
call it).

Jose Alberto

View raw message