commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Spero <>
Subject Re: OSGI Version at Package Level : some more details about the COMPRESS-399 pull request
Date Tue, 13 Jun 2017 19:12:04 GMT
On Jun 13, 2017 1:48 PM, "Gary Gregory" <> wrote:

I think that the best way to see how this works is to provide a patch...
then we can see how it goes.

  Can you clarify a few things:

What would you like to see patches for - the commons parent / related mojo
one or more  commons projects, the Felix maven-bundle-plugin, or some
combination thereof?

The changes which I submitted as a pull-request for COMPRESS-399¹ (as
amended) are on
commons-compress only.

The net changes:

1. Update the version of the maven-bundle-plugin used.
2. Add the bundle:baseline goal to the verify phase.
3. Add a "provided" scope maven dependency on org.osgi:org.osgi.annotation:
for the  @Version annotation.
4. Override the parent bundle:manifest configuration, with no version in
the export-package (this would override any other source of version info).
5. Add initial files to each non-empty package,
initialized to the previously released version.
6. Change the travis.yml configuration to execute mvn verify as the build
7. Add  bundle:baseline-report goal to the site phase.

An example of additional work after  a subsequent api change is

Some of these changes can be lifted to the parent; the initial setup of @Version annotations requires some code.


¹ OK, I made the changes, created the issue, then submitted the

On Mon, Jun 12, 2017 at 10:18 AM, Simon Spero <> wrote:

> On Mon, Jun 12, 2017 at 10:53 AM, Matt Sicker <> wrote:
> > I'd love to have a semantic versioning plugin like that which can
> > what the version number is for the entire project. Elm (programming
> > language) has a tool like that, and it works rather well in practice
> (even
> > though there are some popular libraries that are at version 5.0.0
> > because of it).
> The bundle:baseline goal does this (it's at the start of the report).
> Having  frequent major version bumps is a good thing if they are necessary
> and the libraries are small (definitely better than having breaking
> without the bump).
> It's not as good as having *correct* semantic-version numbers of 1.4.0 :-)

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message