ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antoine Levy-Lambert" <levylamb...@tiscali-dsl.de>
Subject antlib
Date Mon, 21 Apr 2003 21:23:55 GMT
I am trying to update the antlib proposal (proposal/sandbox/antlib).

I believe everybody agrees on the objective of developing antlib(s) (in order to avoid ending
up with 10.000 classes in optional probably)

Every time I open my development environment to have a look at the proposal, I see that I
need to copy 3 or 4 methods from the Project.java of the main branch so that everything works.
So we need to progress swiftly concerning this antlib issue, otherwise the same checks will
need to be done over and over again (moving target syndrome).

There are the following features in the antlib proposal:
 
1) antlib & antjar
------------------------

deployment descriptor called antlib.xml which would go in the META-INF subdirectory of the
antlib

looks like that
<antlib version="1.5" >
  <task name="mkdir" class="org.apache.tools.ant.taskdefs.Mkdir"/>
  <task name="javac" class="org.apache.tools.ant.taskdefs.Javac"/>

  <data-type name="description" class="org.apache.tools.ant.types.Description"/>
  <data-type name="dirset" class="org.apache.tools.ant.types.DirSet"/>
....

Note that this mechanism would also be used for the core of ant and for optional.jar.
So defaults.properties would die. I believe that xml is superior to properties files, and
the fact of using the same technique for ant core and for the antlibs [ to find out which
tasks and which datatypes are defined ] is good.

2) type definitions 
--------------------------

allowing to define new implementations of mappers, selectors, paths, conditions, etc. You
can define these implementations in your antlib and a way to link this with the introspectors
(I am not sure how complete this is).
This would be really nice, because it will eliminate all the need for mentioning classnames
all around, antlibs will be used just like core.
Also useful for tasks like <ejbjar> which has vendor specific components that should
be part of the antlib of the vendor.

3) A scoping framework for the symbol tables needed to manage the antlib definitions
---------------------------------------------------------------------------------------------------------------------------
Management of a hash symbol table containing names, classes, and roles. Roles are currently
task or datatype.
It is possible to define new roles.

4) A framework for managing classloaders where you can specify which classloader to use when
loading an antlib.
--------------------------------------------------------------------------------------------------------------------------------------------------------------------

 

I would like, based on this email, to read what you find OK and what should be changed in
the antlib proposal. Once I have the comments from everybody on the list, we might put them
together in a document - including conflicting views if any - and vote.

Antoine 

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message