commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <j...@socialchange.net.au>
Subject Re: [PATCH] beanutils build system
Date Mon, 25 Mar 2002 01:48:03 GMT
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? 

> > 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.

> > I quite like the defaults.properties idea. Keeps build.xml clean, and
> > you don't lose your place in build.xml when looking up the value of a
> > property.
> 
> The whole point is that you don't have to look at build.xml to change
> properties. Much like you shouldn't have to look at a ./configure script.
> 
> > If we're all happy with this, the change should be done to all projects,
> > not just beanutils (yes I volunteer).
> 
> I have already started doing that for all of the projects that Scarab has a
> dependency on (which is quite a lot of projects at this point...31 .jar
> files)...
> 
...

The current system works quite well for some people. A maven-like system
works well for others. There is no reason why the two systems can't
exist simultaneously. It just takes some compromise.


--Jeff

> -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