https://github.com/cloudogu/versionname
A tiny Java library that allows for conveniently reading the version name of an application
https://github.com/cloudogu/versionname
Last synced: 6 months ago
JSON representation
A tiny Java library that allows for conveniently reading the version name of an application
- Host: GitHub
- URL: https://github.com/cloudogu/versionname
- Owner: cloudogu
- License: mit
- Created: 2016-09-16T14:50:58.000Z (almost 10 years ago)
- Default Branch: develop
- Last Pushed: 2024-08-14T10:57:47.000Z (almost 2 years ago)
- Last Synced: 2024-08-14T23:49:33.612Z (almost 2 years ago)
- Language: Java
- Homepage:
- Size: 160 KB
- Stars: 2
- Watchers: 5
- Forks: 3
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
versionName
===========
versionName is a tiny Java library that allows for conveniently reading the version name of an application from
- Manifest,
- property file or
- from a constant generated by an annotation processor.
# Reading from manifest or property file
versionName consists of one class (as said before it's tiny) [VersionNames](versionName/src/main/java/com/cloudogu/versionname/VersionNames.java) that provides methods for reading the version name.
The public methods return a String that is never `null`. In case of error, messages are written to a [SLF4J](http://slf4j.org/)-logger.
- [VersionNames.getVersionNameFromProperties()](versionName/src/main/java/com/cloudogu/versionname/VersionNames.java),
- [VersionNames.getVersionNameFromManifest()](versionName/src/main/java/com/cloudogu/versionname/VersionNames.java)
To use versionName, either copy [VersionNames](versionName/src/main/java/com/cloudogu/versionName/VersionNames.java) to your classpath or add the [latest stable version](https://search.maven.org/#search%7Cga%7C1%7Cg%3A%20%22com.cloudogu.versionName%22%20AND%20a%3A%22versionName%22) to the dependency management tool of your choice.
Read more about it in those two blog posts (Note that this refers to version 1.x and the maven coords and package names have changed since!)
- [Version names with Maven: Creating the version name](https://www.triology.de/en/blog-entries/versionsnamen-mit-maven-erzeugen-des-versionsnamens) (which refers to the [examples](examples)) and
- [Version names with Maven: Reading the version name](https://www.triology.de/en/blog-entries/version-names-with-maven-reading-the-version-name) (which refers to the library itself).
With maven for example
```XML
com.cloudogu.versionName
versionName
2.0.0
```
[](https://search.maven.org/#search%7Cga%7C1%7Cg%3A%20%22com.cloudogu.versionName%22%20AND%20a%3A%22versionName%22)
You can also get snapshot versions from our [snapshot repository](https://oss.sonatype.org/content/repositories/snapshots/com/cloudogu/versionName/versionName/) (for the most recent commit on develop branch).
To do so, add the following repo to your `pom.xml` or `settings.xml`:
```xml
snapshots-repo
https://oss.sonatype.org/content/repositories/snapshots
false
true
```
# Alternative: Using the annotation processor
From a runtime perspective, its actually a bit odd reading a build-time constant from a file where it could just be
"baked into" the application source code.
This misery can be ended using the [VersionNameProcessor](processor/src/main/java/com/cloudogu/versionname/VersionNameProcessor.java).
It generates a constant `Version.NAME` (package, class and field name can be customized). With this mechanism there is
not even the need for the `com.cloudogu.versionName:versionName` dependency.
In order to trigger the process, an annotation `@VersioName` must be set on a class or package. The `Version` class is
then generated into the same package when the following dependency is added to the build (e.g. with maven):
```xml
com.cloudogu.versionName
processor
2.1.0
provided
```
[](https://search.maven.org/#search%7Cga%7C1%7Cg%3A%20%22com.cloudogu.versionName%22%20AND%20a%3A%22processor%22)
Using the provided scope will add zero dependencies to your project, only the generated class.
In addition, the version name to be written must be passed as an argument `versionName` to the compiler, e.g. like so
using maven:
```xml
org.apache.maven.plugins
maven-compiler-plugin
3.8.0
-AversionName=${versionName}
```
See also
* the [full example using the annotation processor](examples/jar-without-deps) and
* the [unit tests of the annotation processor](processor/src/test/java/com/cloudogu/versionname/VersionNameProcessorTest.java).
# Examples
The examples show how to write a version name to your application using maven and how it can be read using the library from within applications (JAR or WAR).
See [examples/README.md](examples/README.md)
# Jenkins
Running [Jenkinsfile](Jenkinsfile) with the [pipeline plugin](https://wiki.jenkins-ci.org/display/JENKINS/Pipeline+Plugin) (tested with version 2.4) requires
- Docker
- Optional: You can add a build parameter `RECIPIENTS` that contains a comma-separated list of all email recipients
# Releasing
* rebase `main` onto `develop`
* `mvn versions:set -DnewVersion=2.2.0 -DgenerateBackupPoms=false`
* `git commit -m 'Prepare release'`, `tag -s`, `push`
* rebase `develop` onto `main`
* `mvn versions:set -DnewVersion=2.2.1-SNAPSHOT -DgenerateBackupPoms=false`
* `git commit -m 'Prepare next development iteration'`, `push`
We might get rid of develop branch and the rebasing in the future.