Pivot
  1. Pivot
  2. PIVOT-746

Add API to return Version of Pivot retrieved from "build.properties"

    Details

    • Type: New Feature New Feature
    • Status: Resolved
    • Priority: Trivial Trivial
    • Resolution: Fixed
    • Affects Version/s: 2.0.1
    • Fix Version/s: 2.0.1
    • Component/s: wtk
    • Labels:
      None
    • Environment:
      Windows XP SP3, JDK 1.6.0_16

      Description

      Would be helpful to be able to determine programmatically what the version of Pivot is. The simplest method is to include "build.properties" which is the original source of this information in the packaged .jar files and then to provide an API to read and parse this value into a Version structure.

      1. version2.patch
        2 kB
        Roger Whitcomb
      2. pivot746_patch2.patch
        0.8 kB
        Sandro Martini
      3. version.patch
        2 kB
        Roger Whitcomb

        Activity

        Hide
        Roger Whitcomb added a comment -

        Here is a patch that implements this feature.

        Show
        Roger Whitcomb added a comment - Here is a patch that implements this feature.
        Hide
        Greg Brown added a comment -

        Patch applied. Thanks!

        Show
        Greg Brown added a comment - Patch applied. Thanks!
        Hide
        Andrei Pozolotin added a comment -

        few suggestions:

        1) this currently happens in pivot-wtk; should be in pivot-core;

        2) classloader should be PIVOT-742;

        thank you.

        Show
        Andrei Pozolotin added a comment - few suggestions: 1) this currently happens in pivot-wtk; should be in pivot-core; 2) classloader should be PIVOT-742 ; thank you.
        Hide
        Andrei Pozolotin added a comment -

        also: build.properties is reserved name in eclipse pde; I suggest pivot-build.properties instead

        Show
        Andrei Pozolotin added a comment - also: build.properties is reserved name in eclipse pde; I suggest pivot-build.properties instead
        Hide
        Roger Whitcomb added a comment -

        I was piggybacking on two things:
        1) ApplicationContext already has a getJVMVersion() method, so this is very similar – since ApplicationContext is in the "wtk" area, this is where it had to happen. However, I changed the generic <package macro, so actually the version file "build.properties" is embedded in all the .jar files.
        2) The "build.properties" file was already being used as the sole source for the Pivot version number, so I added nothing new. If the name needs to be changed for Eclipse, that is definitely outside the realm of this small change.

        AFAIK the classloader I'm using should be correct because it must load the build.properties from the same .jar file where the ApplicationContext.class file is located. Is there a problem with that in other environments??

        Thanks.

        Show
        Roger Whitcomb added a comment - I was piggybacking on two things: 1) ApplicationContext already has a getJVMVersion() method, so this is very similar – since ApplicationContext is in the "wtk" area, this is where it had to happen. However, I changed the generic <package macro, so actually the version file "build.properties" is embedded in all the .jar files. 2) The "build.properties" file was already being used as the sole source for the Pivot version number, so I added nothing new. If the name needs to be changed for Eclipse, that is definitely outside the realm of this small change. AFAIK the classloader I'm using should be correct because it must load the build.properties from the same .jar file where the ApplicationContext.class file is located. Is there a problem with that in other environments?? Thanks.
        Hide
        Greg Brown added a comment -

        Embedding the file in all JARs seems like the right thing to do, and the location of the method (in ApplicationContext) makes sense to me.

        FYI, I have used Eclipse for Pivot development since day one and the existence of the build.properties file has never been a problem.

        Show
        Greg Brown added a comment - Embedding the file in all JARs seems like the right thing to do, and the location of the method (in ApplicationContext) makes sense to me. FYI, I have used Eclipse for Pivot development since day one and the existence of the build.properties file has never been a problem.
        Hide
        Andrei Pozolotin added a comment -

        I know this is pointless, nonetheless

        re: "location of the method (in ApplicationContext) "
        I am sorry I was not clear: you already has version in core:
        public class Version implements Comparable<Version>, Serializable {
        why not provide singe static final field in core, which does parsing of build version
        and other build context information as you add more of it and expose it as Version or some new BuildInfo interface
        so nobody knows build.properties exists

        re: "since day one"
        try using pde: http://www.vogella.de/articles/EclipsePDEBuild/article.html#productbuild

        Show
        Andrei Pozolotin added a comment - I know this is pointless, nonetheless re: "location of the method (in ApplicationContext) " I am sorry I was not clear: you already has version in core: public class Version implements Comparable<Version>, Serializable { why not provide singe static final field in core, which does parsing of build version and other build context information as you add more of it and expose it as Version or some new BuildInfo interface so nobody knows build.properties exists re: "since day one" try using pde: http://www.vogella.de/articles/EclipsePDEBuild/article.html#productbuild
        Hide
        Greg Brown added a comment -

        > re: "location of the method (in ApplicationContext) "
        > I am sorry I was not clear: you already has version in core:
        > public class Version implements Comparable<Version>, Serializable {
        > why not provide singe static final field in core, which does parsing of build version

        Where would this field live? Certainly not in the Version class itself, since Version is a generic class representing a four-value revision number (in other words, it isn't specific to Pivot). I don't see any problem leaving it in ApplicationContext.

        > so nobody knows build.properties exists

        In the current implementation, only ApplicationContext needs to know about it. How would moving it to another class be any different?

        > try using pde: http://www.vogella.de/articles/EclipsePDEBuild/article.html#productbuild

        I have. How do you think the Pivot plugin was built?

        Show
        Greg Brown added a comment - > re: "location of the method (in ApplicationContext) " > I am sorry I was not clear: you already has version in core: > public class Version implements Comparable<Version>, Serializable { > why not provide singe static final field in core, which does parsing of build version Where would this field live? Certainly not in the Version class itself, since Version is a generic class representing a four-value revision number (in other words, it isn't specific to Pivot). I don't see any problem leaving it in ApplicationContext. > so nobody knows build.properties exists In the current implementation, only ApplicationContext needs to know about it. How would moving it to another class be any different? > try using pde: http://www.vogella.de/articles/EclipsePDEBuild/article.html#productbuild I have. How do you think the Pivot plugin was built?
        Hide
        Andrei Pozolotin added a comment -

        fine, you win!

        speaking of pivot plugin, any chance you can publish it as update site: PIVOT-711

        Show
        Andrei Pozolotin added a comment - fine, you win! speaking of pivot plugin, any chance you can publish it as update site: PIVOT-711
        Hide
        Greg Brown added a comment -

        That's not something I have time to tackle at the moment, but if you are willing to set it up I'd be happy to help if I can.

        Show
        Greg Brown added a comment - That's not something I have time to tackle at the moment, but if you are willing to set it up I'd be happy to help if I can.
        Hide
        Sandro Martini added a comment -

        Note that after this little change (in ApplicationContext) I'm no more able to run some bxml files from eclipse ... if the property file is not found probably I could have a warning in console, but without blocking the execution, ok ?

        For example, try to run "As Pivot script application": tests/ ... / multiple_selection_list.bxml , this is the result:
        java.lang.ExceptionInInitializerError
        Caused by: java.lang.NullPointerException
        at java.util.Properties$LineReader.readLine(Properties.java:418)
        at java.util.Properties.load0(Properties.java:337)
        at java.util.Properties.load(Properties.java:325)
        at org.apache.pivot.wtk.ApplicationContext.<clinit>(ApplicationContext.java:1518)
        Exception in thread "main"

        Tell me what you think.

        Show
        Sandro Martini added a comment - Note that after this little change (in ApplicationContext) I'm no more able to run some bxml files from eclipse ... if the property file is not found probably I could have a warning in console, but without blocking the execution, ok ? For example, try to run "As Pivot script application": tests/ ... / multiple_selection_list.bxml , this is the result: java.lang.ExceptionInInitializerError Caused by: java.lang.NullPointerException at java.util.Properties$LineReader.readLine(Properties.java:418) at java.util.Properties.load0(Properties.java:337) at java.util.Properties.load(Properties.java:325) at org.apache.pivot.wtk.ApplicationContext.<clinit>(ApplicationContext.java:1518) Exception in thread "main" Tell me what you think.
        Hide
        Sandro Martini added a comment -

        sample patch, just for exampe of solution

        Show
        Sandro Martini added a comment - sample patch, just for exampe of solution
        Hide
        Greg Brown added a comment -

        I'm not sure that silently failing is the right solution. It sounds like build.properties is not on the classpath. We probably need to update the Eclipse projects to include this file.

        Show
        Greg Brown added a comment - I'm not sure that silently failing is the right solution. It sounds like build.properties is not on the classpath. We probably need to update the Eclipse projects to include this file.
        Hide
        Sandro Martini added a comment -

        Ok, but "silently" not so much, because something is written in the Console but I agree that could not be the best.
        And Greg, are we sure that not finding such file is right to be a fatal error (in Startup of applications) ?

        > We probably need to update the Eclipse projects to include this file.
        Ok, let's see if it's a good solution, we can try it now ...

        Show
        Sandro Martini added a comment - Ok, but "silently" not so much, because something is written in the Console but I agree that could not be the best. And Greg, are we sure that not finding such file is right to be a fatal error (in Startup of applications) ? > We probably need to update the Eclipse projects to include this file. Ok, let's see if it's a good solution, we can try it now ...
        Hide
        Roger Whitcomb added a comment -

        I'd be happy to do it, except that I know next to nothing about Eclipse... But if someone can point me to what has to change I can do it.

        Sandro, all I did was add our "build.properties" file to all the built .jar files. So, if there is a setting in the Eclipse projects that specifies what the .jar files contain, that just needs to be updated (or something like that).

        Show
        Roger Whitcomb added a comment - I'd be happy to do it, except that I know next to nothing about Eclipse... But if someone can point me to what has to change I can do it. Sandro, all I did was add our "build.properties" file to all the built .jar files. So, if there is a setting in the Eclipse projects that specifies what the .jar files contain, that just needs to be updated (or something like that).
        Hide
        Sandro Martini added a comment -

        Hi Roger, don't worry ... to add the build.properties to any Pivot jar we can do it inside our Ant build process.
        The only problem now is that from the development environment with all Pivot sources (from trunk) we have to see if it's possible to add a reference to that file for any Pivot subproject (like tests, examples, etc). I don't know if it's possible inside eclipse, but I'll try to see as soon as possible.

        In the meantime using the patch2 in eclipse here will solve the problem, as a workaround.

        Just a note:
        I've just seen that inside Pivot jars (for example all jars of Pivot-2.0), in the manifest there is this element:
        Implementation-Version: 2.0
        where the release number if taken from build.properties by ant ...
        so why not try to use directly this info (and not bundle a copy of build.properties) ?
        And when not available (like when there aren't Pivot jars but full sources instead) verify if load from build.properties (if possible, after some checks in eclipse) or if log it as a warning/error ...

        Comments ?

        Bye,
        Sandro

        Show
        Sandro Martini added a comment - Hi Roger, don't worry ... to add the build.properties to any Pivot jar we can do it inside our Ant build process. The only problem now is that from the development environment with all Pivot sources (from trunk) we have to see if it's possible to add a reference to that file for any Pivot subproject (like tests, examples, etc). I don't know if it's possible inside eclipse, but I'll try to see as soon as possible. In the meantime using the patch2 in eclipse here will solve the problem, as a workaround. Just a note: I've just seen that inside Pivot jars (for example all jars of Pivot-2.0), in the manifest there is this element: Implementation-Version: 2.0 where the release number if taken from build.properties by ant ... so why not try to use directly this info (and not bundle a copy of build.properties) ? And when not available (like when there aren't Pivot jars but full sources instead) verify if load from build.properties (if possible, after some checks in eclipse) or if log it as a warning/error ... Comments ? Bye, Sandro
        Hide
        Roger Whitcomb added a comment -

        Can't we just set the classpath for Eclipse to include our "build.properties" and leave the code the way it was? If we just ensure that "build.properties" is always available then there is nothing more to do. I just don't know how to set the Eclipse classpath. Is that done in some of the .settings files? Or somehow via the .classpath file?

        Show
        Roger Whitcomb added a comment - Can't we just set the classpath for Eclipse to include our "build.properties" and leave the code the way it was? If we just ensure that "build.properties" is always available then there is nothing more to do. I just don't know how to set the Eclipse classpath. Is that done in some of the .settings files? Or somehow via the .classpath file?
        Hide
        Greg Brown added a comment -

        > to add the build.properties to any Pivot jar we can do it inside our Ant build process.

        FYI, Roger's patch already added this to build.xml.

        > I've just seen that inside Pivot jars (for example all jars of Pivot-2.0), in the manifest there is this element:
        > Implementation-Version: 2.0

        I actually wrote code to do this a long time ago, but it was pretty messy. The manifest isn't on the classpath, so it's not easy to get to programmatically.

        Show
        Greg Brown added a comment - > to add the build.properties to any Pivot jar we can do it inside our Ant build process. FYI, Roger's patch already added this to build.xml. > I've just seen that inside Pivot jars (for example all jars of Pivot-2.0), in the manifest there is this element: > Implementation-Version: 2.0 I actually wrote code to do this a long time ago, but it was pretty messy. The manifest isn't on the classpath, so it's not easy to get to programmatically.
        Hide
        Sandro Martini added a comment -

        Ok, I'll try to add the build.properties to our eclipse projects, with the assumption that it is 1 level upper (in root of the workspace folder) ... and keep you updated before committing.

        Show
        Sandro Martini added a comment - Ok, I'll try to add the build.properties to our eclipse projects, with the assumption that it is 1 level upper (in root of the workspace folder) ... and keep you updated before committing.
        Hide
        Andrei Pozolotin added a comment -

        another wild idea: there is not need for build.properties at all;

        use instead:
        http://download.oracle.com/javase/6/docs/api/java/lang/Package.html

        getClass().getPackage().getSpecificationVersion();
        getClass().getPackage().getSpecificationTitle();
        getClass().getPackage().getImplementationVersion();
        getClass().getPackage().getImplementationTitle();

        Show
        Andrei Pozolotin added a comment - another wild idea: there is not need for build.properties at all; use instead: http://download.oracle.com/javase/6/docs/api/java/lang/Package.html getClass().getPackage().getSpecificationVersion(); getClass().getPackage().getSpecificationTitle(); getClass().getPackage().getImplementationVersion(); getClass().getPackage().getImplementationTitle();
        Hide
        Roger Whitcomb added a comment -

        Okay, so here's a patch that reverts the addition of "build.properties" to the .jar files and instead uses Andrei's method to get the Implementation-Version (which is already set by the value from "build.properties"). It should be fail-safe in the case of running from .class files and not from .jars.

        Show
        Roger Whitcomb added a comment - Okay, so here's a patch that reverts the addition of "build.properties" to the .jar files and instead uses Andrei's method to get the Implementation-Version (which is already set by the value from "build.properties"). It should be fail-safe in the case of running from .class files and not from .jars.
        Hide
        Roger Whitcomb added a comment -

        Patch to use Package.getImplementationVersion() instead of the "build.properties" file; removes "build.properties" from the .jar files.

        Show
        Roger Whitcomb added a comment - Patch to use Package.getImplementationVersion() instead of the "build.properties" file; removes "build.properties" from the .jar files.
        Hide
        Greg Brown added a comment -

        I was not aware of Package#getSpecificationVersion(), etc. - good find. I assume that this pulls the version info from the JAR manifest?

        Show
        Greg Brown added a comment - I was not aware of Package#getSpecificationVersion(), etc. - good find. I assume that this pulls the version info from the JAR manifest?
        Hide
        Roger Whitcomb added a comment -

        From my testing, yes, it pulls the exact "version" value set in the Jar manifest for Implementation-Version.

        What do you think of my "version2.patch"?

        Show
        Roger Whitcomb added a comment - From my testing, yes, it pulls the exact "version" value set in the Jar manifest for Implementation-Version. What do you think of my "version2.patch"?
        Hide
        Greg Brown added a comment -

        Patch looks good. I applied a slightly modified version - let me know if anything looks amiss.

        Show
        Greg Brown added a comment - Patch looks good. I applied a slightly modified version - let me know if anything looks amiss.
        Hide
        Roger Whitcomb added a comment -

        The only think I was wondering (which is why I was super-cautious) is that getPackage() can return null (such as when Pivot is run from .class files instead of a .jar?) so I didn't want Sandro's case to be broken again if that happened.

        Show
        Roger Whitcomb added a comment - The only think I was wondering (which is why I was super-cautious) is that getPackage() can return null (such as when Pivot is run from .class files instead of a .jar?) so I didn't want Sandro's case to be broken again if that happened.
        Hide
        Greg Brown added a comment -

        A class should still have a valid package whether it was loaded from a JAR or a directory, so I think it is safe to assume that getPackage() will return non-null.

        Show
        Greg Brown added a comment - A class should still have a valid package whether it was loaded from a JAR or a directory, so I think it is safe to assume that getPackage() will return non-null.
        Hide
        Andrei Pozolotin added a comment -

        getPackage() returns null when you run exploded jar applet (legacy classloder);
        this currently breaks wtk, wtk-terra

        Show
        Andrei Pozolotin added a comment - getPackage() returns null when you run exploded jar applet (legacy classloder); this currently breaks wtk, wtk-terra
        Hide
        Greg Brown added a comment -

        That's unfortunate. It's probably not a case we really need to worry about, but the fix is simple enough so we might as well do it.

        Show
        Greg Brown added a comment - That's unfortunate. It's probably not a case we really need to worry about, but the fix is simple enough so we might as well do it.
        Hide
        Sandro Martini added a comment - - edited

        Hi all,
        (after a synchronize with the trunk) I've tried to run/debug some Test classes as Applications, and as Applets from my eclipse and all works good :
        ApplicationContext.class.getPackage() never returns null , but String version = ApplicationContext.class.getPackage().getImplementationVersion(); willy be null, so a safe pivotVersion will be initialized.

        If it's Ok for all, to me seems that this issue could be marked as resolved.
        Thank you to all.

        Show
        Sandro Martini added a comment - - edited Hi all, (after a synchronize with the trunk) I've tried to run/debug some Test classes as Applications, and as Applets from my eclipse and all works good : ApplicationContext.class.getPackage() never returns null , but String version = ApplicationContext.class.getPackage().getImplementationVersion(); willy be null, so a safe pivotVersion will be initialized. If it's Ok for all, to me seems that this issue could be marked as resolved. Thank you to all.

          People

          • Assignee:
            Greg Brown
            Reporter:
            Roger Whitcomb
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - 1h
              1h
              Remaining:
              Remaining Estimate - 1h
              1h
              Logged:
              Time Spent - Not Specified
              Not Specified

                Development