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. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
