commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jon Scott Stevens <>
Subject Re: [PATCH] beanutils build system
Date Mon, 25 Mar 2002 04:23:28 GMT
on 3/24/02 8:12 PM, "Jeff Turner" <> wrote:

> On Sun, Mar 24, 2002 at 06:06:50PM -0800, Jon Scott Stevens wrote:
>> If you let the ./ have precedence over the
>> ~/, then for example, if someone does a:
>> cp
>> Then they will have to go in and remove anything that is defined in their
>> ./ in order to get any effect. I see that as a bad thing.
> Okay, let me see if I've got this right:
> - You have *all* project properties in


> - If you need to customize a jar property, you copy
>  to, edit, and therefore the
> value overrides the value.

You don't need to do the copy, you just define what you want in your give you several locations to define your in...including a project specific one...

> - If the jar properties in work for you (as they
>  most likely will with ${lib.repo}), then you don't have to do
>  anything


> - Your ~/ must be sourced first, or it's pretty
>  useless.

Right, because that is where ${lib.repo} is defined.

> That may sound bleeding obvious, but I can tell you it's not obvious if
> you've spent years with the other system.

Right, but what is obvious is that there is a much easier way of doing
things and years of working with broken systems has helped me (and others)
figure out better ways to do things...

Ant is a relatively new invention. I expect it to take some time to figure
out the best ways. This style of building is simply an advancement and will
take time to convince people. Just like it took time for people to
understand the usefulness of Gump.

> I certainly can't judge which system is better. If there were sensible
> ${lib.repo} defaults in build.xml, then you wouldn't have to copy
>, and the current system probably wouldn't annoy
> you nearly as much.

The point you are missing, which I stated earlier, is that a user or
developer should not have to look through a build.xml file in order to
understand things or figure out which jar's they need to override. I
absolutely hate the idea of storing user defined properties in a build.xml

Asking someone to look at the code in a build.xml file is like asking
someone to read a ./configure script.

> I'm sure there's some technical compromise. Need to think some more. If
> needs be, I'm personally happy to convert from override-by-exception to
> turbine-style, now I understand it.

I'm glad you are starting to see the light. :-)

Go grab Lucene or Scarab from CVS and build it. See how easy it is?


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

View raw message