Re: Here is my Centipede scepticism

Mats Henricson wrote, On 08/06/2003 8.04:

> Nicola Ken Barozzi wrote:
> 
>> Mats Henricson wrote, On 07/06/2003 1.41:
>>
>>> Now your team members also need to learn Centipede, and
>>> you claim that is an improvement?
>>
>>
>> Centipede is not to learn. It's an Ant task that uses the Gump 
>> descriptor. What do you have to learn?
> 
> The Gump descriptor, for example. Plus the Centipede task.

Well, the Gump descriptor is basically the center for the reuse.
A project usually has a .properties file, and in this case it's in xml 
and is structured. The main advantage of using this is for multi-project 
builds.

As for the Centipede task, there is not much to learn. It's much easier 
than any other Ant task.

>>> But, that was what I tried to explain in my original
>>> email, my javadoc ant target needs tweaking anyway.
>>> And so would most other targets anyway. So, what have
>>> you gained? Nothing, it seems to me. On the contrary,
>>> since you've forced your co-workers to use something
>>> that wasn't necessary.
>>
>>
>> Forced? You *can* use it, or not use it.
> 
> Of course, but what I mean is that in every environment
> where you introduce Centipede you are adding complexity,
> since Centipede is non-trivial.

Which is a problem for us. Centipede *must* be trivial, and it was. We 
have acknowleged that it looks complex without being it actually, so we 
are trying to change based on user input. On the dev list you can find 
the details about the latest decisions.

> That means that for it
> to be meaningful to use Centipeded, it must remove some
> complexity somewhere else.
> 
> And this is the main idea with it all, right? Centipede
> will reduce the complexity of you ant build scripts,
> since it uses reusable cents.

Not only. Also because it will remove the jar download hell by 
downloading jars and the dependency hell by doing multi-project builds.
These are equally important, if not more.

> My claim is that it doesn't work! I can't use your javadoc
> cent, since it doesn't do what I want. I can't use your
> JUnit cent (I assume there is such a thing) since it can't
> possibly know the names of the JUnit classes I want to
> run.

Well, the rule is the 80-20: do 80% of what you need with 20% the 
complexity. If the javadoc task does not do what you want, then it means 
that we have to make it better, so RFEs are welcome.
As for the Junit one, it uses filename conventions to find the tests.

>> Cents are like Ant tasks, you use them if you need them.
> 
> Well, I need them, but I can't use them.

Which is a pity. Please resist and persist, I'm sure we will make them 
ok for you :-)

>>>>     2. It is trying to automate/simplify something
>>>>         that is always going to have to be customized
>>>>         by hand.
>>>>
>>>> Sounds like an argument against other build tools, not Centipede. 
>>>> Centibuild
>>>> is just ant w/ optional imports. You want your hand crafted ant 
>>>> script, then
>>>> paste it in. Centipede compliments ant w/ some metadata parsing into
>>>> properties, w/ optional/re-usable scriptlets, it doesn't stop you 
>>>> from using
>>>> plain ant.
>>>
>>> It is NOT just adding something without the cost, since
>>> it requires your co-workers to learn yet another tool,
>>> when ant in most cases is just fine.
>>
>> In most small projects it's easy to start. But then imagine to have to 
>> manage 20 projects, each with their own buildfile changes, and have 
>> them compile every time, with the defined libraries...
> 
> Yes, I agree, this is a complex task, and I do not have
> much experience in maintaining such environments.

Keep in mind that our user are
1 - multi-project builders
2 - users that don't have particular needs and don't want to learn much 
of Ant

You are in between, and correctly see diminishing returns. We have not 
addressed your user-type much, but I'll be happy to.

>> Centipede is an Ant task. That can make "antlibs" that contain both 
>> tasks and prepackaged targets.
>>
>> If you don't want use target libraries and don't want to have 
>> autodownload of jars and don't want to have common properties in a 
>> common descriptor, fine. Then you don't need Centipede.
> 
> Autodownload of jars sounds scary to me, but I'm sure it
> solves real problems in real environments.

Well, not scary, it just gets the jars for you instead of going to all 
the sites to get them by hand. It also reduces CVS bandwidth problems, 
that are to be remembered, especially for Apache and other OS sites.

> So, does this mean that Centipede is mostly useful in
> really complex environments, but overkill for smaller
> projects?

It's really useful in really complex environments and in really simple 
ones (ideally only write the decriptor and the cents to use).
For in-between uses it's not *so* compelling, but as soon as you will 
move into more complex builds, you will start seeing returns.

> After re-reading my text above it seems clear to me that
> what I have most problems with are the reusable cents.
> I can't see how they can possibly work. Centipede seems
> to be much more than just reusable cents however, of
> which I know nothing.

Probably because you don't have those needs, as it seems from your mails.

So let's focus on your cent "problems". What I'm still a bit confused 
about is the fact that you don't see how they can work, but still would 
like to have them work... what would you *really* like? What do you have 
in mind about what they should do for you?

Thanks :-)

-- 
Nicola Ken Barozzi                   [email protected]
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------



-------------------------------------------------------
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.