commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [logging] please check release candidate 1
Date Sun, 29 Jan 2006 17:02:14 GMT
On 1/24/06, robert burrell donkin <robertburrelldonkin@blueyonder.co.uk> wrote:
> On Tue, 2006-01-24 at 22:35 +0100, Dennis Lundberg wrote:
> > robert burrell donkin wrote:
> > > On Wed, 2006-01-25 at 09:35 +1300, Simon Kitching wrote:
> > >> On Tue, 2006-01-24 at 18:39 +0000, robert burrell donkin wrote:
> > >>> On Tue, 2006-01-24 at 12:14 +1300, Simon Kitching wrote:
> > >>>> Why is it necessary to use two different JVMs?
> > >>> need a 1.4 JVM to compile the java.util stuff but the rest of the code
> > >>> needs to run fine on earlier JVMs.
> > >>>
> > >>> javac settings will care of the differences in class formats but changes
> > >>> to the system libraries mean that you should compile against the 1.2
> > >>> java system libraries. this can be done either by using a 1.2 JSDK
or by
> > >>> using a later JSDK and setting bootclasspath appropriately.
> > >>>
> > >>> if we were confident that our unit tests had 100% code coverage then
> > >>> compiling with a 1.4 JSDK would probably be safe enough. i'm not that
> > >>> confident and every other JCL release i've cut has used 2 JSDKs. so,
i'm
> > >>> more confident to use the system i know works.
> > >> Ok, sounds entirely reasonable. I agree there are corner cases where
> > >> target doesn't solve the problem (eg the new StringBuffer overloaded
> > >> methods in more recent JVMs).
> > >>
> > >> It might be nice to note this somewhere, eg as a comment in the
> > >> build.xml file or similar.
> > >
> > > the latest build.xml now supports dual compilation (1.2 and 1.4). the
> > > ant task should be run by a 1.2 JDK and a build.property set the a 1.4
> > > compiler. there's some documentation but i hope to return to this later
> > > (unless anyone else beats me to it).
> > >
> > > i'm now trying to think about whether to add a task to build the source
> > > distributions. one advantage is that it would automatically standardise
> > > the EOLs. one disadvantage is that it would require using exec to call
> > > svn directly. another is that it should really be loaded from a tag
> > > which would mean another build property.
> >
> > Robert, why would you need to use svn? If you are adding this to easy
> > the creating of RC:s and releases, then I would imagine that the release
> > manager has already checked out the correct tag from svn. If that is the
> > case then the source is already checked out as well, you just need to
> > package it.
>
> it's best to export a fresh copy from the tag. a couple of reasons:
>
> 1 this ensures that no svn meta-data is present
> 2 it ensure that no temporary files used when building the release are
> left in the source distribution
>
> i'll probably just use svn, i think. svn export --native-eols=XXX should
> do the line ending conversions automatically.

This is better, IMHO than applying conversion in scripts, since it
will make the distros independent of the OS platform used to do the
build.  It would be nice if maven did this by default when creating
source distros.

Phil

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


Mime
View raw message