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: [DISC] details of task library concept
Date Tue, 22 May 2001 10:28:47 GMT
> From: Stefan Bodewig [mailto:bodewig@apache.org]
>
> We've settled on
>
> * allow tasks to be loaded from jars. tasks should be indicated by
>   either xml file in TSK-INF/taskdefs.xml or manifest file.
>
> and we've also agreed that these jars could also contain data types
> and other pluggable components.
>
> What we have not defined at this point is whether we should use
>
> 1) Entries in the MANIFEST.MF
>
> 2) an XML file
>
> 3) something else
>
> to provide Ant with all necessary information about the specific
> library.
>
> My preference here is to use an XML file and the syntax one would use
> in a build file as well, i.e. use <taskdef> to define a task,
> <typedef> to define a data type and so on.  This file should reside in
> META-INF and I propose META-INF/antlib.xml.  The main reason is
> consistency.
>

I agree with you. And to make it more specific, I would say that we also
need to allow for the use of properties which can be inherited from the
including project.
That way one can specify other jars or task libs that must be loaded.

>
> Other details to resolve are
>
> * Will each task library be loaded with a class loader of its own to
> avoid class-name or class-version clashes?
>
> I'm not a class loader expert and can only hope that breaking JDK 1.1
> compatibility will make the whole class loader business a bit
> easier. At first glance, they should probably be separate.
>

I think they should follow the current rules of <taskdef> with respect to
classloaders.
What happens otherwise if I define tasks by extending the classes of other
tasks defined by other people in other task libraries?

> * Will each task library be assigned to an XML-Namespace to avoid
> task-name clashes?
>
> IMHO, yes.  Maybe we should use the name of the jar file (without
> extension) as the namespace prefix.

I prefer an explicit name assignment. There is nothin to prevent having two
task libraries with the same file name but in different directories. Or any
need to modify my build file all over the place when I upgrade from
"weblogiclib-1.1.jar" to "weblogic-1.2.jar".

	<tasklib name="weblogic">
		<classpath ...>
		<fileset .... />
	</tasklib>

this will use the files in the fileset as libraries to load toghether using
a classloader that also makes the classes in <classpath> available. They all
will be loaded under the same XML-namespace of "weblogic".

With a semantic shuch as that, the default loading of libraries from the
ant/lib is nothing else but the implicit execution of the following
<tasklib>:

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

the empty name is the official way in XML to talk about the default
namespace. So there is no special or magic stuff happening.

>
> * The extension of the library file itself.
>
> ".tsk" has been proposed, but this might put too much focus on tasks.
> How about ".ant"?
>

I propose that <tasklib> itself does not require a specific extention name.
We can propose some naming conventions. This is important because I want
people whose products require the use of installation tools to be able to
define <task>s for usage with ANT and be able to ship them as part of the
jar of their product. So for example:

	weblogic-3_5.jar: may contain the weblogic code, their deployment tools,
including classes defining tasks for ANT. They just put an antlib.xml in the
*-INF directory and I should be able to just loaded in my buildfiles
directly. No need for separate packaging.

> * We've agreed to store documentation within the library itself -
> where?
>
> We shouldn't store formated docs but only the source XML files for the
> documentation inside the libs IMHO - I'd put them in META-INF/doc
> maybe with subdirectories for tasks and types so that a task
> generating the documentation can easily sort them into categories.
>

I think this is way asking too much. How are these documents going to be
extracted and displayed? Are we going to add a document renderer inside ANT?
I think we should keep it simple. Have ANT just provide a "-taskhelp
[space:]task" which displays a <description> element to be added to
<taskdef>:

	<taskdef....>
		<description href="http://location/of/formated/docs">
			Here goes the short description for ANT help.
		</description>
	</taskdef>

The help may print the hyper-link as text, and tools like antidote can
provide a clickable link to it. But there is no need for us to force some
complicated directory structure.

Jose Alberto


Mime
View raw message