ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: myrmidon questions
Date Sun, 13 Jan 2002 08:19:03 GMT
On Sun, 13 Jan 2002 16:13, Adam Murdoch wrote:
> Thanks for answering these.  Of course, I have even more questions now :)

eek! That'll learn me ;)

> > From: Peter Donald []
> >
> > On Sun, 13 Jan 2002 13:32, Adam Murdoch wrote:
> > > What are your plans for the <import> task and <import> directive
> > > the 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. 

probably a good idea. However it may be a goo idea to rename the import task 
to load-type-library or something similar.

> 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. 

I would really hate to do this for the directive but +1 for the task 

>- 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.

sounds kool - what would it end up looking like in xml?

> 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).

I haven't looked at the code in a year but if it can be refactored then 
probably a good idea to do so ;)

> 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?

originally we were going to delegate this to a "policy" object. This same 
policy object would be used throughout the ant system to check policy of 
different things before allowing them or whatever. Theres a whole bunch of 
similar issues that people may want to toggle. Abstracting them behind a 
policy object would allow them to toggel it. Examples of things that may 
check policy include

* loading a library
* registering a type
* overiding a type
* setting a property
* overiding a property

So if you wanted property immutability (well actually the requirement to set 
values once) then you change the policy or if you wanted mutable propertys 
you just change the property. However this was discussed after I stopped 
working on myrmidon so I never implemented it ;)

> > > 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?

Sounds right (without going back to the code to look at it exactly).

> 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.

Correct ;) It was sorta by design. Because every instance of the Role needs 
to have the interface in it's ClassLoader, if a type lib was to register a 
role then only it could add in types to the registry (because only it would 
have access to class/interface for Role).

Hence if you register a role you probably *should* be placing class into 
shared lib/ directory. (ie Types implementing role can live in different 
typelibs but the Roles have difficulty).

We could relax this maybe .. not sure if thats a good idea - thoughts?

> 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.

Not sure. I still want there to be a separate ant-roles.xml (separate from 
ant-types.xml) but whether we also deploy ant-roles.xml from type libs is 
another question. If we decide to then it could be a good idea to make it 
possible to do this from DefaultDeployer.

> 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?

As it stands now the types have to be in the DataType role for those tasks to 
find them. So if they would usually in another Role then they have to be 
placed in two roles (ie data and the other one).

> 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>
> and
> <property name="some-fileset">
>     <fileset>...</fileset>
> </property>

Well I actually prefer the second form but that has been -1'ed by other 
committers ...

> > 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. 

Precisely! ;)

The magic is up to the people writing the task not the people writing the 
container. Ant1.xs biggest criticism is always that the container was not 
flexible enough (or that the committers weren't flexible enough). So putting 
the power in their hands - without compromising the total system is kinda a 
design goal. 

The basic design of it is to encourage good task design but if someone really 
wants to do something awful then they are free to do that aswell ;) 

> 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 effort.
> Would you (or anyone else) -1 an auto registering type manager?

I actually think XDoclet is more flexible but TypeManager is more simpler ;) 
However it is easy enough to try both - we can always revert or change 
something later if it doesn't work.



 Don't take life too seriously -- 
                          you'll never get out of it alive.

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

View raw message