You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Peter Donald <do...@apache.org> on 2001/06/03 06:08:02 UTC
Descriptor Format
Hi,
I think we are closer to defining the format for descriptor file. The
problem is that we have an open set of components that each descriptor file
must be able to describe. For isntance we currently have settled on at
least the following types being stored in jars;
* Mappers
* Tasks
* DataTypes (and sub-classes like FileSet/FTPFileSet/ZipFileSet).
* Aspects
* Listeners
* Converters
We need some way to be able to register all these different types.
Excluding converter for the moment, all of them have similar attributes
that need to be placed in TypeRegistry (ie Type + name + className).
A pattern that originated with Cocoon2 (which has similar requirements) is
to have two types of data in XML. The first type looks like
<type name="task" interface="org.apache.ant.api.Task"/>
<type name="data-type" interface="org.apache.ant.api.DataType"/>
<type name="mapper" interface="org.apache.ant.framework.Mapper"/>
It maps a short-hand name to a Type/Role name. The second type looks like
<task name="javac" class="org.apache.ant.tasks.jdk.Javac"/>
<task name="java" class="org.apache.ant.tasks.jdk.Java"/>
<data-type name="classpath" class="org.apache.ant.tasks.jdk.Classpath"/>
<data-type name="fileset" class="org.apache.ant.tasks.file.FileSet"/>
<data-type name="zip-fileset" class="org.apache.ant.tasks.file.ZipFileSet"/>
<mapper name="glob" class="org.apache.ant.framework.mappers.GlobMapper"/>
and this maps name to classes that match a certain role. ie The following
two representations are basically equivelent
<mapper name="glob" class="org.apache.ant.framework.mappers.GlobMapper"/>
<item name="glob"
interface="org.apache.ant.framework.Mapper"
class="org.apache.ant.framework.mappers.GlobMapper"/>
but the first is easier to read.
I propose that the descriptor format looks like -
<task name="javac" class="org.apache.ant.tasks.jdk.Javac"/>
<task name="java" class="org.apache.ant.tasks.jdk.Java"/>
<data-type name="classpath" class="org.apache.ant.tasks.jdk.Classpath"/>
<data-type name="fileset" class="org.apache.ant.tasks.file.FileSet"/>
<data-type name="zip-fileset" class="org.apache.ant.tasks.file.ZipFileSet"/>
<mapper name="glob" class="org.apache.ant.framework.mappers.GlobMapper"/>
It is easy to read and write and expressive enough for most concerns. If we
ever across a need for parameterized types (which I am not sure we will) we
can always change format to look like
<mapper name="glob" class="org.apache.ant.framework.mappers.GlobMapper">
<parameter name="foo" value="bar" />
</mapper>
However I am not sure we will ever need this.
The first set of information
<type name="task" interface="org.apache.ant.api.Task"/>
<type name="data-type" interface="org.apache.ant.api.DataType"/>
<type name="mapper" interface="org.apache.ant.framework.Mapper"/>
will be stored in regular jars that are sucked into base ClassLoader. The
reason is that the interfaces have to come from common jars that all tasks
have access to and it seems good to keep information about interface in one
place.
So I essentially propose 2 descriptors. One stored with antlibs and one
stored with archive that defines the interfaces used by antlibs.
(Converters will be handled separately - more on that later). Thoughts?
Cheers,
Pete
*-----------------------------------------------------*
| "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 |
*-----------------------------------------------------*
RE: Descriptor Format
Posted by Peter Donald <do...@apache.org>.
At 01:07 PM 6/3/01 +0100, Jose Alberto Fernandez wrote:
>Not to be picky, but I suggest we try to keep some similarity with ANT1 name
>usages if at all possible, so that we do not shock users too much:
><taskdef>, <typedef>, etc.
users have never had to deal with descriptors before except via
default.properties so I don't see that as of high enough importance atm.
>I would like to have the same syntax (whatever that is) for antlib.xml and
>for loose declarations in the buildfile itself. There is no reason to
>confuse people more than necessary ;-)
I don't see any need as the <*def ../> have a lot more attributes that are
relvent when defining tasks in build file but are not relvent in descriptor.
>With that in mind, we need to make allowance for declaring <classpath> on
>the <task(def)> declaration, so I can compile and use a loose task in one
>go. I presume simmilar requirements apply to others.
-1
Leave it to standard mechanisms (or slightly enhanced standard mechanisms)
to do this.
Cheers,
Pete
*-----------------------------------------------------*
| "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 |
*-----------------------------------------------------*
Re: Descriptor Format
Posted by coconut forcoconuts <co...@yahoo.com>.
--- Stefan Bodewig <bo...@apache.org> wrote:
> Jose Alberto Fernandez <j_...@yahoo.com>
> wrote:
>
> > I would like to have the same syntax (whatever
> that is) for
> > antlib.xml and for loose declarations in the
> buildfile itself.
>
> +1 on using the same syntax, but we could restrict
> the version that
> will be used in antlib.xml.
>
> I.e. make both use the same name and attributes, and
> allow the one
> used in build files to have additional
> attributes/child elements.
> Defining a classpath in antlib.xml doesn't make too
> much sense IMHO.
>
> Stefan
__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35
a year! http://personal.mail.yahoo.com/
Re: Descriptor Format
Posted by Stefan Bodewig <bo...@apache.org>.
Jose Alberto Fernandez <j_...@yahoo.com> wrote:
> I would like to have the same syntax (whatever that is) for
> antlib.xml and for loose declarations in the buildfile itself.
+1 on using the same syntax, but we could restrict the version that
will be used in antlib.xml.
I.e. make both use the same name and attributes, and allow the one
used in build files to have additional attributes/child elements.
Defining a classpath in antlib.xml doesn't make too much sense IMHO.
Stefan
RE: Descriptor Format
Posted by Jose Alberto Fernandez <j_...@yahoo.com>.
> From: Peter Donald [mailto:donaldp@apache.org]
>
> Hi,
>
> I think we are closer to defining the format for descriptor file. The
> problem is that we have an open set of components that each
> descriptor file
> must be able to describe. For isntance we currently have settled on at
> least the following types being stored in jars;
> * Mappers
> * Tasks
> * DataTypes (and sub-classes like FileSet/FTPFileSet/ZipFileSet).
> * Aspects
> * Listeners
> * Converters
>
> We need some way to be able to register all these different types.
> Excluding converter for the moment, all of them have similar
> attributes
> that need to be placed in TypeRegistry (ie Type + name + className).
>
> A pattern that originated with Cocoon2 (which has similar
> requirements) is
> to have two types of data in XML. The first type looks like
>
> <type name="task" interface="org.apache.ant.api.Task"/>
> <type name="data-type" interface="org.apache.ant.api.DataType"/>
> <type name="mapper" interface="org.apache.ant.framework.Mapper"/>
>
> It maps a short-hand name to a Type/Role name. The second
> type looks like
>
> <task name="javac" class="org.apache.ant.tasks.jdk.Javac"/>
> <task name="java" class="org.apache.ant.tasks.jdk.Java"/>
>
> <data-type name="classpath"
> class="org.apache.ant.tasks.jdk.Classpath"/>
> <data-type name="fileset" class="org.apache.ant.tasks.file.FileSet"/>
> <data-type name="zip-fileset"
> class="org.apache.ant.tasks.file.ZipFileSet"/>
>
> <mapper name="glob"
> class="org.apache.ant.framework.mappers.GlobMapper"/>
>
> and this maps name to classes that match a certain role. ie
> The following
> two representations are basically equivelent
>
> <mapper name="glob"
> class="org.apache.ant.framework.mappers.GlobMapper"/>
>
> <item name="glob"
> interface="org.apache.ant.framework.Mapper"
> class="org.apache.ant.framework.mappers.GlobMapper"/>
>
> but the first is easier to read.
>
> I propose that the descriptor format looks like -
>
> <task name="javac" class="org.apache.ant.tasks.jdk.Javac"/>
> <task name="java" class="org.apache.ant.tasks.jdk.Java"/>
>
> <data-type name="classpath"
> class="org.apache.ant.tasks.jdk.Classpath"/>
> <data-type name="fileset" class="org.apache.ant.tasks.file.FileSet"/>
> <data-type name="zip-fileset"
> class="org.apache.ant.tasks.file.ZipFileSet"/>
>
> <mapper name="glob"
> class="org.apache.ant.framework.mappers.GlobMapper"/>
>
Not to be picky, but I suggest we try to keep some similarity with ANT1 name
usages if at all possible, so that we do not shock users too much:
<taskdef>, <typedef>, etc.
> It is easy to read and write and expressive enough for most
> concerns. If we
> ever across a need for parameterized types (which I am not
> sure we will) we
> can always change format to look like
>
> <mapper name="glob"
> class="org.apache.ant.framework.mappers.GlobMapper">
> <parameter name="foo" value="bar" />
> </mapper>
>
> However I am not sure we will ever need this.
>
I would like to have the same syntax (whatever that is) for antlib.xml and
for loose declarations in the buildfile itself. There is no reason to
confuse people more than necessary ;-)
With that in mind, we need to make allowance for declaring <classpath> on
the <task(def)> declaration, so I can compile and use a loose task in one
go. I presume simmilar requirements apply to others.
> The first set of information
>
> <type name="task" interface="org.apache.ant.api.Task"/>
> <type name="data-type" interface="org.apache.ant.api.DataType"/>
> <type name="mapper" interface="org.apache.ant.framework.Mapper"/>
>
> will be stored in regular jars that are sucked into base
> ClassLoader. The
> reason is that the interfaces have to come from common jars
> that all tasks
> have access to and it seems good to keep information about
> interface in one
> place.
>
This makes sense, you could think of them belonging to the CORE. If on some
specialized usage of ANT's engine, (e.g. 3d rendering) you need some other
types, you can added to its CORE.
Jose Alberto