ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: cvs commit: jakarta-ant-myrmidon/api project.xml
Date Sun, 14 Apr 2002 10:47:52 GMT
On Sun, 14 Apr 2002 18:07, Adam Murdoch wrote:
> On Sun, 14 Apr 2002 17:41, wrote:
> > adammurdoch    02/04/14 00:41:00
> >
> >   Added:       .        build.xml
> >                aut      project.xml
> >                api      project.xml
> >   Log:
> >   Added sample project descriptors for api and aut.
> This is a first cut at a descriptor driven build for myrmidon. It's pretty
> rough at this stage, but should give an idea of how it might end up
> looking.

looks good so far. However I want to work in a more extensive dependency 
system that I started working on that works with the "Optional Packages" 
spec. I got it about 70% fleshed out and you can see the basic idea in 
antlibs.extension though I will backport it to ant1.x. 

Basically it gives the projects the opportunity to declare dependencies on 
extensions. Then there is some mechanism to map extensions to "real" jars. 
This mechanism of course being pluggable so that you could use <ant/> task, 
<get/> task, maven, forrest, gump, cjan, jjar or whatever to actually get 
required library. If it ends up not being able to map extension to a physical 
library then it will throw a exception. 

By leaving this open ended we don't have to really decide on any specific 
mechanism to do mapping or whatever and anyone can plug their favourit build 
system in.

> Thoughts?  Is this is the direction we want to go?  If so, I'll tidy up the
> project descriptor DTD a little, and get the stylesheet into a workable
> state.

Looks good so far. Personally I would prefer not to have a really fixed DTD as 
such. Fixed DTDs make it harder for end users to customize to their own 
environment. So the easier we make it to add new rlesets/transforms then the 
better it will be IMHO.

BTW I would probably prefer to use XSLT over velocity in longterm. The reason; 
from jdk1.4 onwards it comes with the JVM and I would like to minimize the 
number of dependencies that end users require. However DVSL is fine for now. 



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

View raw message