commons-dev mailing list archives

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

> On Sun, Mar 24, 2002 at 06:06:50PM -0800, Jon Scott Stevens wrote:
>> 
>> If you let the ./build.properties have precedence over the
>> ~/build.properties, then for example, if someone does a:
>> 
>> cp default.properties build.properties
>> 
>> Then they will have to go in and remove anything that is defined in their
>> ./build.properties 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 default.properties

Right.

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

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

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

RIGHT!

> - Your ~/build.properties 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
> build.properties.sample, 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
file. 

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?

-jon


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message