Closed ST-DDT closed 6 years ago
Thanks for opening this issue. I realized the meta data was wrong when building the demo docker image during a break this morning.
Not sure why it is so, though. It seems ok when building the multiproject, not depending on the jar itself.
Using the manifest is a very good suggestion. I'll try to give it a go after I find out what happened to the meta data of the artifact.
Ok I found out the problem regarding the deployment of an artifact with stale resources. This is due to this gradle "bug": https://github.com/gradle/gradle/issues/808 https://github.com/gradle/gradle/issues/861
Following the suggestions there, I think I have some changes that could prevent this from happening again. Anyway, I should build and upload artifacts from a clean environment to avoid this kind of issues next time.
Using the manifest for the version looks nice, but there is no easy way to get the build date out of it. Getting the manifest seems to be a not-so-easy task after all. Also, this would only work when running livedoc from a JAR. This is the case most of the time except during local development, and thus will make local testing more complicated.
I guess I'll stick to the properties file for now as far as reading the info is concerned, but I'll generate a more complete manifest anyway for the sake of better packaging.
Describe the bug
In the generated
/jsondoc
endpoint the outputs a different version number than the one specified in the artifact. The build date is written in an english format that is intended for humans, but since it is a data endpoint it should output a format understandable by computers.Expected behavior
Screenshots
Environment/Context
I use Livedoc in a Spring 5.0.x Environment with Maven.
Solution
To avoid such issues (due to wrongly generated meta-data files) you could switch the the meta data that are stored in the
META-INF/MANIFEST.mf
file (needs to be enabled in your build config)Here an example from Postgresql's jdbc driver:
Then you can access these meta information by simply invoking.
getClass().getPackage().getImplementationVersion()