Am 15.09.2010 12:45, schrieb sebb:
On 15 September 2010 09:28, Michael Lieshoff
<michael.liesh...@healthcarion.de>  wrote:
  Hi there,

i have problems in big environments where different versions of Apache
Commons projects exists, some older and others newer. I think in this case a
version class is pretty, contains the version of the project. So a simple
version request at runtime would be possible and it's not needed to read
manifest informations. I searched about version classes in Apache Commons
projects but i dont find anything.

Here is a simple code fragment:

package org.apache.commons.lang;
public final class Version {
    private Version() {
        super();
    }
    private final static String VERSION = "2.4";
    public static String getVersion() {
        return VERSION;
    }
}

What you think about it?
I like the idea.

Apache JMeter does the same.

It also includes the last SVN revision of whatever workspace was used
to build it.

Since the version is available to Maven (or Ant) it could update (or
perhaps create?) the version file as part of the build.

If we decide to include the SVN revision as well, we could also add
the SVN revision as a new manifest entry.

Which makes me wonder - maybe another way to do this would be to have
the getVersion() method read the Manifest entry?

Best regards

Michael.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



The version class can defines most of entries (and perhaps more) in manifest file with several method for access. In other projects i generate same class automatically during build process. Methods in version class reading informations from manifest file seems good too. There will be no need of automatically generation or double maintenance.

Best regards

Michael.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to