ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran" <>
Subject Re: CET494 and Ant
Date Thu, 20 Dec 2001 21:19:17 GMT

Hi Harry,

Messing with ant internals is somewhat a sensitive area, because there is a
such a risk of breaking things. Now that ant is the de-facto build tool for
all open source and many closed source java projects, we are somewhat
constrained by the fear of breaking everyone elses code. Sometimes we do
this accidentally, but the big nightly build of everything, GUMP, usually
lets us know -unless it is some subtle change that only shows up later.

There is, however a major refactoring being planned, Ant 1.9, which will
rework the engine in a way which will lead to the next major release of ant,
which is not going to be backwards compatible with the old one.

All the discussion is on the ant-dev mail list; much of the documentation is
on the web site, but it really lives on the apache CVS tree as the
jakarta-ant project. There, in the folder docs/ant2 is the current feature
set intended for ant 2 (by vote, using the apache voting rules that give
committers veto rights, a bit like the UN Security council only more

I would pull down the CVS tree, and look at docs/ant2/actionlist.html, which
is the outline of things to do for ant1.9, and see if there is something
your students want to take off that list. Some of the problems there are
quite 'interesting', such as colouring and an embeddor API


----- Original Message -----
From: "Harry Koehnemann" <>
To: "Steve Loughran" <>
Sent: Thursday, December 20, 2001 6:49 AM
Subject: Re: CET494 and Ant

> Hi Steve,
> Thanks for the reply.  The course ran last semester and we used a
> different project.  But, it is running again next semester and has
> become rather popular so I suspect it will run every semester for the
> foreseeable future.  I would love to take a group or two and have them
> work on ant.  I agree you absolutely should only accept student
> submissions if they meet all your criteria and hopefully that is the
> student's motivation.
> Since it's a semster-long team project the work should be reasonably
> substantial.  I'd like to have them enhance ant's internals instead of
> simply modifying/adding tasks.  What work is on your group's list?  Do
> you manage requirements - feature list, user stories?  Also, any
> documentation on ant's design/architecture?  If student's produce some,
> would it be interesting to you?  It would probably be UML-based.
> Regards,
> Harry.
> Steve Loughran wrote:
> >
> > Hello,
> >
> > We on ant-dev are very intruiged by giving student assignments of
changes to
> > Ant, with bonus points for submissions. Is the course ongoing? Have they
> > made any submissions. We havent seen any, but then we havent been
> > Now that we are aware of the course we have an interesting little
> > dilemma: should we accept all submissions from the students, or reject
> > Probably we will be rigorous and accept them if they a) add something of
> > value, b) dont create maintenance nightmares in future and c) they
> > the ant task guidelines
> > and come with
> > tests and documentation. If they meet those criteria the team can use XP
> > the latest ISO working draft of the Z notation as a basis for
> > it doesnt matter.
> >
> > Regarding the coursework, here are my opinions:
> >
> > 1. add an m option to jar task to not create a manifest
> > -we call this <zip>; class jar extends zip and adds the manifest
> >
> > 2. add a jar option to java task to take a jar file.
> > -already done; the jar attribute of <java>
> >
> > 3. add filenames w/ wildcard to unjar and unzip commands
> > -already in there; they take a fileset as a nested element
> >
> > 4. add -n option to the ant command where ant tells what it will do
> > doing it
> >
> > -Ooh, that would be tricky. You'd need to edit every single task which
> > side effects and have it not generate them. Make has it easier as it is
> > which does the dependencies, rather than the programs it invokes. Ant's
> > tasks are more tightly coupled to the run time, and are pretty much
> > to execute.
> >
> > -Steve

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

View raw message