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, <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
