ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: [VOTE] vote on general direction, details will be discussed later
Date Sun, 25 Mar 2001 13:29:17 GMT
At 11:04  25/3/01 +1000, Conor MacNeill wrote:
>It is interesting to see you arguing strongly against the Commons project

Actually I was one of the original people who were arguing strongly for it
in the begining. If you look across the library/ant/avalon/james lists you
will I was arguing for many of the same features of commons. It was only
later when they wanted centralized control rather than distributed control
that I argued against it ;)

>but you seem to be arguing for Ant to become like the Commons. 

partially. Thou I would argue for every project to embrace some of the
features of commons ;)

>I don't see Ant being some sort of library for other projects. I'm all for
reuse but
>perhaps the way to go would be to take those things from Ant into something
>like the Commons as reusable bits. After all most tasks will be strongly
>coupled into the Ant core and thus will require the ant.core to come along
>as well.

I don't see that at all. Almost all the ant tasks will access the ant
engine/runtime whatever through a small interface (say 4-5 classes). The
may rely on particular utility classes (maybe as many as 20). So all in all
it will be a small bundle (say two small jars - one for taskapi and one for
support util) plus any tasks that they want to use.

>> Monolithic jars make it hard to pick and choose tasks to include in these
>> sorts of environments.
>That isn't really true.

You really think so? I disagree for two main reasons.
* Perception
* No forced separation of concerns

Perception - Many people will not use avalon/turbine components because
they perceive they have to use the whole framework to use the components
regardless of whether or not this is the case.

No forced separation of concerns - Break the jars up and you are forced to
separate out the tasks so that there is not a mass of interwoven
dependencies. It will soon be obvious (ie when jar 1 depends on jar 2 and
vice versa) where you have too tight a coupling and need to do some work.
We did that over at Avalon and it helped identify a lot of problems that
were not obvious before hand.



| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |

View raw message