ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: ant for and foreach tasks use them or not
Date Mon, 12 Jan 2009 16:10:00 GMT
On 2009-01-12, Francis Galiegue <> wrote:

> Le lundi 12 janvier 2009, Stefan Bodewig a écrit :
>> On 2009-01-12, Francis Galiegue <> wrote:

>>> The more it goes, the more I'm skeptical about this "different development
>>> model" schism between ant and ant-contrib.

>> Ant == community driven ASF project
>> ant-contrib == "benevolent dictator" style project with external
>>                contributions

> Well, err, every community has a "benevolent dictator" ultimately, doesn't
> it? :p Even if this "benevolent dictator" happens to be a committee. No
> offense meant ;)

In the ASF's case the "dictator" is "all of the committers" with no
single committer having more impact on the project than any other.
That's quite different from ant-contrib.

>> IP could be an issue since the ant-contrib project (like most any
>> open source project outside the bigger foundations) accepted
>> patches without asking for proper legaleese - I'm not blaming
>> ant-contrib, this is how most projects do it.

> OK, I can understand that. But is the original ant-contrib creator/current
> maintainer reachable at all? Does its current license ask that the
> contributors be named verbatim, or is a "project-wide" courtesy enough to
> include the code?

That's not the point.  It is about "yes, I was allowed to contribute
the code and as far as I know it is free from third party rights and
no, my employer doesn't own it either" which is needed from every
single contributor.  Ever.

>> The problem (if there really is one) is two-sided.

>> On the one hand ant-contrib contains some tasks that would never ever
>> make it into Ant because they are in direct violation of the Ant
>> developer's design decisions (<var>)

> I really don't understand the first point. It is very, very limiting. Heck,
> even make allows "variables" to be redefined along the way (provided you
> prefix their initial declaration appropriately), so why can't ant do it?
> What motivated this restriction in the first place? 

Because mutability destroys the declarative nature of build files.

In many cases, if not all, it is entirely possible to live without
mutable properties (even though I've written several of the ant-conrib
tasks myself, I've never used a single one of them outside of
ant-contrib's unit tests).

Ant trunk's scoped properties are going to solve many of the remaining
issues (like having to reinvent property names in macros).

> I cannot source an external property file if a property has already
> been defined before!

Sure you can, you just have to do things in the opposite order.  With
Ant properties the first definition wins, with mutable variables the
last one wins, either approach has drawbacks.

>> and on the other hand code from ant-contrib needed to be properly
>> contributed to the ASF, which involves having people sign paper
>> work that you may not know how to reach.

> As to the second point... Paperwork. Ugh. OK, I don't know about
> this, but (pardon me for being somewhat crude) it sounds
> ludicrous. Is it _really_ needed?


For every bit of code released by the ASF you get a promise (in fact
more than that) that it is free of third party IP as far as the ASF is
aware.  So any contribution has to be covered by a signed contributors
agreement (which states "my contribution is/will be clean").

>> Personally I'd prefer to see ant-contrib do a release and have people
>> use that over forking ant-contrib anywhere.

> Is there anything at all, right now, preventing the Ant developer
> community from salvaging ant-contrib's code?

Apart from IP paper work, there is time and effort.  I don't think
there is a single Ant developer currently who feels the code needs to
be salvaged urgently - or at all.  It is out there for people who want
to use it.

There are so many other things that look way more interesting to do,
you know 8-)


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

View raw message