Add --version tag to show the version of the jar of RepoSense

[fzdy1914]

As, title. The users may not know the jar file they download is the correct version of RepoSensse or not and they cannot verify it.

Let's add a -version tag to show the version of jar file of RepoSense.

[yong24s]

Can be done together with #449

Removing this requirement.

[eugenepeh]

let's add another requirement, print the version in the report as well.

[yong24s]

For users running RepoSense usingpublish-RepoSense with latest master, it would be helpful if we can print the commit hash rather than the release version.

[fzdy1914]

For users running RepoSense usingpublish-RepoSense with latest master, it would be helpful if we can print the commit hash rather than the release version.

Printing out the commit hash will be a little bit difficult to implement. For the release version, we only need to keep a variable that stores the version of RepoSense. But for commit hash, we cannot store it.

There is one way that may solve the problem, the --version tag can also take in a argument, in publish-RepoSense, when we choose the latest master, it can pass the hash to the jar file. So, the generated report can contains the hash. What's your opinion on this?

[yong24s]

I think we could get the version information pushed into the Jar manifest. 🤔

[fzdy1914]

@yong24s But we will need it to be included in our generated report right? It should be better to let it be a variable.

[yong24s]

I believe you can access manifest values at runtime. 🤔

shadowJar {
    archiveName = 'RepoSense.jar'
    destinationDir = file("${buildDir}/jar/")

    manifest {
    	attributes 'Version': project.property("version")
    }
}

Building Jar

$ ./gradlew shadowJar -Pversion='1.8'

META-INF\MANIFEST.MF

Manifest-Version: 1.0
Version: '1.8'
Main-Class: reposense.RepoSense

[yong24s]

Printing out the commit hash will be a little bit difficult to implement. For the release version, we only need to keep a variable that stores the version of RepoSense. But for commit hash, we cannot store it.

Where would you proposed to keep the version variable?

If its inside the source code then we have to make a new commit to update the version value every time we release. I would like to minimize trivial commits to the repository. This approach also makes it hard to track the commit hash.

There is one way that may solve the problem, the --version tag can also take in a argument, in publish-RepoSense, when we choose the latest master, it can pass the hash to the jar file. So, the generated report can contains the hash. What's your opinion on this?

Yes, something like this workflow.

My suggested workflow would be:

• For releaser to run ./gradlew shadowJar -Pversion='1.8' to generate Jar
• For CI to run ./gradlew shadowJar -Pversion=$(git rev-parse --short HEAD)

At this point of time, I don't think our code needs to know anything about versions.

[fzdy1914]

• For releaser to run ./gradlew shadowJar -Pversion='1.8' to generate Jar
• For CI to run ./gradlew shadowJar -Pversion=$(git rev-parse --short HEAD)

At this point of time, I don't think our code needs to know anything about versions.

OK, I will investigate how to access manifest values at runtime.

[yong24s]

Also at frontend we can just take the version and plug it in https://github.com/reposense/RepoSense/commits/<VERSION>

https://github.com/reposense/RepoSense/commits/v1.7
https://github.com/reposense/RepoSense/commit/6dd74a0

[fzdy1914]

• For releaser to run ./gradlew shadowJar -Pversion='1.8' to generate Jar
• For CI to run ./gradlew shadowJar -Pversion=$(git rev-parse --short HEAD)

A little nit, then, we are unable to have a default version for our project.

[fzdy1914]

I have investigated how to access MANIFEST file and gradle.property during runtime, it seems that there is no elegant way to do so. Can you suggest a good way to do so?

[fzdy1914]

Add some way I have searched:
https://stackoverflow.com/questions/1272648/reading-my-own-jars-manifest
https://www.programcreek.com/java-api-examples/java.util.jar.Manifest
https://gualtierotesta.wordpress.com/2015/07/05/java-how-to-check-jar-version-at-runtime/
https://www.yegor256.com/2014/07/03/how-to-read-manifest-mf.html

[fzdy1914]

~The last one looks promising but we need to add two more dependencies which we may not want.

@yong24s Please give a review. Also, you may see my implementation until now #565.~

[fzdy1914]

I found a way to get the version of our project correctly using s.getClass().getPackage().getImplementationVersion()

[yong24s]

I found a way to get the version of our project correctly using s.getClass().getPackage().getImplementationVersion()

Hmm, it worked for you? I only got the installed Java version in my system 1.8.0_172. 😂

I'm okay with jcabi-manifests if it helps to prevent dangerous coding. You may want to check with other mentors.

When needed, a well documented/maintained library can be used, if it simplifies development. Just don't pick a library that is clearly an overkill.

[fzdy1914]

@yong24s I have implemented the solution.
See my pr to test out.
Try:
./gradlew shadowJar -Pversion='6dd74a0'
and for the generated jar
Try:
java -jar RepoSense.jar --version
and try use it to generate a report.

[fzdy1914]

However, I still leave a default version number in my implementation, which is not so necessary.

[eugenepeh]

perhaps try out using git tag for this purpose?
https://github.com/palantir/gradle-git-version