ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Murdoch" <>
Subject RE: myrmidon questions
Date Wed, 16 Jan 2002 03:44:28 GMT

> From: Peter Donald []
> 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.

If we expose embedded tasks to the configurer (via reflection, say, but however), then the
container could certainly validate them.

However, I wonder whether early validation is going to be worth the effort, at the end of
the day.  Some examples of things that are going to make early validation unpleasant:

- Anything that implements Configurable can't be validated, without the introduction of, 
let's say, a Validatable interface or similar.  Some notable examples of types that implement
Configurable: <property> and all the <data-type> psuedo-tasks.  And anything that
contains an embedded task.

- Any custom tasks/types built by the project and def'd with an import or typedef task.

- Anything loaded by the import task, which, in my case, if there's no libpath on the import
directive, is most tasks and datatypes.

- When the policy object allows tasks/types to be replaced, you can't validate anything (ok,
not strictly true, but you get the idea).

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

That's the beauty of having a task as well as a directive.  The user can pick and choose:
 If I want property expansion, I have to use the task, and validation is out.  If I don't
want property expansion, I can use the directive, and get validation.

Of course, if there's no early validation, the problem goes away.  So does the directive too,
I guess.

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

No, it has to be in the build file somewhere:

- so that I can use a path relative to the build file.
- so that I don't have to document how to run the build (apart from saying "use the default
- so that the build is portable across OSes and launchers (command-line, IDEs, etc).

> 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 
> file.
> 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"/>
>   </listener>
>   <errorhandler name="mail-out">
>     <param name="email" value=""/>
>   </errorhandler>
> </ant>

This would work, definitely.  But only if I had a single entry point for my build.  And I
never do, e.g. compile, dist, test, clean, rebuild, javadocs, etc.

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

I wasn't 100% clear on this - are you saying:  There will not be any standard way for downloading
libraries any time soon, so we should implement it ourselves (if we want that functionality
in Ant2).

Regardless, the download thing was just an aside - "hey look at what falls out of having a
VFS and having paths in <import>".  I didn't want to kick off the whole discussion again.

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

So only interfaces may be shared between typelibs, then?

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

Is there any concept of role sub-typing?  Given that a role maps one-to-one to a java type
(only to an interface?), and java types can be sub-typed, maybe it makes sense to introduce
such a concept.  Certainly, if we did, then the 'magic' of the type manager goes away.

So would the need for DataType, as the 'data-type' role could map to java.lang.Object.


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

View raw message