ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ara Abrahamian" <>
Subject RE: Object oriented builds [was Mutant Documentation]
Date Sun, 23 Jun 2002 18:27:58 GMT
What do you guys think of making Target behave like a Task? I mean
introduce a reusable JavaCTarget class, initialize it and put it in
build.xml. A javac-target.xml will back this "target component".

One thing I like in Tapestry framework is how it manages its web
components. Say you have to display a contact list in two screens. You
define a ContactListComponent class, define its formal parameters and
all its in/out bindings/etc in a xmlish ContactListComponent.jwc, the
html body of this component is in a ContactListComponent.html file with
reference to setups in jwc file.

Now take a look at it from an Ant perspective: we can define reusable
JavaCTargetComponent class which has some bean properties, in/out,
expected dependency definitions and stuff like those. Which tasks it
executes is defined in JavaCTargetComponent.atc (ant target component)
file. Since we're not generating an html like output we don't need
another html (template) file. We can do very interesting stuff imho with
these kinds of code+atc combination. JavaCTargetComponent can define a
well defined DependChecker interface, or many other useful extension

Is the above scenario completely stupid or relevant? Maybe Maven does it
already? :-)

Also another thing I love to see is Ant moving to a real javabean
design. Let me define my project in say jbuilder via visual composition
:-) Funny isn't it? But why not? Some projects are so complicated you
really can't live without extensive control over each step involved, and
what's better than java and javabeans for handling it?


> -----Original Message-----
> From: Adam Murdoch []
> Sent: Sunday, June 23, 2002 9:15 AM
> To: Ant Developers List
> Subject: Re: Object oriented builds [was Mutant Documentation]
> On Sun, 23 Jun 2002 13:45, Erik Hatcher wrote:
> > Does the object-oriented nature of this include being able to
> > tasks or projects?  I'm thinking at the API level now, not the XML
> > representation. What I'd like to do is create a StandardJavaProject
> project
> > which does all the basic stuff like init, clean, compile, jar, and
> javadoc.
> >  In slightly more advanced projects, I might want to use a
> XDocletProject,
> > where all stays the same except a new "gensrc" target is added and
> > compile target is modified to depend on it and add the generated
> > directory to the compile and javadoc stage.  Does that make sense?
> >
> > My questions are for both Mutant and Myrmidon - do either or both of
> them
> > address this type of idea?  If so, could you elaborate on this
> There's some support for this in myrmidon, at the API level.  You do
> by
> providing your own ProjectBuilder implementation.  The ProjectBuilder
> responsible for building a Project object from a project file (a
> is
> basically just a set of named Targets).
> You can use a custom ProjectBuilder to do things like:
> - Run the project file through a transformation, before handing it off
> the
> standard ProjectBuilder.
> - Do your own parsing, and assemble the Project object yourself.
> - Provide your own Project implementation.
> - Swap in your own target implementation.
> ProjectBuilders are loaded from antlibs just like any other type, so
> installing them is very easy.
> Also, they fit in nicely with the inter-project dependency stuff, so
> you
> can mix projects of different types together, and have dependencies
> between
> them.  For example, you could have an ant2 project that depends on an
> project, and a StandardJavaProject.
> But regardless of how it happens, having a library of high-level
> projects, to use and customise ("extend"), is a great idea.
> --
> Adam
> --
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message