ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Murdoch <>
Subject Re: cvs commit: jakarta-ant-myrmidon/api project.xml
Date Sun, 14 Apr 2002 12:24:59 GMT
On Sun, 14 Apr 2002 20:47, Peter Donald wrote:
> 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.

I was thinking along (kinda) similar lines, where we start dealing with 
dependencies at a more abstract level than plain files names.  I was planning 
on adding a bunch of types and/or tasks which would allow classpaths and such 
to be specified in terms of optional packages.  There were 2 things in 

* A FileList (i.e. <path>) implementation which evaluates to the jar for an 
optional package.  This would be useable anywhere a regular <path> could be 
(including other paths):

        <library-path name="some.extension" version="1.0"/>

* A polymorphic classloader type, which would be used to provide a classloader 
to tasks like <java>, or <typedef>, or whatever.  One of the implementations 
would allow the classloader for an optional package to be used:

<java classname="SomeClass">
    <library-classloader name="some.extension" version="1.0"/>

Regardless of how this ends up looking, if we can push as much of the 
pluggability behind ExtensionManager, then myrmidon can take advantage of it 

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

The DTD isn't completely fixed - there's a few places where you can add 
whatever ant tasks you want.  Even so, the plan wasn't really to come up with 
a completely general project descriptor, just what we need for myrmidon.

What I would eventually like to end up with is a handful of different project 
file DTDs, and include project builders for each of them in the myrmidon 
distribution.  Plus, of course the native myrmidon and ant1 project builders. 
Basically a library of project templates, some tailored to specific problems, 
others more general.  The fact that a project builder can be loaded from an 
antlib makes this easy to do, and we can (potentially) distribute all kinds 
of odd project builders, without tieing them to the core.

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

Sure.  My xslt skills aren't as flash as they should be, so I'll stick to dvsl 
for the time being.


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

View raw message