trying to read build properties. #948
Conversation
| @@ -317,6 +323,10 @@ | |||
| private static Predicate<Property> hasFedoraNamespace = | |||
| p -> !p.isAnon() && p.getNameSpace().startsWith(REPOSITORY_NAMESPACE); | |||
|
|
|||
| // DOAP release decribes fedora build information | |||
There was a problem hiding this comment.
May as well move this property up closer to the DOAP namespace... instead of down here at the bottom of the file.
|
@nianma, I would suggest adding two integration test methods:
|
| @@ -0,0 +1,3 @@ | |||
| build.name=${project.version} | |||
| build.date=${build.timestamp} | |||
| build.revision=${buildNumber} | |||
There was a problem hiding this comment.
I really don't think we should use a properties file for this. The version information is already included in the MANIFEST.MF file and it can be retrieved like so:
this.getClass().getPackage().getImplementationVersion();
The build date and build revision are not typically part of the manifest file, and if they are not needed, I would omit them. IMO, we would also define and use the SpecificationVersion, which would correspond to the version of fcrepo-kernel-api (the ImplementationVersion would be the version of fcrepo-kernel-modeshape) -- that would involve updating ./fcrepo-parent/pom.xml to include this line in the bundle plugin:
<Specification-Version>${project.version}</Specification-Version>
Once the kernel-api is completely separated from the implementation, the version of fcrepo-kernel-api could be different than ${project.version}, but for now, they are the same.
|
It seems this was never meant to be merged and is marked wont fix. Closing |
This is only for sharing, not for merging.