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 02:06:50 GMT
on 3/24/02 5:48 PM, "Jeff Turner" <jeff@socialchange.net.au> wrote:

> On Sun, Mar 24, 2002 at 04:45:25PM -0800, Jon Scott Stevens wrote:
>> on 3/22/02 9:46 PM, "Jeff Turner" <jeff@socialchange.net.au> wrote:
>> 
>>> Hi Jon,
>>> 
>>> Would you be happy (ie, would it build on your system) if we applied the
>>> patch with the following modifications?
>>> 
>>> 1) Source ${basedir}/build.properties before
>>> ${user.home}/build.properties
>>> 
>>> Many people have a ~/build.properties with default values, which only
>>> needs to be overridden by ./build.properties for unusual cases. Changing
>>> the order breaks these people's setups. So I'm proposing that the order
>>> be:
>>> 
>>> <property file="${basedir}/build.properties" />
>>> <property file="${user.home}/beanutils.build.properties" />
>>> <property file="${user.home}/build.properties" />
>>> <property file="${basedir}/default.properties" />
>> 
>> -1. The order that I have it in is done on purpose and has worked well for a
>> long time for Scarab, Turbine, Lucene, etc.
> 
> The existing order is also done on purpose, and has worked well for a
> long time for Tomcat, Struts, Commons, etc.
> 
>> The point is that the ~/build.properties is like a globally defined
>> set of props.
>> 
>> I don't see how changing the order would break people's setups.
> 
> Re-read the explanation above, or re-read Craig's posts when this very
> subject arose last year. If you really want, I can spell it out.
> 
> Either way, take it as given that changing the order does irrevocably
> break some people's setups.
> 
> I'm asking not whether you *prefer* the new order for aethetic reasons,
> but whether it will *work*. Can you provide a concrete example where the
> existing order causes problems?

Craig's posts last time didn't make sense to me either. I personally keep my
build system as simple as possible. I don't define a few things in my
~/build.properties.

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.

>>> 2) Not delete build.properties.sample. Ie, defaults.properties will
>>> default the values to ${lib.repo}/.., but people without a jar
>>> repository can still 'cp build.properties.sample build.properties' and
>>> have things working.
>> 
>> -1
>> 
>> If anything you should do:
>> 
>> cp default.properties build.properties
> 
> Somewhere we need all the stuff currently in build.properties.sample. It
> can live in default.properties if you like. Might be cleaner in
> build.properties.sample.

Look at my diff more closely. ALL of the properties are in
default.properties. Essentially, default.properties ==
build.properties.sample. default.properties is just a better name and also
prevents people from having to do a cp just to use the build system (which I
find terribly annoying).

> The current system works quite well for some people.

It may work, but it is a real pain in the ass to use. It is incredibly lame
to require people to do a cp or define all of the .jar files in advance in
order to build things.

> A maven-like system
> works well for others.

The system I'm proposing has nothing to do with Maven. Maven came long after
it...

> There is no reason why the two systems can't
> exist simultaneously. It just takes some compromise.

Sure...

-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