You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Raul Kripalani <ra...@apache.org> on 2016/04/06 17:36:23 UTC
Usage of SNAPSHOT qualifier in package exports
During a discussion in the Camel dev@ list about possibly adopting the
bnd-maven-plugin, a contributor noticed differences in the way that package
export versions are computed between Felix' maven-bundle-plugin and the
former.
http://camel.465427.n5.nabble.com/DISCUSS-Moving-from-maven-bundle-plugin-to-bnd-maven-plugin-and-SNAPSHOT-versions-tp5780520.html
* maven-bundle-plugin transforms the -SNAPSHOT qualifier to .SNAPSHOT.
* bnd-maven-plugin transforms the -SNAPSHOT qualifier to .<timestamp>.
OSGi sorts versions in alphanumeric order, which means that, to the eyes of
an OSGi container, 1.0.0.SNAPSHOT is higher than 1.0.0 (!).
https://versionatorr.appspot.com/?a=1.0.0-SNAPSHOT&b=1.0.0
Sure this is a minor issue, with practically zero impact. I can't think of
a use case where one would deploy the same bundle twice in production, as a
SNAPSHOT and as final.
It seems that your artefacts are affected, based on the MANIFEST.MF in this
bundle as an example:
https://repository.apache.org/content/groups/snapshots/org/apache/felix/org.apache.felix.fileinstall/3.5.3-SNAPSHOT/org.apache.felix.fileinstall-3.5.3-20160401.145250-1.jar
.
As I said, not a biggie, but being Felix a leader in the OSGi technology
space, I would like to hear your thoughts, as it's a matter of semantic
correctness and adherence to the OSGi principles.
Cheers,
*Raúl Kripalani*
PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and
Messaging Engineer
http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
Blog: raul.io
<http://raul.io/?utm_source=email&utm_medium=email&utm_campaign=apache> |
twitter: @raulvk <https://twitter.com/raulvk>
Re: Usage of SNAPSHOT qualifier in package exports
Posted by Julian Sedding <js...@gmail.com>.
Hi Raúl
A simple workaround to remove this ambiguity is to use odd micro
versions for snapshots only and even micro versions for releases. We
use this strategy in the Apache Sling project successfully since
several years.
I.e.
1.0.1-SNAPSHOT
1.0.2 <-- release
1.0.3-SNAPSHOT
1.0.4 <-- release
Regards
Julian
On Wed, Apr 6, 2016 at 5:36 PM, Raul Kripalani <ra...@apache.org> wrote:
> During a discussion in the Camel dev@ list about possibly adopting the
> bnd-maven-plugin, a contributor noticed differences in the way that package
> export versions are computed between Felix' maven-bundle-plugin and the
> former.
>
> http://camel.465427.n5.nabble.com/DISCUSS-Moving-from-maven-bundle-plugin-to-bnd-maven-plugin-and-SNAPSHOT-versions-tp5780520.html
>
> * maven-bundle-plugin transforms the -SNAPSHOT qualifier to .SNAPSHOT.
> * bnd-maven-plugin transforms the -SNAPSHOT qualifier to .<timestamp>.
>
> OSGi sorts versions in alphanumeric order, which means that, to the eyes of
> an OSGi container, 1.0.0.SNAPSHOT is higher than 1.0.0 (!).
>
> https://versionatorr.appspot.com/?a=1.0.0-SNAPSHOT&b=1.0.0
>
> Sure this is a minor issue, with practically zero impact. I can't think of
> a use case where one would deploy the same bundle twice in production, as a
> SNAPSHOT and as final.
>
> It seems that your artefacts are affected, based on the MANIFEST.MF in this
> bundle as an example:
> https://repository.apache.org/content/groups/snapshots/org/apache/felix/org.apache.felix.fileinstall/3.5.3-SNAPSHOT/org.apache.felix.fileinstall-3.5.3-20160401.145250-1.jar
> .
>
> As I said, not a biggie, but being Felix a leader in the OSGi technology
> space, I would like to hear your thoughts, as it's a matter of semantic
> correctness and adherence to the OSGi principles.
>
> Cheers,
>
> *Raúl Kripalani*
> PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and
> Messaging Engineer
> http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> Blog: raul.io
> <http://raul.io/?utm_source=email&utm_medium=email&utm_campaign=apache> |
> twitter: @raulvk <https://twitter.com/raulvk>
Re: Usage of SNAPSHOT qualifier in package exports
Posted by Julian Sedding <js...@gmail.com>.
Hi Raúl
A simple workaround to remove this ambiguity is to use odd micro
versions for snapshots only and even micro versions for releases. We
use this strategy in the Apache Sling project successfully since
several years.
I.e.
1.0.1-SNAPSHOT
1.0.2 <-- release
1.0.3-SNAPSHOT
1.0.4 <-- release
Regards
Julian
On Wed, Apr 6, 2016 at 5:36 PM, Raul Kripalani <ra...@apache.org> wrote:
> During a discussion in the Camel dev@ list about possibly adopting the
> bnd-maven-plugin, a contributor noticed differences in the way that package
> export versions are computed between Felix' maven-bundle-plugin and the
> former.
>
> http://camel.465427.n5.nabble.com/DISCUSS-Moving-from-maven-bundle-plugin-to-bnd-maven-plugin-and-SNAPSHOT-versions-tp5780520.html
>
> * maven-bundle-plugin transforms the -SNAPSHOT qualifier to .SNAPSHOT.
> * bnd-maven-plugin transforms the -SNAPSHOT qualifier to .<timestamp>.
>
> OSGi sorts versions in alphanumeric order, which means that, to the eyes of
> an OSGi container, 1.0.0.SNAPSHOT is higher than 1.0.0 (!).
>
> https://versionatorr.appspot.com/?a=1.0.0-SNAPSHOT&b=1.0.0
>
> Sure this is a minor issue, with practically zero impact. I can't think of
> a use case where one would deploy the same bundle twice in production, as a
> SNAPSHOT and as final.
>
> It seems that your artefacts are affected, based on the MANIFEST.MF in this
> bundle as an example:
> https://repository.apache.org/content/groups/snapshots/org/apache/felix/org.apache.felix.fileinstall/3.5.3-SNAPSHOT/org.apache.felix.fileinstall-3.5.3-20160401.145250-1.jar
> .
>
> As I said, not a biggie, but being Felix a leader in the OSGi technology
> space, I would like to hear your thoughts, as it's a matter of semantic
> correctness and adherence to the OSGi principles.
>
> Cheers,
>
> *Raúl Kripalani*
> PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and
> Messaging Engineer
> http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> Blog: raul.io
> <http://raul.io/?utm_source=email&utm_medium=email&utm_campaign=apache> |
> twitter: @raulvk <https://twitter.com/raulvk>