ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Murdoch" <>
Subject RE: myrmidon questions
Date Sun, 13 Jan 2002 05:13:21 GMT

Thanks for answering these.  Of course, I have even more questions now :)

> From: Peter Donald []
> On Sun, 13 Jan 2002 13:32, Adam Murdoch wrote:
> > What are your plans for the <import> task and <import> directive (at
> > top of a <project>)?  Right now, they take different attributes and
> > reference the library differently (the task by file path, the 
> directive by
> > base name). What do you think of doing away with one of them (the
> > directive, say)?
> I was actually hoping to do away with the task (I actually forgot 
> it still 
> existed). Basically I was hoping that import of type librarys for 
> ant behaved 
> in a similar fashion to import of packages for java.
> At least thats the idea - I think we will need to experiment with 
> things and 
> see if they end up turning out like that though ;)

Sounds like we don't want to do away with either of them.  Perhaps making them work identically
would be a better thing.  That is, have attributes to:

- Specify the library by base name.  The standard lib path would be searched to find the library.
- Specify the library by path.  This would be useful for typelibs that sitting in the source
tree (e.g. <import libpath="libs/somelib.atl"/>) or that get built by the project.
- Specify the type to import (role name + type name).  Might be useful to import more than
one type with a single <import>, so maybe a nested element to do this.

All we need is some refactoring to pull this stuff into a single config class that is used
in both places (maybe use interfaces.model.TypeLib).

How do you reckon we handle name conflicts when importing a lib?  Right now, DefaultTypeManager
and MultiSourceTypeFactory will chuck away the old type and replace it with the new type.
 Perhaps bailing on conflict is a better thing to do?

> > In particular, how would this affect the configurer, if it wanted to
> > do type substitution?
> Does the above cover that?

Yep, pretty much.  To put it in code terms, the configurer would:

1. Call RoleManager.getRoleForName(propJavaClass.getName()) to figure out the role name.
2. Call TypeManager.getFactory(roleName) to find the factory.
3. Call TypeFactory.create(typeName) to create the value.

Is that right?

Exactly how it figures out "propJavaClass" and "typeName" we can ignore for now.

One thing I noticed is that ant-roles.xml doesn't appear to be used when a typelib is imported.
 DefaultRoleManager.initialize() loads the roles during startup, finding ant-roles.xml using
ClassLoader.getResources().  But that's the only time roles are added.  Makes it kinda hard
for a typelib to introduce roles for its types.

How about we move responsibility for deciding which ant-roles.xml to load, and when to load
them, to DefaultDeployer?  Maybe even move the parsing code over too, so that roles are treated
the same as types and converters.

Once the data types are partitioned into their various roles, how are the Property and TypeInstanceTask
tasks going to find a factory to instantiate their value?  Same as the configurer?

> > I'd like to automate the process of defining a TypeInstanceTask task for
> > each data type.  Looks like it would be trivial to use the 
> XDoclet stuff to
> > add a <task> declaration in the descriptor for each data type.  
> However, I
> > think it would be good to keep the descriptor as normalised as possible,
> > and avoid putting the <task> declaration in there.  This would give the
> > container plenty of freedom to do what it wants at runtime.  What I was
> > thinking of doing was add a TypeManager implementation that took care of
> > either registering the task when the data type is registered, 
> or that took
> > care of instantiating a TypeInstanceTask when a "task" with the 
> name of a
> > data-type is requested.  Thoughts?
> I don't like the last case but the other two (xdoclet and a "smart" 
> registering TypeManager) could be interesting to work with. 
> XDoclet would be 
> by far the most flexible solution and if we end up going with 
> that approach 
> then we could almost completely automate it (have a rule that 
> said anything 
> implementing interface X that has attribute Y is registered like so).
> A "smart" TypeManager could also be a good idea. Not sure - it would mean 
> that everything that was a DataType would automatically be 
> registered as a 
> "task". Is that a good idea? I don't know. 

Consistency is a good thing.  If you use TypeInstanceTask for one data type, you probably
want to use it for all of them.

Maybe we should step back and ask whether pseudo-tasks that create a data-type instance is
a good idea or not?

As in, is there really any difference between:

<fileset id="some-fileset">...</fileset>


<property name="some-fileset">

> It is kinda neat but probably a 
> bit more work and has icky magic code ala
> if( o instanceof DataType )
> {
>   doMagic()
> }

Sure, but that's true of using XDoclet as well.  Except that then the magic code is in every
typelib descriptor.  Too bad if we want the container to use something other than org.apache.myrmidon.framework.TypeInstanceTask.

Using XDoclet is definitely simpler, and would be an excellent short-term solution.  However,
the flexibility we get from a TypeManager (or whatever component) is probably worth the extra

Would you (or anyone else) -1 an auto registering type manager?


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message