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