ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: [warning inflammatory email] Stagn-ant?
Date Tue, 09 Jul 2002 03:17:19 GMT
On Tue, 9 Jul 2002 wrote:

> [snip] 
> > If you want to develop an xml programming language - nothing can stop 
> you, 
> > but please don't call it ant ( or ant2 ).
> I wasn't planning on it....if I wanted to do that, I'd be working on 
> making Jelly and Jexl an ant replacement in earnest.

I doubt a scripting language will replace ant. Or that XML scripting
is a good use of XML, except for very limited things. 

> > I hope ant1.6 will get one of the current classloading / optional 
> > proposals - if not, then 1.7 will certainly do. 
> > I don't see anything technical to prevent doing that ( in a backward
> > compat. way ). Spending time on finding the best solution is good.
> Sure. All things come to he who waits. But 'finding the best solution' for 

In jakarta it is: 'all things come to he who _does_' :-)
And of course there are others who review and have different
opinions. The result should be a good solution. 

> > However tomcat is a complex project - and most things in the build.xml
> > are there because something needs them. I doubt ant ( or any other 
> > build tool ) could have all the tomcat needs covered ( and if it 
> > does, it'll be a very complex tool, since few projects need all that ).

> Tomcat is a complex project. But then again there are far more complex 
> projects out there too. But there are good bits of Tomcat's and Ant's 
> build files that never get seen or moved into a common place, and should 
> be.
> Other projects have jdk compilation dependencies too, and these should be 
> supported somehow in the base ant, rather than in every project.

I agree. We need more higher-level tasks for what is commonly used.

> > Gump running all the existing projects without error is the minimum.
> > ( that includes running all existing user-defined tasks in 
> > jakarta/xml/etc ).
> So that means:
> a) no API changes to the project/target/task/datatype
> b) must be able to run existing build files.
> Seems reasonable to me.

No backward incompatible API or DTD changes.

> > And no change just for the sake of changing ( like name changes, 
> > cosmetics, etc ).
> 'Name changes' are often very important and assist greatly in 
> understanding something. For example, if I were to keep referring to Ant 
> as Gump, people would get very confused.

And if you start renaming tag names or methods - even more people would
get confused. 

There is time before an official release to do all the 'cosmetic' name
changes on new tasks. Once the release is out and people start using
the names - all you can do is add better documentation.

Besides, everyone has a different taste - and we can add 'aliases'
if absolutely needed.


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

View raw message