commons-compress
commons-compress copied to clipboard
apache
COMPRESS-399 OSGI package versions are overly pessimistic, except when they're overly optimisic
-
Add packageinfo files for per-package version settings.
- Initialize to 1.14
- Copy packageinfo files in resource phase.
-
Use latest bundle plugin.
- Remove headers from generate manifest.
- Pretty-print the manifest.
- Add bundle:baseline to the verify phase
- Add bundle:baseline-report to the site phase
- To change the base version from default (i.e. previous release) set comparisonVersion property
-
Change travis build to use verify instead of test
Signed-off-by: Simon Spero [email protected]
It's difficult to generalize, since the packageinfo files have to be put in with the source code. Since a export header parameter with an explicit version overrides packageinfo and annotations, defaults can be problematic.
Adding the resource copy and rat excludes is good, as is keeping up with the felix bundle versions.
Adding a bundle:baseline goal to the parent verify phase is a really, really good idea if bundle headers are going to be generated. Package versions MUST follow semver (bundle versions also, but to a lesser extent).
Maven versions theoretically ought to too, but dependencies are usually point versions not ranges.
(Of course, there's always guava, where version is a major release, except for bug fixes, which are minor.)
The real work is getting the api and implementation(s) properly modularized so that the api isn't always affected by implementation changes. At least jigsaw has gotten people to start thinking about modules. Not always sensibly....
On Jun 2, 2017 2:38 PM, "Gary Gregory" [email protected] wrote:
Hi,
Should any of this work also apply to commons-parent?
Gary
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/apache/commons-compress/pull/26#issuecomment-305876373, or mute the thread https://github.com/notifications/unsubscribe-auth/AAZIG7Xv74lnd98TXW3kzw9huxG2US7Rks5sAFaZgaJpZM4NukX5 .
Why are those packageinfo files in src/main/java instead of src/main/resources as it is common in Maven builds? Now you have to configure explicitly these files as resources. On top of it, I don't like the idea of modifying these files for each release manually. I'd look for a solution that generates these files automatically into target/generated-resources. Such a plugin should not be difficult.
The packageinfo files are in the source tree because they're source files, and provide metadata for the package. You can also use a package annotation on package-info.java, which puts a Class Retention annotation on the packages package-info.class.
Examples:
https://github.com/apache/felix/blob/trunk/dependencymanager/org.apache.felix.dependencymanager.annotation/src/org/apache/felix/dm/annotation/api/packageinfo
https://github.com/apache/felix/blob/trunk/converter/ converter/src/main/java/org/apache/felix/converter/dto/package-info.java
(Requires provided / compileOnly dependency on the osgi annotation bundle).
On Fri, Jun 2, 2017 at 6:11 PM, Jörg Schaible [email protected] wrote:
Why are those packageinfo files in src/main/java instead of src/main/resources as it is common in Maven builds? Now you have to configure explicitly these files as resources. On top of it, I don't like the idea of modifying these files for each release manually. I'd look for a solution that generates these files automatically into target/generated-resources. Such a plugin should not be difficult.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/apache/commons-compress/pull/26#issuecomment-305920965, or mute the thread https://github.com/notifications/unsubscribe-auth/AAZIGza5aeOCDCCwJhvZ1jufn0jZ7BkWks5sAIitgaJpZM4NukX5 .
This is a Maven project and we follow Maven conventions. Anything that is processed by a Java compiler belongs into src/main/java (true for package-info.java files, not true for packageinfo files or package.html files). Anything else that should be collected in a jar file is a resource and belongs therefore into src/main/resources. The fact that you have to reconfigure the resources clearly demonstrates this.
Nevertheless, these files will make our release process even more cumbersome if they are checked in as sources. The nature and content of the files identifies them clearly as something that can be generated. We might even be able to use the antrun plugin directly. If we put it into a profile and activate it based on file existence, we might even move it into commons-parent.
... and again we have a bunch of files that we have to modify for every release.
A key point is that these files that are not modified for each release. They are only changed when the package version changes, which only happens when the API changes (and was supposed to). If the package API does not change, then the package version should not be modified.
Also, changing the package version number happens in the development phase of the lifecycle rather than the release phase.
On Mon, Jun 5, 2017, 6:26 PM Jörg Schaible [email protected] wrote:
... and again we have a bunch of files that we have to modify for every release.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/apache/commons-compress/pull/26#issuecomment-306328119, or mute the thread https://github.com/notifications/unsubscribe-auth/AAZIGyAYQTfOaV8sY3a7k0YDqMx1qsoaks5sBICggaJpZM4NukX5 .
Sorry, I'm currently swamped and won't find time to look into this for the coming days. @sesuncedu there is a discussion going on on the dev mailing list that you may want to join -> https://lists.apache.org/thread.html/4a205ffad0ae0886113e76f358a6fbe59dfdf113f194c5fa687cdd69@%3Cdev.commons.apache.org%3E
(typo in the title -- optimisic -> optimistic -- which may be good to fix before it's part of some release notes generation. 😉 )
Please rebase on master. Recent changes should allow all builds to be green including Java 16 and 17-EA.