ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: myrmidon questions
Date Mon, 14 Jan 2002 11:11:16 GMT
On Mon, 14 Jan 2002 20:39, Adam Murdoch wrote:
> > From: Peter Donald []
> >
> > > - 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?

Because I really like the java "import" model as it makes it much easier to 
validate stuff. However this declarative import prolly would not work with 
embedded tasks.  As soon as we start allowing paths and similar items in the 
<import/> directive then people would want to do property evaluation in them, 
which means propertys/tasks would need to be evaluated before the directives 
and they cease be as useful (or useful at all) in validating ant files.

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

Still that could still be done by setting a environment variable such as 

export ANTLIB_PATH=~/my/typelibs/dir/is/here

or perhaps passed in on the command line like

ant.bat --antlib-path=~/my/typelibs/dir/is/here

or the third and final way (and the way I actually do a lot of things in 
ant1.x world) is to have a "controller" build file. So the controler build 
file would integrate your local settings and then launch the "real" build 

It may include a task such as

<ant file="build.ant">
  <antlib-path value="~/my/typelibs/dir/is/here"/>
  <listener name="classic">
    <param name="file" value="foo.txt"/>
  <errorhandler name="mail-out">
    <param name="email" value=""/>

etc. So the top level controller basically sets up the "frame" of the 
following project and exeutes it.

> 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=""/>
> Again, it would be good if these were treated exactly the same as those
> installed locally.

we have talked a fair bit about this and how to download stuff automagically 
etc. It actually spawned a few efforts in commons-dev (cjan, jjar) and we 
could also integrate into standard technologies (ie JNLP). Because there is 
unlikely to be one true way for this downloaded part I think it would be 
better to deal with it separately - at least until such a point in the future 
where there is one consistent standard.

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

works for me. 

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

We don't :) Currently inter-application communication in phoenix is done via 
standard java mechanisms (RMI, JMX, CORBA, Sockets, whatever). Eventually we 
will support some sort of streamlined inter-app comms but we haven't yet. 
Actually Paul Hammant recently created an alternate to RMI for in process 
(and outter process) comms for different transports. And proposed a question 
to avalon-dev about an hour ago ... haven't read it yet though ;)

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

The only real solution that I can come up with off the top of my head is the 
following. We implement a Proxy solution (based on ideas similar to JDK1.3s 
Proxy API but 1.2 compatible). Each type library then loads their own version 
of Role, and the core interacts with it via a proxy/adaptor. Then anytime we 
need to pass a role type instance between typelibrary we create more adaptors 
and so forth.

There are a few cases where this would miss but it catches 95% of the 
problems - but it is a fairly large amount of work and for a small benefit 
IMHO. If we implement it then it can wait till later in development cycle IMO

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

We can try it - not sure if this is too much magic in the container though ;)

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

(4) can be implemented using xdoclet regardless of whether we add any magic 
into the container. I guess (2) is a nice way if it could be generalized to 
other similar things ... not sure need thinking music ;)



Frank Zappa observed: "It's not getting any smarter out
                       there.You have to come to terms with
                       stupidity, and make it work for you."

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

View raw message