ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Murdoch" <adammurdoch...@yahoo.com>
Subject RE: myrmidon questions
Date Mon, 14 Jan 2002 09:39:00 GMT

> From: Peter Donald [mailto:peter@apache.org]
> 
> > - 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 
> 

Why is that?

Regardless, here's what I'd like to be able to do:

I usually put everything I need to build into source control, so that the only thing someone
needs installed on their machine is a JDK and Ant (I know, I know, jars in CVS, evil and all
that).  I imagine it will be the same with typelibs - I will want to put the non-standard
typelibs I need into source control, and not install them in lib/.  But I will want them to
be treated exactly the same as those installed in lib/.  For example, I will want to use their
data types in my own custom tasks.

Also, once we get the VFS happening, I imagine it would be extremely handy to be able to put
the download location of the typelib in the <import> directive, and have the VFS layer
go hunt it down (and cache it locally, even better).  For example:

<import libpath="ftp://somewhere.org/pub/sometypelib.atl"/>

Again, it would be good if these were treated exactly the same as those installed locally.

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

Something like this, I guess:

<import lib="somelib">
    <task name="sometask"/>
    <mapper name="somemapper"/>
    ...
</import>

> > 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
> etc
> 
> 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 ;)
> 

I like this.

> > 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 do you deal with this kind of thing in phoenix?  Same rule?

I guess there's a few things we could do, but they're all kind of hacky.  But then so is requiring
typelibs to be in lib/ if they want to define roles, because it doesn't really solve the classloader
problem (well, it does if the role interfaces are the only things that are allowed to be shared
between typelibs).

How about we drop the restriction, and come up with a classloader solution later?  It could
just be something like a "common solutions" message attached to the class not found error.

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

Another auto registering type manager, then?  Or maybe not.

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

How about this then:

Seems like we have 4 cases for the task writer's intention for how the psuedo-task should
be treated:

- don't care, the container can do what it likes.
- yes, there must be a psuedo-task, but the container can *implement* it how it chooses.
- no, there must not be a psuedo-task.
- yes, there must be a psuedo-task, and it must be implemented a particular way.

And the same cases for a task user's attitude (or the container on behalf of the user).

I guess there's no real problem with putting a default implementation into the task-descriptor
for the first 2 cases, provided the task-descriptor also indicates that the container is free
to use a different implementation.


Adam


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


Mime
View raw message