You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Jon Scott Stevens <jo...@latchkey.com> on 2002/03/23 00:33:54 UTC
[PATCH] beanutils build system
Included is a patch for the beanutils build system so that it will build out
of the box without having to mv build.properties.sample to build.properties.
It removes the build.properties.sample file and adds it as
default.properties.
It basically implements a build system similar to Lucene, Scarab, Turbine,
etc...please apply it.
Also, please note that I'm getting a compile warning...
compile:
[javac] Compiling 29 source files to
/Users/jon/checkout/jakarta-commons/beanutils/target/classes
[javac]
[javac] Issued 1 semantic warning compiling
"/Users/jon/checkout/jakarta-commons/beanutils/src/java/org/apache/commons/b
eanutils/BeanUtils.java":
[javac]
[javac] 92. public class BeanUtils {
[javac] <------->
[javac] *** Warning: Method "java.lang.String
capitalize(java.lang.String $1);" in class
"org/apache/commons/beanutils/MappedPropertyDescriptor" does not override
the corresponding method with default access in class
"java/beans/PropertyDescriptor".
[copy] Copying 1 file to
/Users/jon/checkout/jakarta-commons/beanutils/target/classes
When I went to look at the MappedPropertyDescriptor.java class in order to
fix the compile warning, it looks like the linefeeds in the file are also
screwed up so I decided to let someone fix that first.
-jon
Re: [PATCH] beanutils build system
Posted by Jon Scott Stevens <jo...@latchkey.com>.
on 3/24/02 8:12 PM, "Jeff Turner" <je...@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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] beanutils build system
Posted by Jeff Turner <je...@socialchange.net.au>.
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
- 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.
- 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
- Your ~/build.properties must be sourced first, or it's pretty
useless.
Correct?
That may sound bleeding obvious, but I can tell you it's not obvious if
you've spent years with the other system.
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.
> >> 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).
Ah yes.. I must have sounded dense.
> > There is no reason why the two systems can't
> > exist simultaneously. It just takes some compromise.
>
> Sure...
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.
--Jeff
>
> -jon
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] beanutils build system
Posted by Jon Scott Stevens <jo...@latchkey.com>.
on 3/24/02 5:48 PM, "Jeff Turner" <je...@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" <je...@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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] beanutils build system
Posted by Jeff Turner <je...@socialchange.net.au>.
On Sun, Mar 24, 2002 at 04:45:25PM -0800, Jon Scott Stevens wrote:
> on 3/22/02 9:46 PM, "Jeff Turner" <je...@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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] beanutils build system
Posted by Jon Scott Stevens <jo...@latchkey.com>.
on 3/22/02 9:46 PM, "Jeff Turner" <je...@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 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.
> 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
> 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)...
./activation-1.0.1.jar
./commons-beanutils.jar
./commons-codec-1.0-dev.jar
./commons-collections.jar
./commons-digester-1.1.jar
./commons-email-0.1-dev.jar
./commons-http.jar
./commons-io.jar
./commons-lang-1.0-dev.jar
./commons-logging-20020321.jar
./commons-util-1.0-rc2-dev.jar
./dom4j-full-1.3.jar
./flux-3.0-dev.jar
./fulcrum-1.0.jar
./jakarta-regexp-1.3-dev.jar
./JavaGroups-2.0.jar
./jdbc2_0-stdext.jar
./junit-3.7.jar
./log4j-1.1.3.jar
./lucene-1.2-rc4.jar
./mail-1.2.jar
./mm.mysql-2.0.11-bin.jar
./postgresql-7.2.jar
./servlet-2.2-CVSHEAD-12-04-00.jar
./stratum-1.0-b2-dev.jar
./turbine-3.0-dev.jar
./velocity-1.3-rc1.jar
./village-1.5.2.jar
./xalan-2.1.0.jar
./xerces-1.4.4.jar
./xmlParserAPIs-2.0.0.jar
-jon
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] beanutils build system
Posted by Jeff Turner <je...@socialchange.net.au>.
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" />
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.
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.
If we're all happy with this, the change should be done to all projects,
not just beanutils (yes I volunteer).
--Jeff
On Fri, Mar 22, 2002 at 03:33:54PM -0800, Jon Scott Stevens wrote:
> Included is a patch for the beanutils build system so that it will build out
> of the box without having to mv build.properties.sample to build.properties.
> It removes the build.properties.sample file and adds it as
> default.properties.
>
> It basically implements a build system similar to Lucene, Scarab, Turbine,
> etc...please apply it.
>
...
> -jon
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] beanutils build system
Posted by Jeff Turner <je...@socialchange.net.au>.
On Tue, Mar 26, 2002 at 12:17:11AM -0800, Jon Scott Stevens wrote:
> Someone going to apply my patch?
It would break a lot of people's systems. Even if they are ignorant and
unenlightened people declining to follow the One True Path ;P So it
deserves a [vote]. Which will generate lots of heat, little light, and
probably a few -1's. To avoid that, here's a possible technical
compromise:
The ordering problem is unsolvable; either way, it screws one group of
users. One solution is to adopt a two-pass system. A ~/pre.properties
for things like ${lib.repo}, and a ~/post.properties for declaring
properties not overridden by ./build.properties. You symlink
~/build.properties to ~/pre.properties, I'll symlink it to
~/post.properties.
<property file="${user.home}/pre.properties" />
<property file="build.properties" />
<property file="project.properties" />
<property file="${user.home}/post.properties" />
Does it sound workable?
--Jeff
> -jon
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] beanutils build system
Posted by Jon Scott Stevens <jo...@latchkey.com>.
Someone going to apply my patch?
-jon
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>