[Qt-jambi-interest] [RFC PATCH 0/5] Goodbye Version.java

[Francis Galiegue]

On Sun, Dec 27, 2009 at 7:38 PM, Raymond Martin <laseray at gmail.com> wrote:
> On December 27, 2009 12:44:57 pm Francis Galiegue wrote:
[...]
>
> Getting rid of the hardcoded version for a  .properties file is not necessarily
> the best way to go. Whether you have a .java or .properties file with the
> version stuff in it almost amounts to the same thing.
>

Well, no: since it is now a simple property file, is it directly
usable by ant _and_ Java code. With the version hardcoded into a Java
file, I cannot check whether the Qt version I try to build again is
compatible at all, unless I compile that code and run it. Tough.

> Did you consider putting the version information into the Ant build.xml as
> properties and having them inserted into the manifest as attributes?
>

No, that's even worse. Think merge conflicts. With a single
version.properties file, this is much less likely to happen.

I agree, though, that there are too many property files at the moment.
But I'm working on that ;)

> Then you can use the java jar utilities to read the attributes directly and
> you do not need another file laying around.
>
> For instance, a little excerpt of a build.xml:
>
>  <property name="devel"          value="false" />
>  <property name="build"          value="${build.date}" />
>  <property name="major"          value="1.0" />
>  <property name="minor"          value="M3" />
>  <property name="update"         value="1" />
>  <property name="version"        value="${major}.${minor}" />
>  <property name="version.update" value="${version}.${update}" />
>  <property name="version.build"  value="${version.update}-${build}" />
>  <property name="applicationjar" value="omegatplus.jar" />
>

This is exactly what I want to avoid when it comes to build.xml. If
properties are bound to change over time, they should be in property
files, not in the build.xml. A build.xml contains the build mechanism,
it is no data file. At least, that's how I see it.

However, this is interesting:

>  <!-- automatically build/update the manifest file -->
>  <target name="manifest" description="Create manifest">
>    <manifest file="MANIFEST.MF" mode="update">
>      <attribute name="Built-By"       value="${user.name}" />
>      <attribute name="Version"        value="${version}" />
>      <attribute name="Update"         value="${update}" />
>      <attribute name="Build"          value="${build}" />
>      <attribute name="ApplicationJar" value="${applicationjar}" />
>      <attribute name="Devel"          value="${devel}" />
>      <attribute name="Main-Class"     value="omegatplus.OmegaTPlus" />
>      <attribute name="Class-Path"     value="lib/liquidlnf.jar images/" />
>      <attribute name="License"        value="GPL"/>
>    </manifest>
>  </target>
>

if I can build the manifest file once and for all and include it in
all the jars, it makes a lot of sense. I didn't know about that task.

> With some associated utility code:
>
>  /**
>   *  Name of the OmegaT+ Jar file
>   *  Used to calculate the installation directory, etc.
>   */
>  final public static String APPLICATIONJAR = "omegatplus.jar";
>  final public static File APPLICATIONJARPATH =
>    new File( installDir() + File.separator + APPLICATIONJAR );
>
>  public static Attributes readManifest()
>  {
>    Manifest manifest = null;
>
>    try
>    {
>      JarFile jar = new JarFile( APPLICATIONJARPATH );
>      manifest = jar.getManifest();
>    }
>    catch( IOException e )
>    {
>      log.error( "Cannot read jar-file manifest: " + e.getMessage(), e );
>    }
>
>    if( manifest == null ) return( null );
>
>    return( manifest.getMainAttributes() );
>  }
>
>  final public static Attributes attribs = readManifest();
>
>  final public static String attrBuiltBy    = attribs.getValue( "Built-By" );
>  final public static String attrVersion    = attribs.getValue( "Version" );
>  final public static String attrBuild      = attribs.getValue( "Build" );
>  final public static String attrUpdate     = attribs.getValue( "Update" );
>  final public static String attrDevel      = attribs.getValue( "Devel" );
>  final public static String attrMain       = attribs.getValue( "Main-Class" );
>  final public static String attrClassPath  = attribs.getValue( "Class-Path" );
>  final public static String attrLicense    = attribs.getValue( "License" );
>

Again, we diverge. I avoid anything build or install related in code.
You need to compile that code and therefore call the build system to
compile it. Why not have the build system do it all in this case? ;)

-- 
Francis Galiegue, fgaliegue at gmail.com
"It seems obvious [...] that at least some 'business intelligence'
tools invest so much intelligence on the business side that they have
nothing left for generating SQL queries" (Stéphane Faroult, in "The
Art of SQL", ISBN 0-596-00894-5)