ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject RE: [DISC] details of task library concept
Date Thu, 24 May 2001 02:50:16 GMT
At 03:26 AM 5/24/01 +0100, Jose Alberto Fernandez wrote:
>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

Exec and java style classes will be built in the framework which you will
be able to use. There will also be tasks that do the same thing but offer
interface to TOM as well.

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

That is nothing that can't be done with proposed solution.

>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?

The ones that have been discussed from memory were things like

Execute, Java, FileScanner, *Scanner, *Sets, Dependency checking, mapping etc.

All other task like things you need should be done via the TOM.

>> 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:

deployment != loading

deployment means placing item in registry so that when it needs to be
instantiated it can be (at which point it will be loaded). Lazy loading is
of course done for performances sake.

>	<tasklib name="A" file="lib/A.tsk">
>		<classpath path="....."/> <!-- the path to add to classloader -->
>	</tasklib>
>alternatively, we could add multiple .tsk files on the same classloader:
>	<tasklib name="B" >
>		<classpath path="....."/>
>		<fileset dir="lib">
>			<include name="*.tsk" />
>		</fileset>
>	</tasklib>

Thats just creating one task library nade of multiple .tsk files.

>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" />
>		</fileset>
>	</tasklib>

no it is not. The auto deploy feature will load each .tsk into own

>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.

Thats not something I would ever wish on anybody. Having just gone through
.so hell and having much expereince with .dll and .jar hell I would pity
anyone who has to do this for anything great size.

>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).

Unlikely to ever happen - especially when these details can be specified
via Ant-Class-Path or similar manifest entry. It will be up to the runtime
to do searching and porefixing of directories or whatever. The one
difficulty I see with this is loading tools.jar (or equivelent) which will
in turn need to be done by reflection still. (tools.jar is different as it
is not on classpath but is in a well known place that you can not move).



| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |

View raw message