ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <>
Subject Update to Sandbox/antlib
Date Mon, 11 Feb 2002 01:57:24 GMT

here is the first part of my updates to the antlib sandbox, if a committer could please open
the attached jar in the sandbox and checkin all the new files I would really appreciate.

Here is an excerpt of what the new code does:

This is a new implementation of the <antlib> and <antjar> tasks including the
begining of the reconfiguration of some of the internals of ANT. This first set of changes
is just to prove that the internal changes necessary can be performed in a backward compatible
manner, in particular they pass (except for cosmetic changes) the testcases for ANT.

This is what I want to accomplish at the end:

1) Antlib/antjar allowing the definition of roles. There are two predefined roles "task" and
The meaning of roles is simillar to that of Peter but the way they work (are declared) is
somewhat different.
A role declaration especifies:

 - a name for the role

 - an interface with only one method which is used be the container to add elements of that
particular role.

 - an optional adapter class that can be used to adapt elements to the signature of the interface.

The idea is to reduce guessing by forcing the Task writer to indicate which roles its task
supports. As suppose to guess using introspection. This definitions are consistent with ANT1.x
structure by having the following predefined roles:

    <role name="task" 
             adapter=""    />

    <role name="datatype"
             adapter="" />

As you can see the same interface can be used to define multiple roles, and by using different
adapters it is possible to tackle the issue of datatypes and the TaskContainer.

2) A new way of managing classloaders that gives back certain control to the user.
Each antlib may specify a "loaderid" which identifies the classloader to use for this library.

All antlibs in a project identified by the same loader-id will be loaded by the same classloader.
Loaders in subprojects have as a parent ClassLoader the corresponding on the parent project.

I think this is a much better arangement, only if we actually have conflicting packages, do
we need to use different classloaders.

3) A new SymbolTable scope structure (in resemblace of the ExecutionFrames in ANT2 proposals).
In this way 
role declarations can be inherited from one project to the next instead of being copied.

There are provisions for backward compatibility that allow people to think that we are using
the old datastrctures although they have changed.

4) I am not using the new fnctionality completely. In particular the code continues to call
the old APIs (with their new implementations) in order to initialize the projects. In my next
iinstallment I will move more of the code to use the new
functionality removing all the special management for tasks and datatypes, if I can.

Once those changes are in, we can see how easy would be to rewrite tasks like <ejbjar>
and <condition> to take advantage of this roles.

BTW, I am willing to talk about the proos and cons of any one of this things. And how to make
them better.


Jose Alberto

View raw message