ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: myrmidon questions
Date Wed, 16 Jan 2002 08:03:55 GMT
On Wed, 16 Jan 2002 14:44, Adam Murdoch wrote:
> > 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.

hmm - true. This more lies in a "preferences" or "configuration" file that is 
loaded to do things like that I guess. ie That is where you would store 
things like compiler preference (jikes vs modern), listener preference and so 

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

More that there is N different mechanisms of varying strength and potential. 
Some will download dependencies, some support versioning, etc. So instead of 
binding ants core to one, it may be better to just add an extra task for each 
different protocol that acted in accordance with the protocol.

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


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

If I get what you mean - yes. It is not possible to do classloader hacks like 
the proxy thing for interfaces but not for classes. To share classes they 
have to be either 

* no classloader boundaries (icky especially in light of XML parser 
incompatabilities etc)
* a shared jar in a parent classloader
* some other rmi-like hack where you serialize and then deserialize objects 
when dealing with items from different type librarys (this is hard and may 
not be possble if types don't implement serializable).

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

There used to be. Originally classes just registered and you did something 
like "give me an instance of class X with name Y". However this proved to be 
extremely complex - I was actually warned against it by the Cocoon developers 
who faced a similar design problem. It ended up that they were right and I 
simplified it to what we have now.

Now it is much easier to determine what you get when you ask with a component 
with a certain role. Previously it was much mre ickier - especially as 
roles/interfaces allow multiple inheritance/implementation.



   "Don't play dumb with me. 
I happen to be an expert at that" 
           - Maxwell Smart

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

View raw message