Conor MacNeill <conor@cortexebusiness.com.au> wrote on 07/08/2002 03:29:20
PM:
> dion@multitask.com.au wrote:
> > Long Email Warning....
> >
> > I've spent some time this weekend reading up on the various proposals
for
> > Ant 2, and my first reaction is:
> >
> > 'Is Ant dead?'
>
> No :-)
>
> Ant1 continues quite strongly, I think, despite its limitations. I would
> say many (most?) build operations can be done with Ant the way it is.
Yep and most nails can be put in place with a hammer. Those screws though
are an interesting thing...
> > Ant 1.x has been around a very long time now, and some of the
proposals
> > have been around for more than a year. It seems that there is a
general
> > unwillingness to make a move forward.
>
> Unwillingness? Maybe. IMHO, I think the problem comes more from a lack
> of defined process for adopting a codebase. Is it by majority vote - is
> there a possibility for veto? If Ant2 is to progress I think the process
> should be defined but I am unsure as to how to agree the process :-( A
> timetable and acceptance criteria would be desirable.
Being an Ant committer, from my perspective it's all in your (and the
other's) hands. What to do with Ant2 has been an unconscious decision of
evolution since the proposals were put in place and not voted on. Reading
the requirements, they need a severe revisit.
For me an acceptable process would be that the committers decide to put
Ant 1.x into maintenance mode and choose what to do with the existing
proposals:
- Vote for one as the usurper
- Vote for neither, and migrate the functionality into Ant 1.x as
soon as possible
- Vote for both, and merge into a new proposal.
> > Proposals still seem to be heavily rooted in Ant 1.x terminology and
> > technology and offer some 'goodies' to the end user, but little as a
> > driving factor to move to something else is evident.
>
> Are you talking about the end-user visible features? This is probably
> true. I know Mutant tries to clean up the core so things can be
Yep, I'm thinking what does an Ant 2 user get that an Ant 1 user doesn't.
> packaged, installed, managed more easily without necessarily providing a
> huge range of new end-user features in the build files itself. My
> feeling was that those features would emerge once the core was cleaner.
I agree, they would emerge, if the core were being used on a wider scale.
> Anyway, I think we need to avoid
> http://www.tuxedo.org/~esr/jargon/jargon.html#second-system%20effect
> when providing "motivation for moving to something else".
>
> >
> > In the meantime, other projects have come along building on top of and
> > next to Ant (Jelly, Maven, Centipede etc), usurping what would seem to
be
> > Ant 2's territory.
> > These projects have no 'history' to deal with and can
> > freely move forward with new ideas and technologies, that the Ant team
> > seems reluctant to touch, e.g. scripting, backward compatibility etc.
>
> What do you mean "backward compatibility"? Ant1 is mired in backward
> compatability! As for scripting, I presume you mean script-like tasks
I mean breaking with backward compatibiliity.
> (<if>, <while>, etc) and not the <script> task itself. Is an XML based
> scripting language the way to go? I really don't know. It would
> certainly be convenient in cases. Things like <try>-<catch> should be
> there IMHO. The gradual addition of failonerror attributes to each task
> is just the wrong way to do it. OTOH, If you need that much logic, why
> not just go into Java or <script>? We have seen how <antcall> gets
> abused :-) It is a matter of where it is best to put complex build
> logic, I guess. I don't know the right answer.
Mostly not in the build file :) But simple things like looping and
conditional processing are very important., the if and unless just don't
cut it as the build gets bigger.
> > The current unspoken decision seems to be that none of the proposals
are
> > acceptable, and that the evolution of Ant 1 is the direction that will
be
> > taken, albeit at a slower pace than seems possible elsewhere.
>
> Previous discussions have suggested using Gump as a minimum acceptance
> criteria. I've certainly tried to have Mutant work effectively with
> Gump. Again the problem is not having an agreed process. Indefinite
> postponement seems to be easier than a decision.
But postponement really is a decision. As time goes by I've seen things
planned for Ant 2 move into Ant 1 and the core classloading and
optional/built-in issues get worse.
> > So is it time to revisit what the requirements are for Ant 2 (
> > http://jakarta.apache.org/ant/ant2/ ) ? What do users actually want?
To
> > write xml files and understand the oddities of history? Do people
believe
> > that developers want to write build files for small projects?
>
> I sense the suggestion that Ant is suitable for small projects only.
Definitely not, but looking at things like Tomcat's build file scares me
big time. The other thing is the sheer amount of duplication across build
files without standardisation, e.g. jdk1.2/3/4 compilation exclusion, on
vs offline etc.
> Could you elaborate?
My point above was that for simple java projects, a user may not need/want
a build file. Take for example the typical uni assignment: javac, jar,
javadoc etc all work off java source code. Being able to:
ant jar javadocs -Ddir=C:\source
and have it compile source, javadoc source and build a project.jar would
be nice for ease of adoption. Writing a build file for a simple project
means less visibility. How about generating a build file for the simple
case? etc.....
> With respect to "oddities of history", it is probably also worth asking
> what is the acceptable level of backward compatability breakage in
> moving from Ant1 to Ant2. For some people, no break is acceptable even
> across a major version number increment.
Embrace the change :) Ok, I'll bite... What is the acceptable level of
backward compatibility? Build file? API?
> > Personally, as a long time user of Ant 1.x, it's interesting reading
the
> > existing proposals and seeing how heavily we all have been influenced
by
> > some of the key concepts that Ant 1 used. After looking around, maybe
we
> > need to throw the bath water out and keep the baby, i.e. go back to
the
> > drawing board.
>
> Sure we can go back to the drawing board. Discussions are useful
> especially "off the wall" ideas. OTOH, I don't think we can have design
> by committee. It doesn't work very well.
100% agreed. For example, I'd like to remove the idea of properties being
a task, and untie them and the expression language Ant uses, similar to
then JSPTL idea.
> > For example, for a 'build' tool, having your top level
> > element as 'project' is an unusual choice.
>
> A rose by any other name ...
Yep, but the 'Project' model in the Ant 2 requirements and proposals is
really a build model. Gump has more of the 'project' model to it.
> > The expression language of Ant
> > is also an interesting point, as jexl and jsptl gain ground (?)
>
> I'm not sure where these are gaining ground. Can you give me a few
> pointers?
Gaining ground had a '?' because it was something that could happen as the
JSPTL becomes more common place.
> > Also, the
> > concept of 'tasks' and 'datatypes' - <sarcasm>could we get a little
more
> > generic?</sarcasm>
>
> I'm not sure your point here. These are pretty generic concepts so the
> names seem appropriate. What would you have?
Ok, sarcasm off :) Tasks == process == code. Datatypes == data. Right? So
a taskdef is supposedly the only way of telling ant about code to be
executed. It's a tad restrictive. Lots of code exists outside of Ant, and
it'd be good to be able to easily access that from within Ant instead of
having to create special Ant 'tasks'.
Datatypes are also similar, and represent generic java objects. Being able
to have them defined, but not be able to do anything with them except add
them to tasks is frustrating. How about accessing their properties, for
example.
> > This is not a wholesale swipe @ the current Ant team. I think they do
a
> > fantastic job. And I love Ant....
> >
> > I realise a lot of this has been said already, but it's been a long
time
> > since Ant2 has been mentioned seriously, and I personally feel that
Ant
> > itself has stagnated, and needs something/someone to poke an iron into
the
> > ashes to see if there's any fire left.
>
> I understand your frustration.
So, where to from here? Do the other committers feel like Ant 2's time is
nigh?
--
dIon Gillard, Multitask Consulting
Work: http://www.multitask.com.au
Developers: http://adslgateway.multitask.com.au/developers
|