ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From peter reilly <peter.rei...@corvil.com>
Subject Re: cvs commit: ant/src/testcases/org/apache/tools/ant/taskdefs TypeAdapterTest.java
Date Thu, 26 Jun 2003 15:17:38 GMT
Yep, I realize that getTaskDefinitions returns
an empty table and that this behaviour is not
backward compatible.

The problem is that as tasks are now types, the getTypeDefinitions()
should now return everything. Current code that use
getTaskDefinitions also need to to call getTypeDefinitions() to
get a complete picture (as <typedef/> can be used to currently to define
tasks). <antstructure> calls both and
generates <!ELEMENT project (target | %tasks; | %types;)*>
so to the %types entity would have to exclude definitions in %tasks.


If this is a problem, I could make a new method
Project#getAllTypes() that would return the complete set of types,
and rework Project#getTaskDefinitions to iterate through the table and
only show the types that are tasks, and Project#getTypeDefinitions to
do the same for types that are not tasks. This solution does have
some issues. The main one being the delayed resolution of tasks/types.

Alternatively, <antstructure/> could be reworked to do the same,
or simply drop the tasks ENTITY.

On Thu, 2003-06-26 at 15:03, Stefan Bodewig wrote:
> On 26 Jun 2003, <peterreilly@apache.org> wrote:
> 
> >      * unifies the type and task definitions into one table
> 
> the only problem with this I see is that we are causing a potential
> backwards incompatibility with Project.getTaskDefinitions now
> returning an empty table - I don't think this is correct (remember you
> had to alter the test to pass because of this).
> 
> <antstructure> uses it for example and creates a now empty entity for
> Ant:
> 
> <!ENTITY % tasks "">
> 
> doesn't look too interesting.
Opps, I guess not ;-)
> 
> Maybe we should record all tasks added via addTaskDefinition in a
> separate table and return a "subtable" of the definitions that only
> contained the defined tasks here?

The problem here is that addTaskDefinition will (ok might) not be used
to add tasks in my next patches and it is not used by the new <taskdef/>

> 
> >      * <typedef/> has a number of new attributes:
> >          - adapter
> >          - adaptto
> >          - onerror
> 
> onerror is used for loading of the equivalent of defaults.properties
> in the future, I guess.  Do we really want to expose it as a general
> attribute?

The reason for this to be visible is to allow optional types/tasks to
be defined by thirdparty libraries - for example ant-contrib or
antelope.

I would like the lib author to specify which tasks/types are optional
and which are not in the antlib.xml file.

Currently all tasks in defaults.properties are optional in that if
they cannot be loaded, ant does not care. This is probably correct
behaviour for ant as it speeds up loading of ant. (in that the
names do not get resolved to classes until the name is used).

I would also like the same attributes to be used for the
antlib.xml <typedef/> definitions as for build.xml <typedef/> 
definitions (except for classloading attributes/elements).

Perhaps an "optional" attribute could be used instead.

> 
> Apart from that I've only seen some style violations checkstyle's
> going to pick up on my first skimming through the changes.  The next
> nightly Gump run will be interesting.

Heres hoping it is uninteresting....

Peter



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message