Re: [jgrapht-developers] JGraphT backport

[John V. S. <js...@gm...>]

In line with Barak's suggestions below, I made the following changes:

- Instead of customBuild.properties, build.xml now reads 
etc/build.properties (if it exists).

- I created file etc/build.properties.template with the documented (but 
commented-out) property definitions in CVS.  In a distribution, this 
becomes etc/build.properties.  The reason I gave it a different name in 
CVS is to avoid developers accidentally editing it and committing 
site-specific changes.  Instead, developers should copy the template to 
etc/build.properties and edit that.  Distribution users can just edit 
etc/build.properties directly.

- I renamed the property from retro.jre.dir to jre1.4.dir

In addition, I also made a change to the jar naming convention.  The jar 
name used to be based on the release version, but I have found this to 
be a pain in dependent projects, because it means with every upgrade I 
have to edit the dependent build file to reference the new version. 
Instead, the jar names are now:

jgrapht-jdk1.4.jar (retrowoven version)
jgrapht-jdk1.5.jar (standard compile)

README.html explains when to use one or the other or both depending on 
your compile/deploy dependencies.

JVS

Barak Naveh wrote:
> Come to think of it, maybe it would be useful to extend the idea and instead
> of having 'customBuild.properties', we can have 'build.properties'.  Such a
> file might help with all kinds of custom of builds (release, cvstag,...),
> present and future.
> 
> The build.properties could have the form of commented sections, one section
> for each alternative build (one for retro).  When someone wants to build a
> retro, he just uncomments the params in the retro section and fills in the
> paths according to the documented instruction within the 'build.properties'
> itself.  In such a way, custom builds can be a no-brainer.  Of course, the
> file in its distributed form contains only comments, so that a casual "ant
> all" on the distribution doesn't do funny things...
> 
> 
> A little naming suggestion:
> 
> 
>>retro.jre.dir=/path/to/jre1.4
> 
> 
> Since the only JREs supported here are 1.4*, I think a variable name such as
> 'jre1_4.dir' or 'jre1.4.dir' will be more self-explanatory. 
> 
> Barak 
> 
> 
> 
>>-----Original Message-----
>>
>>The JGraphT development version (0.7.0alpha) in CVS requires JDK 1.5 to
>>build, but I've just checked in backport support to allow it to run on
>>JRE 1.4.  To use it, install Retroweaver (and JRE 1.4), then create a
>>file named customBuild.properties in the same directory as build.xml and
>>add these two lines:
>>
>>retroweaver.dir=/path/to/full/distribution/of/retroweaver
>>retro.jre.dir=/path/to/jre1.4
>>
>>Then run ant.  The "all" target will perform a normal build/test/jar
>>sequence, and then run the backport (overwriting the class files in
>>place with their retrowoven versions).  Then it will re-run all tests
>>against JRE 1.4 to make sure that no dependencies on JRE 1.5 have crept
>>in.  Finally, it will create an extra jar with the retrowoven classes as
>>part of the distribution.
>>
>>If you have comments on this process, please let me know.
>>
>>JVS
>>
>>
>>-------------------------------------------------------
>>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
>>from IBM. Find simple to follow Roadmaps, straightforward articles,
>>informative Webcasts and more! Get everything you need to get up to
>>speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
>>_______________________________________________
>>jgrapht-developers mailing list
>>jgr...@li...
>>https://lists.sourceforge.net/lists/listinfo/jgrapht-developers
> 
> 
> 
>