You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Quinn Stevenson <qu...@pronoia-solutions.com> on 2016/04/05 20:58:21 UTC
[DISCUSS] - Moving from maven-bundle-plugin to bnd-maven-plugin and SNAPSHOT versions
I’ve got the basics down for doing this conversion, but there are a couple of differences between the MANIFEST.MF files generated by the two tools when SNAPSHOT versions are used.
Bundle-Version header:
By default, given a version in a POM like "1.2.3-SNAPSHOT”:
- the maven-bundle-plugin converts the version to “X.X.X.SNAPSHOT"
- the bnd-maven-plugin changes the version "X.X.X.<timestamp>"
There is a new instruction in the upcoming 3.2.0 release of the bad-maven-plugin that will allow preserving the “.SNAPSHOT” in the Bundle-Version header.
I’m assuming we want to preserve the “.SNAPSHOT” in the Bundle-Version header, so we’ll need to wait for version 3.2.0 of the bnd-maven-plugin
Export-Package header:
- the maven-bundle-plugin includes “.SNAPSHOT” in the version of exported packages - i.e. org.apache.camel;version=“2.18.0-SNAPSHOT"
- the bnd-maven-plugin does not include “.SNAPSHOT” in the version of the exported packages - i.e. org.apache.camel;version=“2.18.0”
The bad-maven-plugin can be configured to do this by adding a “packageinfo” file for every exported package
Do we need to keep the “.SNAPSHOT” in the exported package versions?
Re: [DISCUSS] - Moving from maven-bundle-plugin to bnd-maven-plugin
and SNAPSHOT versions
Posted by Matt Pavlovich <ma...@gmail.com>.
On 4/5/16 6:29 PM, David Jencks wrote:
> I don’t know how camel is doing release versions after a period of development, but recall that osgi version 1.2.3.SNAPSHOT is after 1.2.3, so if you use normal maven release practices and version the exported packages the same as the bundle version (a terrible idea, but IIUC what you are doing), then a snapshot would be preferred over a release version as it appears to be later.
That's an important point-- the SNAPSHOT being favored over the release
(b/c it is presumed to be *more* current) would be bad mojo.
> david jencks
>
>> On Apr 5, 2016, at 4:15 PM, Quinn Stevenson <qu...@pronoia-solutions.com> wrote:
>>
>> I did manage to get the bnd-maven-plugin to generate the Export-Package header as it is today - with “.SNAPSHOT” on the version - but I had to add a packageinfo file to every exported package (as described by the snippet posted below) - they had the same content, but I had to put them there. This could be a good thing long-term if we ever get to the point of actually versioning the packages instead of just the entire bundle, but it’s a just lot of duplication right now.
>>
>> I’m struggling with coming up with a way I’d actually use multiple SNAPSHOT versions of the same module - I can’t think of where this would make any sense. In fact, it happened to me by accident when working with one client, and it was a huge problem/mess. Further, even if .SNAPSHOT is on the version of the exported package, what exactly does that accomplish? The versions of the exported packages for a given module would always be the same (i.e. they’d always have the .SNAPSHOT at the end), so the only way to tell what version of which package you’re using would be by the Bundle-Version anyway - and it doesn’t help either because it’s listed as .SNAPSHOT. The only way I could see actually using this to any effect would be to use the bnd-maven-plugin default option of putting in a timestamp - that actually provides something you can work with to distinguish bundles and package versions.
>>
>> So while I’m a little nervous changing the export package versioning scheme we use (by dropping the .SNAPSHOT), it feels like the right thing to do in this case.
>>
>> As far as having access to the OSGi Version for the bundle - can you point me to a specific example so I can figure out what I’d do there?
>>
>>> On Apr 5, 2016, at 4:15 PM, Raul Kripalani <ra...@apache.org> wrote:
>>>
>>> On Tue, Apr 5, 2016 at 11:00 PM, Matt Pavlovich <ma...@gmail.com> wrote:
>>>
>>>> I was ruminating about this as well-- I agree its not exact; however, is
>>>> there any real impact? The bundle version is indicated by the SNAPSHOT.
>>>> How would the package export having the .SNAPSHOT qualifier (which would
>>>> not impact any wiring) have any undesirable impact?
>>>>
>>> Hmmm... To be frank, off the top of my head right now, I can't come up with
>>> a scenario where one would want to run coexisting SNAPSHOT and FINAL
>>> modules for the same version. But the fact that one doesn't come to mind
>>> doesn't mean that it's ok to bypass semantic accuracy.
>>>
>>> In fact, the bnd docs even recognise using qualifiers to designate build
>>> specifiers in package exports. So right now it feels like a shortcoming/bug
>>> of the bnd-maven-plugin.
>>>
>>> If you now export the package (from any bundle that has the package on its
>>>> class path), it will be properly versioned.
>>>> bnd.bnd:
>>>> build = ${tstamp}
>>>> Export-Package: com.example.*
>>>> The resulting manifest will look like:
>>>> Manifest:
>>>> Export-Package: com.example; version=1.2.0.*v201010101010*
>>>
>>> http://www.aqute.biz/Bnd/Versioning
>>>
>>> My conclusion is that changing our package export policy as a consequence
>>> of a possible (temporary) bug in the bnd-maven-plugin doesn't seem a sound
>>> approach IMHO.
>>>
>>> My preference would be to open a bug upstream and send a PR to fix the
>>> issue there.
>>>
>>> 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: [DISCUSS] - Moving from maven-bundle-plugin to bnd-maven-plugin and SNAPSHOT versions
Posted by Quinn Stevenson <qu...@pronoia-solutions.com>.
A quick update on this - I was working too hard.
Getting “SNAPSHOT” in the version for the Export-Package header turns out to be pretty simple with the following in the bnd.bnd file
Export-Package: org.apache.camel.*;version=${Bundle-Version}
So this won’t be too hard to accomplish
> On Apr 6, 2016, at 10:39 AM, Quinn Stevenson <qu...@pronoia-solutions.com> wrote:
>
> Thanks Raul -
>
> I didn’t realize the SNAPSHOTs were always deployed. I tried using the SNAPSHOT repository quite a while ago, and it didn’t ever seem to be very current.
>
> Regardless, given the way we generate our Import-Package header today (we don’t use SNAPSHOT there), the versions will resolve. But I would hope that nobody would actually try and use SNAPSHOT versions in production or test. I did that with a customer a couple of years ago, and the chaos was tremendous - bundles updated at the most inopportune moments, and the environment would break. It took quite a while to figure out what was going on and once we did, we changed our policy so that SNAPSHOT versions were only used in development environments.
>
>
>> On Apr 6, 2016, at 9:39 AM, Raul Kripalani <ra...@apache.org> wrote:
>>
>> On Wed, Apr 6, 2016 at 4:35 PM, Quinn Stevenson <quinn@pronoia-solutions.com
>>> wrote:
>>
>>> Also, since Camel doesn’t really “release” any SNAPSHOT builds, this is a
>>> decision that only effects the development community IMO. People
>>> building/using SNAPSHOT versions must understand what’s going on anyway -
>>> either way will work.
>>
>>
>> Actually we do release nightly SNAPSHOTs:
>> https://repository.apache.org/content/groups/snapshots/org/apache/camel/camel-core/2.18-SNAPSHOT
>> .
>>
>> And you can install them directly in a modern Karaf container without
>> downloading them first to your local repo. Karaf is configured OOTB to
>> search in the ASF Snapshots repo.
>>
>> $ feature:repo-add camel 2.18-SNAPSHOT
>>
>> and off you go.
>>
>> *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: [DISCUSS] - Moving from maven-bundle-plugin to bnd-maven-plugin and SNAPSHOT versions
Posted by Quinn Stevenson <qu...@pronoia-solutions.com>.
Thanks Raul -
I didn’t realize the SNAPSHOTs were always deployed. I tried using the SNAPSHOT repository quite a while ago, and it didn’t ever seem to be very current.
Regardless, given the way we generate our Import-Package header today (we don’t use SNAPSHOT there), the versions will resolve. But I would hope that nobody would actually try and use SNAPSHOT versions in production or test. I did that with a customer a couple of years ago, and the chaos was tremendous - bundles updated at the most inopportune moments, and the environment would break. It took quite a while to figure out what was going on and once we did, we changed our policy so that SNAPSHOT versions were only used in development environments.
> On Apr 6, 2016, at 9:39 AM, Raul Kripalani <ra...@apache.org> wrote:
>
> On Wed, Apr 6, 2016 at 4:35 PM, Quinn Stevenson <quinn@pronoia-solutions.com
>> wrote:
>
>> Also, since Camel doesn’t really “release” any SNAPSHOT builds, this is a
>> decision that only effects the development community IMO. People
>> building/using SNAPSHOT versions must understand what’s going on anyway -
>> either way will work.
>
>
> Actually we do release nightly SNAPSHOTs:
> https://repository.apache.org/content/groups/snapshots/org/apache/camel/camel-core/2.18-SNAPSHOT
> .
>
> And you can install them directly in a modern Karaf container without
> downloading them first to your local repo. Karaf is configured OOTB to
> search in the ASF Snapshots repo.
>
> $ feature:repo-add camel 2.18-SNAPSHOT
>
> and off you go.
>
> *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: [DISCUSS] - Moving from maven-bundle-plugin to bnd-maven-plugin
and SNAPSHOT versions
Posted by Raul Kripalani <ra...@apache.org>.
On Wed, Apr 6, 2016 at 4:35 PM, Quinn Stevenson <quinn@pronoia-solutions.com
> wrote:
> Also, since Camel doesn’t really “release” any SNAPSHOT builds, this is a
> decision that only effects the development community IMO. People
> building/using SNAPSHOT versions must understand what’s going on anyway -
> either way will work.
Actually we do release nightly SNAPSHOTs:
https://repository.apache.org/content/groups/snapshots/org/apache/camel/camel-core/2.18-SNAPSHOT
.
And you can install them directly in a modern Karaf container without
downloading them first to your local repo. Karaf is configured OOTB to
search in the ASF Snapshots repo.
$ feature:repo-add camel 2.18-SNAPSHOT
and off you go.
*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: [DISCUSS] - Moving from maven-bundle-plugin to bnd-maven-plugin and SNAPSHOT versions
Posted by Quinn Stevenson <qu...@pronoia-solutions.com>.
I’d like to mention one area where the default behavior of the bnd-maven-plugin with SNAPSHOTs is very useful/helpful.
As stated before, the bnd-maven-plugin sets the Bundle-Version header to X.X.X.<timestamp> by default. When you’re installing/updating bundles in Karaf, this makes it easy to determine if you got what you were after because the timestamp changed.
Also, since Camel doesn’t really “release” any SNAPSHOT builds, this is a decision that only effects the development community IMO. People building/using SNAPSHOT versions must understand what’s going on anyway - either way will work.
> On Apr 6, 2016, at 9:18 AM, Raul Kripalani <ra...@apache.org> wrote:
>
> On Wed, Apr 6, 2016 at 12:29 AM, David Jencks <
> david_jencks@yahoo.com.invalid> wrote:
>
>> I don’t know how camel is doing release versions after a period of
>> development, but recall that osgi version 1.2.3.SNAPSHOT is after 1.2.3, so
>> if you use normal maven release practices and version the exported packages
>> the same as the bundle version (a terrible idea, but IIUC what you are
>> doing), then a snapshot would be preferred over a release version as it
>> appears to be later.
>
>
> David, that's a very good point. Evidence here:
> https://versionatorr.appspot.com/?a=2.18-SNAPSHOT&b=2.18.
> Substituting SNAPSHOT by the timestamp doesn't help either (like
> bnd-maven-plugin does), because OSGi would still consider that version
> higher than one without the timestamp (2.18.0.201504041000 > 2.18.0).
>
> My opinion is that Camel should follow the methodology that OSGI expert
> communities @ the ASF use: Felix and Karaf.
>
> What I'm seeing is that Felix does use the SNAPSHOT qualifier in their
> package exports:
> 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
> .
>
> I'm going to open a cross-community thread to enquire.
>
> 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: [DISCUSS] - Moving from maven-bundle-plugin to bnd-maven-plugin
and SNAPSHOT versions
Posted by Raul Kripalani <ra...@apache.org>.
On Wed, Apr 6, 2016 at 12:29 AM, David Jencks <
david_jencks@yahoo.com.invalid> wrote:
> I don’t know how camel is doing release versions after a period of
> development, but recall that osgi version 1.2.3.SNAPSHOT is after 1.2.3, so
> if you use normal maven release practices and version the exported packages
> the same as the bundle version (a terrible idea, but IIUC what you are
> doing), then a snapshot would be preferred over a release version as it
> appears to be later.
David, that's a very good point. Evidence here:
https://versionatorr.appspot.com/?a=2.18-SNAPSHOT&b=2.18.
Substituting SNAPSHOT by the timestamp doesn't help either (like
bnd-maven-plugin does), because OSGi would still consider that version
higher than one without the timestamp (2.18.0.201504041000 > 2.18.0).
My opinion is that Camel should follow the methodology that OSGI expert
communities @ the ASF use: Felix and Karaf.
What I'm seeing is that Felix does use the SNAPSHOT qualifier in their
package exports:
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
.
I'm going to open a cross-community thread to enquire.
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: [DISCUSS] - Moving from maven-bundle-plugin to bnd-maven-plugin and SNAPSHOT versions
Posted by David Jencks <da...@yahoo.com.INVALID>.
I don’t know how camel is doing release versions after a period of development, but recall that osgi version 1.2.3.SNAPSHOT is after 1.2.3, so if you use normal maven release practices and version the exported packages the same as the bundle version (a terrible idea, but IIUC what you are doing), then a snapshot would be preferred over a release version as it appears to be later.
david jencks
> On Apr 5, 2016, at 4:15 PM, Quinn Stevenson <qu...@pronoia-solutions.com> wrote:
>
> I did manage to get the bnd-maven-plugin to generate the Export-Package header as it is today - with “.SNAPSHOT” on the version - but I had to add a packageinfo file to every exported package (as described by the snippet posted below) - they had the same content, but I had to put them there. This could be a good thing long-term if we ever get to the point of actually versioning the packages instead of just the entire bundle, but it’s a just lot of duplication right now.
>
> I’m struggling with coming up with a way I’d actually use multiple SNAPSHOT versions of the same module - I can’t think of where this would make any sense. In fact, it happened to me by accident when working with one client, and it was a huge problem/mess. Further, even if .SNAPSHOT is on the version of the exported package, what exactly does that accomplish? The versions of the exported packages for a given module would always be the same (i.e. they’d always have the .SNAPSHOT at the end), so the only way to tell what version of which package you’re using would be by the Bundle-Version anyway - and it doesn’t help either because it’s listed as .SNAPSHOT. The only way I could see actually using this to any effect would be to use the bnd-maven-plugin default option of putting in a timestamp - that actually provides something you can work with to distinguish bundles and package versions.
>
> So while I’m a little nervous changing the export package versioning scheme we use (by dropping the .SNAPSHOT), it feels like the right thing to do in this case.
>
> As far as having access to the OSGi Version for the bundle - can you point me to a specific example so I can figure out what I’d do there?
>
>> On Apr 5, 2016, at 4:15 PM, Raul Kripalani <ra...@apache.org> wrote:
>>
>> On Tue, Apr 5, 2016 at 11:00 PM, Matt Pavlovich <ma...@gmail.com> wrote:
>>
>>> I was ruminating about this as well-- I agree its not exact; however, is
>>> there any real impact? The bundle version is indicated by the SNAPSHOT.
>>> How would the package export having the .SNAPSHOT qualifier (which would
>>> not impact any wiring) have any undesirable impact?
>>>
>>
>> Hmmm... To be frank, off the top of my head right now, I can't come up with
>> a scenario where one would want to run coexisting SNAPSHOT and FINAL
>> modules for the same version. But the fact that one doesn't come to mind
>> doesn't mean that it's ok to bypass semantic accuracy.
>>
>> In fact, the bnd docs even recognise using qualifiers to designate build
>> specifiers in package exports. So right now it feels like a shortcoming/bug
>> of the bnd-maven-plugin.
>>
>> If you now export the package (from any bundle that has the package on its
>>> class path), it will be properly versioned.
>>> bnd.bnd:
>>> build = ${tstamp}
>>> Export-Package: com.example.*
>>> The resulting manifest will look like:
>>> Manifest:
>>> Export-Package: com.example; version=1.2.0.*v201010101010*
>>
>>
>> http://www.aqute.biz/Bnd/Versioning
>>
>> My conclusion is that changing our package export policy as a consequence
>> of a possible (temporary) bug in the bnd-maven-plugin doesn't seem a sound
>> approach IMHO.
>>
>> My preference would be to open a bug upstream and send a PR to fix the
>> issue there.
>>
>> 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: [DISCUSS] - Moving from maven-bundle-plugin to bnd-maven-plugin and SNAPSHOT versions
Posted by Quinn Stevenson <qu...@pronoia-solutions.com>.
I did manage to get the bnd-maven-plugin to generate the Export-Package header as it is today - with “.SNAPSHOT” on the version - but I had to add a packageinfo file to every exported package (as described by the snippet posted below) - they had the same content, but I had to put them there. This could be a good thing long-term if we ever get to the point of actually versioning the packages instead of just the entire bundle, but it’s a just lot of duplication right now.
I’m struggling with coming up with a way I’d actually use multiple SNAPSHOT versions of the same module - I can’t think of where this would make any sense. In fact, it happened to me by accident when working with one client, and it was a huge problem/mess. Further, even if .SNAPSHOT is on the version of the exported package, what exactly does that accomplish? The versions of the exported packages for a given module would always be the same (i.e. they’d always have the .SNAPSHOT at the end), so the only way to tell what version of which package you’re using would be by the Bundle-Version anyway - and it doesn’t help either because it’s listed as .SNAPSHOT. The only way I could see actually using this to any effect would be to use the bnd-maven-plugin default option of putting in a timestamp - that actually provides something you can work with to distinguish bundles and package versions.
So while I’m a little nervous changing the export package versioning scheme we use (by dropping the .SNAPSHOT), it feels like the right thing to do in this case.
As far as having access to the OSGi Version for the bundle - can you point me to a specific example so I can figure out what I’d do there?
> On Apr 5, 2016, at 4:15 PM, Raul Kripalani <ra...@apache.org> wrote:
>
> On Tue, Apr 5, 2016 at 11:00 PM, Matt Pavlovich <ma...@gmail.com> wrote:
>
>> I was ruminating about this as well-- I agree its not exact; however, is
>> there any real impact? The bundle version is indicated by the SNAPSHOT.
>> How would the package export having the .SNAPSHOT qualifier (which would
>> not impact any wiring) have any undesirable impact?
>>
>
> Hmmm... To be frank, off the top of my head right now, I can't come up with
> a scenario where one would want to run coexisting SNAPSHOT and FINAL
> modules for the same version. But the fact that one doesn't come to mind
> doesn't mean that it's ok to bypass semantic accuracy.
>
> In fact, the bnd docs even recognise using qualifiers to designate build
> specifiers in package exports. So right now it feels like a shortcoming/bug
> of the bnd-maven-plugin.
>
> If you now export the package (from any bundle that has the package on its
>> class path), it will be properly versioned.
>> bnd.bnd:
>> build = ${tstamp}
>> Export-Package: com.example.*
>> The resulting manifest will look like:
>> Manifest:
>> Export-Package: com.example; version=1.2.0.*v201010101010*
>
>
> http://www.aqute.biz/Bnd/Versioning
>
> My conclusion is that changing our package export policy as a consequence
> of a possible (temporary) bug in the bnd-maven-plugin doesn't seem a sound
> approach IMHO.
>
> My preference would be to open a bug upstream and send a PR to fix the
> issue there.
>
> 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: [DISCUSS] - Moving from maven-bundle-plugin to bnd-maven-plugin
and SNAPSHOT versions
Posted by Raul Kripalani <ra...@apache.org>.
On Tue, Apr 5, 2016 at 11:00 PM, Matt Pavlovich <ma...@gmail.com> wrote:
> I was ruminating about this as well-- I agree its not exact; however, is
> there any real impact? The bundle version is indicated by the SNAPSHOT.
> How would the package export having the .SNAPSHOT qualifier (which would
> not impact any wiring) have any undesirable impact?
>
Hmmm... To be frank, off the top of my head right now, I can't come up with
a scenario where one would want to run coexisting SNAPSHOT and FINAL
modules for the same version. But the fact that one doesn't come to mind
doesn't mean that it's ok to bypass semantic accuracy.
In fact, the bnd docs even recognise using qualifiers to designate build
specifiers in package exports. So right now it feels like a shortcoming/bug
of the bnd-maven-plugin.
If you now export the package (from any bundle that has the package on its
> class path), it will be properly versioned.
> bnd.bnd:
> build = ${tstamp}
> Export-Package: com.example.*
> The resulting manifest will look like:
> Manifest:
> Export-Package: com.example; version=1.2.0.*v201010101010*
http://www.aqute.biz/Bnd/Versioning
My conclusion is that changing our package export policy as a consequence
of a possible (temporary) bug in the bnd-maven-plugin doesn't seem a sound
approach IMHO.
My preference would be to open a bug upstream and send a PR to fix the
issue there.
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: [DISCUSS] - Moving from maven-bundle-plugin to bnd-maven-plugin
and SNAPSHOT versions
Posted by Matt Pavlovich <ma...@gmail.com>.
I was ruminating about this as well-- I agree its not exact; however, is
there any real impact? The bundle version is indicated by the
SNAPSHOT. How would the package export having the .SNAPSHOT qualifier
(which would not impact any wiring) have any undesirable impact?
On 4/5/16 4:48 PM, Raul Kripalani wrote:
> I quoted the wrong part of your email, but the point still stands.
>
> With regards to the package exports, we do need to preserve the indication
> that the module is a snapshot. Otherwise the resulting export is
> indistinguishable from the final version IMHO.
>
> 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>
>
> On Tue, Apr 5, 2016 at 10:45 PM, Raul Kripalani <ra...@apache.org> wrote:
>
>> On Tue, Apr 5, 2016 at 7:58 PM, Quinn Stevenson <
>> quinn@pronoia-solutions.com> wrote:
>>
>>> Do we need to keep the “.SNAPSHOT” in the exported package versions?
>>
>> Does the bnd-maven-plugin feed back the calculated version into the build,
>> perhaps as a property? We need to inject the correct version number
>> downstream in the Karaf features repository (features.xml) for all Camel
>> bundles.
>>
>> Other than that, I'm pretty sure there are other places where the actual
>> OSGi version number is needed. I just can't think of them now.
>>
>> 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: [DISCUSS] - Moving from maven-bundle-plugin to bnd-maven-plugin
and SNAPSHOT versions
Posted by Raul Kripalani <ra...@apache.org>.
I quoted the wrong part of your email, but the point still stands.
With regards to the package exports, we do need to preserve the indication
that the module is a snapshot. Otherwise the resulting export is
indistinguishable from the final version IMHO.
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>
On Tue, Apr 5, 2016 at 10:45 PM, Raul Kripalani <ra...@apache.org> wrote:
>
> On Tue, Apr 5, 2016 at 7:58 PM, Quinn Stevenson <
> quinn@pronoia-solutions.com> wrote:
>
>> Do we need to keep the “.SNAPSHOT” in the exported package versions?
>
>
> Does the bnd-maven-plugin feed back the calculated version into the build,
> perhaps as a property? We need to inject the correct version number
> downstream in the Karaf features repository (features.xml) for all Camel
> bundles.
>
> Other than that, I'm pretty sure there are other places where the actual
> OSGi version number is needed. I just can't think of them now.
>
> 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: [DISCUSS] - Moving from maven-bundle-plugin to bnd-maven-plugin
and SNAPSHOT versions
Posted by Raul Kripalani <ra...@apache.org>.
On Tue, Apr 5, 2016 at 7:58 PM, Quinn Stevenson <quinn@pronoia-solutions.com
> wrote:
> Do we need to keep the “.SNAPSHOT” in the exported package versions?
Does the bnd-maven-plugin feed back the calculated version into the build,
perhaps as a property? We need to inject the correct version number
downstream in the Karaf features repository (features.xml) for all Camel
bundles.
Other than that, I'm pretty sure there are other places where the actual
OSGi version number is needed. I just can't think of them now.
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: [DISCUSS] - Moving from maven-bundle-plugin to bnd-maven-plugin and SNAPSHOT versions
Posted by Quinn Stevenson <qu...@pronoia-solutions.com>.
In my opinion, the benefits of the bnd-maven-plugin vs the maven-bundle-plugin are:
- Easier configuration
You configure the bnd-maven-plugin just like you configure BND - there isn’t any strange XML mapping to BND configuration. Also, it keeps the OSGi configuration separate from the build configuration - in the bnd.bnd file.
- Better performance (maybe)
I haven’t verified this for the new build setup with the “lightweight” process, but building my own projects using the bnd-maven-plugin was significantly faster than using the maven-bundle-plugin.
- Active community
While I’ve been trying this out, the BND community has been very responsive and helpful - even when I mistakenly posted to a closed topic. I still haven’t heard anything about the bug in the maven-bundle-plugin I reported, and I even submitted a patch for it.
I think either will work for us - the “lightweight” build process gets us out of the custom packaging required by the “bundle” type, and we don’t have the situation in the Camel build that the maven-bundle-plugin just doesn’t work for (Blueprint files in alternate locations combined with bundle fragments - a pretty far-out edge-case I know, but it’s what I had to do).
Neil Bartlett’s post explained why the plugin came about ( http://njbartlett.name/2015/03/27/announcing-bnd-maven-plugin.html <http://njbartlett.name/2015/03/27/announcing-bnd-maven-plugin.html> ).
I’ve switched to the bnd-maven-plugin because it’s easier for me to deal with than the maven-bundle-plugin. The implicit exclusion of certain packages, and the automatic export of packages have been very problematic for me. I like the fact that the bnd-maven-plugin forces me to specify what I want exported - I have to think about that - and deciding which packages to export packages to export should be a decision with some thought behind it.
> On Apr 6, 2016, at 1:53 AM, Raul Kripalani <ra...@apache.org> wrote:
>
> I agree with you guys. I have doubts whether going the bnd-maven-plugin
> brings in any actual benefits vs our current setup.
>
> Now that we use the "lightweight" process anyway (no 'bundle' extensions,
> just generating the manifest), both approaches got to be functionally
> equivalent, aside from minor differences like the ones pointed out. At the
> end of the day, it's bnd who does the fieldwork in both cases, and not the
> plugin itself.
>
> I feel bad for Quinn because he's worked on this, and I'm sure it wasn't an
> easy task.
>
> Quinn, what are the benefits vs cons of adopting this plugin, from your
> point of view?
>
> Cheers.
> On 6 Apr 2016 7:49 a.m., "Achim Nierbeck" <bc...@googlemail.com> wrote:
>
>> Hi,
>>
>> just wanted to give my 2 cents here.
>> I'm watching the bnd-maven-plugin for a while now, from my perspective it's
>> not quite there yet, that's why I would stick with the maven-bundle-plugin
>> for a while.
>>
>> regards, Achim
>>
>>
>> 2016-04-06 7:46 GMT+02:00 Claus Ibsen <cl...@gmail.com>:
>>
>>> Hi
>>>
>>> It all sound promising. But there is plenty of changes already for
>>> 2.18 in the build system. We should IMHO keep this version as-is to
>>> avoid too many changes. Building OSGi bundles is really complex for a
>>> project the size as Apache Camel. We need to get what we have now out
>>> to the community.
>>>
>>> Changing to a new plugin seems a bit risky to me at this stage.
>>>
>>> For the next release Camel 2.19 or what the version is, then it can be
>>> on the roadmap and then other issues we discover such as what you
>>> found that required a version 3.2.0 etc can be ironed out.
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Apr 5, 2016 at 8:58 PM, Quinn Stevenson
>>> <qu...@pronoia-solutions.com> wrote:
>>>> I’ve got the basics down for doing this conversion, but there are a
>>> couple of differences between the MANIFEST.MF files generated by the two
>>> tools when SNAPSHOT versions are used.
>>>>
>>>> Bundle-Version header:
>>>> By default, given a version in a POM like "1.2.3-SNAPSHOT”:
>>>> - the maven-bundle-plugin converts the version to “X.X.X.SNAPSHOT"
>>>> - the bnd-maven-plugin changes the version "X.X.X.<timestamp>"
>>>> There is a new instruction in the upcoming 3.2.0 release of the
>>> bad-maven-plugin that will allow preserving the “.SNAPSHOT” in the
>>> Bundle-Version header.
>>>>
>>>> I’m assuming we want to preserve the “.SNAPSHOT” in the Bundle-Version
>>> header, so we’ll need to wait for version 3.2.0 of the bnd-maven-plugin
>>>>
>>>> Export-Package header:
>>>> - the maven-bundle-plugin includes “.SNAPSHOT” in the version of
>>> exported packages - i.e. org.apache.camel;version=“2.18.0-SNAPSHOT"
>>>> - the bnd-maven-plugin does not include “.SNAPSHOT” in the version of
>>> the exported packages - i.e. org.apache.camel;version=“2.18.0”
>>>> The bad-maven-plugin can be configured to do this by adding a
>>> “packageinfo” file for every exported package
>>>>
>>>> Do we need to keep the “.SNAPSHOT” in the exported package versions?
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Claus Ibsen
>>> -----------------
>>> http://davsclaus.com @davsclaus
>>> Camel in Action 2: https://www.manning.com/ibsen2
>>>
>>
>>
>>
>> --
>>
>> Apache Member
>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
>> Project Lead
>> blog <http://notizblog.nierbeck.de/>
>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>
>> Software Architect / Project Manager / Scrum Master
>>
Re: [DISCUSS] - Moving from maven-bundle-plugin to bnd-maven-plugin
and SNAPSHOT versions
Posted by Raul Kripalani <ra...@apache.org>.
I agree with you guys. I have doubts whether going the bnd-maven-plugin
brings in any actual benefits vs our current setup.
Now that we use the "lightweight" process anyway (no 'bundle' extensions,
just generating the manifest), both approaches got to be functionally
equivalent, aside from minor differences like the ones pointed out. At the
end of the day, it's bnd who does the fieldwork in both cases, and not the
plugin itself.
I feel bad for Quinn because he's worked on this, and I'm sure it wasn't an
easy task.
Quinn, what are the benefits vs cons of adopting this plugin, from your
point of view?
Cheers.
On 6 Apr 2016 7:49 a.m., "Achim Nierbeck" <bc...@googlemail.com> wrote:
> Hi,
>
> just wanted to give my 2 cents here.
> I'm watching the bnd-maven-plugin for a while now, from my perspective it's
> not quite there yet, that's why I would stick with the maven-bundle-plugin
> for a while.
>
> regards, Achim
>
>
> 2016-04-06 7:46 GMT+02:00 Claus Ibsen <cl...@gmail.com>:
>
> > Hi
> >
> > It all sound promising. But there is plenty of changes already for
> > 2.18 in the build system. We should IMHO keep this version as-is to
> > avoid too many changes. Building OSGi bundles is really complex for a
> > project the size as Apache Camel. We need to get what we have now out
> > to the community.
> >
> > Changing to a new plugin seems a bit risky to me at this stage.
> >
> > For the next release Camel 2.19 or what the version is, then it can be
> > on the roadmap and then other issues we discover such as what you
> > found that required a version 3.2.0 etc can be ironed out.
> >
> >
> >
> >
> >
> >
> > On Tue, Apr 5, 2016 at 8:58 PM, Quinn Stevenson
> > <qu...@pronoia-solutions.com> wrote:
> > > I’ve got the basics down for doing this conversion, but there are a
> > couple of differences between the MANIFEST.MF files generated by the two
> > tools when SNAPSHOT versions are used.
> > >
> > > Bundle-Version header:
> > > By default, given a version in a POM like "1.2.3-SNAPSHOT”:
> > > - the maven-bundle-plugin converts the version to “X.X.X.SNAPSHOT"
> > > - the bnd-maven-plugin changes the version "X.X.X.<timestamp>"
> > > There is a new instruction in the upcoming 3.2.0 release of the
> > bad-maven-plugin that will allow preserving the “.SNAPSHOT” in the
> > Bundle-Version header.
> > >
> > > I’m assuming we want to preserve the “.SNAPSHOT” in the Bundle-Version
> > header, so we’ll need to wait for version 3.2.0 of the bnd-maven-plugin
> > >
> > > Export-Package header:
> > > - the maven-bundle-plugin includes “.SNAPSHOT” in the version of
> > exported packages - i.e. org.apache.camel;version=“2.18.0-SNAPSHOT"
> > > - the bnd-maven-plugin does not include “.SNAPSHOT” in the version of
> > the exported packages - i.e. org.apache.camel;version=“2.18.0”
> > > The bad-maven-plugin can be configured to do this by adding a
> > “packageinfo” file for every exported package
> > >
> > > Do we need to keep the “.SNAPSHOT” in the exported package versions?
> > >
> > >
> >
> >
> >
> > --
> > Claus Ibsen
> > -----------------
> > http://davsclaus.com @davsclaus
> > Camel in Action 2: https://www.manning.com/ibsen2
> >
>
>
>
> --
>
> Apache Member
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
> Project Lead
> blog <http://notizblog.nierbeck.de/>
> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>
> Software Architect / Project Manager / Scrum Master
>
Re: [DISCUSS] - Moving from maven-bundle-plugin to bnd-maven-plugin
and SNAPSHOT versions
Posted by Matt Pavlovich <ma...@gmail.com>.
On 4/6/16 1:53 AM, Claus Ibsen wrote:
> Yeah all the sister Apache projects like Karaf / ServiceMix / CXF /
> ActiveMQ etc are also using it. Though it begs the question - why 2
> plugins? Why cant they work together and make 1 good plugin. There
> adoption of OSGi do not need more confusion and projects that start to
> stall. Look at blueprint that is semi dead - not updated website and
> whatnot.
Agreed!
>> regards, Achim
>>
>>
>> 2016-04-06 7:46 GMT+02:00 Claus Ibsen <cl...@gmail.com>:
>>
>>> Hi
>>>
>>> It all sound promising. But there is plenty of changes already for
>>> 2.18 in the build system. We should IMHO keep this version as-is to
>>> avoid too many changes. Building OSGi bundles is really complex for a
>>> project the size as Apache Camel. We need to get what we have now out
>>> to the community.
>>>
>>> Changing to a new plugin seems a bit risky to me at this stage.
>>>
>>> For the next release Camel 2.19 or what the version is, then it can be
>>> on the roadmap and then other issues we discover such as what you
>>> found that required a version 3.2.0 etc can be ironed out.
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Apr 5, 2016 at 8:58 PM, Quinn Stevenson
>>> <qu...@pronoia-solutions.com> wrote:
>>>> I’ve got the basics down for doing this conversion, but there are a
>>> couple of differences between the MANIFEST.MF files generated by the two
>>> tools when SNAPSHOT versions are used.
>>>> Bundle-Version header:
>>>> By default, given a version in a POM like "1.2.3-SNAPSHOT”:
>>>> - the maven-bundle-plugin converts the version to “X.X.X.SNAPSHOT"
>>>> - the bnd-maven-plugin changes the version "X.X.X.<timestamp>"
>>>> There is a new instruction in the upcoming 3.2.0 release of the
>>> bad-maven-plugin that will allow preserving the “.SNAPSHOT” in the
>>> Bundle-Version header.
>>>> I’m assuming we want to preserve the “.SNAPSHOT” in the Bundle-Version
>>> header, so we’ll need to wait for version 3.2.0 of the bnd-maven-plugin
>>>> Export-Package header:
>>>> - the maven-bundle-plugin includes “.SNAPSHOT” in the version of
>>> exported packages - i.e. org.apache.camel;version=“2.18.0-SNAPSHOT"
>>>> - the bnd-maven-plugin does not include “.SNAPSHOT” in the version of
>>> the exported packages - i.e. org.apache.camel;version=“2.18.0”
>>>> The bad-maven-plugin can be configured to do this by adding a
>>> “packageinfo” file for every exported package
>>>> Do we need to keep the “.SNAPSHOT” in the exported package versions?
>>>>
>>>>
>>>
>>>
>>> --
>>> Claus Ibsen
>>> -----------------
>>> http://davsclaus.com @davsclaus
>>> Camel in Action 2: https://www.manning.com/ibsen2
>>>
>>
>>
>> --
>>
>> Apache Member
>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
>> Project Lead
>> blog <http://notizblog.nierbeck.de/>
>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>
>> Software Architect / Project Manager / Scrum Master
>
>
Re: [DISCUSS] - Moving from maven-bundle-plugin to bnd-maven-plugin
and SNAPSHOT versions
Posted by Claus Ibsen <cl...@gmail.com>.
On Wed, Apr 6, 2016 at 9:06 AM, Achim Nierbeck <bc...@googlemail.com> wrote:
> It's something I don't get either, why they didn't work on the
> maven-bundle-plugin, but that's something you need to ask the bnd folks.
> blueprint isn't dead btw. just the website really really sucks :D
>
Yeah we know the feeling with a poor website here at Apache Camel ;(
> regards, Achim
>
> 2016-04-06 8:53 GMT+02:00 Claus Ibsen <cl...@gmail.com>:
>
>> On Wed, Apr 6, 2016 at 8:49 AM, Achim Nierbeck <bc...@googlemail.com>
>> wrote:
>> > Hi,
>> >
>> > just wanted to give my 2 cents here.
>> > I'm watching the bnd-maven-plugin for a while now, from my perspective
>> it's
>> > not quite there yet, that's why I would stick with the
>> maven-bundle-plugin
>> > for a while.
>> >
>>
>> Yeah all the sister Apache projects like Karaf / ServiceMix / CXF /
>> ActiveMQ etc are also using it.
>>
>> Though it begs the question - why 2 plugins?
>> Why cant they work together and make 1 good plugin. There adoption of
>> OSGi do not need more confusion and projects that start to stall. Look
>> at blueprint that is semi dead - not updated website and whatnot.
>>
>>
>>
>>
>> > regards, Achim
>> >
>> >
>> > 2016-04-06 7:46 GMT+02:00 Claus Ibsen <cl...@gmail.com>:
>> >
>> >> Hi
>> >>
>> >> It all sound promising. But there is plenty of changes already for
>> >> 2.18 in the build system. We should IMHO keep this version as-is to
>> >> avoid too many changes. Building OSGi bundles is really complex for a
>> >> project the size as Apache Camel. We need to get what we have now out
>> >> to the community.
>> >>
>> >> Changing to a new plugin seems a bit risky to me at this stage.
>> >>
>> >> For the next release Camel 2.19 or what the version is, then it can be
>> >> on the roadmap and then other issues we discover such as what you
>> >> found that required a version 3.2.0 etc can be ironed out.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> On Tue, Apr 5, 2016 at 8:58 PM, Quinn Stevenson
>> >> <qu...@pronoia-solutions.com> wrote:
>> >> > I’ve got the basics down for doing this conversion, but there are a
>> >> couple of differences between the MANIFEST.MF files generated by the two
>> >> tools when SNAPSHOT versions are used.
>> >> >
>> >> > Bundle-Version header:
>> >> > By default, given a version in a POM like "1.2.3-SNAPSHOT”:
>> >> > - the maven-bundle-plugin converts the version to “X.X.X.SNAPSHOT"
>> >> > - the bnd-maven-plugin changes the version "X.X.X.<timestamp>"
>> >> > There is a new instruction in the upcoming 3.2.0 release of the
>> >> bad-maven-plugin that will allow preserving the “.SNAPSHOT” in the
>> >> Bundle-Version header.
>> >> >
>> >> > I’m assuming we want to preserve the “.SNAPSHOT” in the Bundle-Version
>> >> header, so we’ll need to wait for version 3.2.0 of the bnd-maven-plugin
>> >> >
>> >> > Export-Package header:
>> >> > - the maven-bundle-plugin includes “.SNAPSHOT” in the version of
>> >> exported packages - i.e. org.apache.camel;version=“2.18.0-SNAPSHOT"
>> >> > - the bnd-maven-plugin does not include “.SNAPSHOT” in the version of
>> >> the exported packages - i.e. org.apache.camel;version=“2.18.0”
>> >> > The bad-maven-plugin can be configured to do this by adding a
>> >> “packageinfo” file for every exported package
>> >> >
>> >> > Do we need to keep the “.SNAPSHOT” in the exported package versions?
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Claus Ibsen
>> >> -----------------
>> >> http://davsclaus.com @davsclaus
>> >> Camel in Action 2: https://www.manning.com/ibsen2
>> >>
>> >
>> >
>> >
>> > --
>> >
>> > Apache Member
>> > Apache Karaf <http://karaf.apache.org/> Committer & PMC
>> > OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer
>> &
>> > Project Lead
>> > blog <http://notizblog.nierbeck.de/>
>> > Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>> >
>> > Software Architect / Project Manager / Scrum Master
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> http://davsclaus.com @davsclaus
>> Camel in Action 2: https://www.manning.com/ibsen2
>>
>
>
>
> --
>
> Apache Member
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
> Project Lead
> blog <http://notizblog.nierbeck.de/>
> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>
> Software Architect / Project Manager / Scrum Master
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: [DISCUSS] - Moving from maven-bundle-plugin to bnd-maven-plugin
and SNAPSHOT versions
Posted by Achim Nierbeck <bc...@googlemail.com>.
It's something I don't get either, why they didn't work on the
maven-bundle-plugin, but that's something you need to ask the bnd folks.
blueprint isn't dead btw. just the website really really sucks :D
regards, Achim
2016-04-06 8:53 GMT+02:00 Claus Ibsen <cl...@gmail.com>:
> On Wed, Apr 6, 2016 at 8:49 AM, Achim Nierbeck <bc...@googlemail.com>
> wrote:
> > Hi,
> >
> > just wanted to give my 2 cents here.
> > I'm watching the bnd-maven-plugin for a while now, from my perspective
> it's
> > not quite there yet, that's why I would stick with the
> maven-bundle-plugin
> > for a while.
> >
>
> Yeah all the sister Apache projects like Karaf / ServiceMix / CXF /
> ActiveMQ etc are also using it.
>
> Though it begs the question - why 2 plugins?
> Why cant they work together and make 1 good plugin. There adoption of
> OSGi do not need more confusion and projects that start to stall. Look
> at blueprint that is semi dead - not updated website and whatnot.
>
>
>
>
> > regards, Achim
> >
> >
> > 2016-04-06 7:46 GMT+02:00 Claus Ibsen <cl...@gmail.com>:
> >
> >> Hi
> >>
> >> It all sound promising. But there is plenty of changes already for
> >> 2.18 in the build system. We should IMHO keep this version as-is to
> >> avoid too many changes. Building OSGi bundles is really complex for a
> >> project the size as Apache Camel. We need to get what we have now out
> >> to the community.
> >>
> >> Changing to a new plugin seems a bit risky to me at this stage.
> >>
> >> For the next release Camel 2.19 or what the version is, then it can be
> >> on the roadmap and then other issues we discover such as what you
> >> found that required a version 3.2.0 etc can be ironed out.
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Tue, Apr 5, 2016 at 8:58 PM, Quinn Stevenson
> >> <qu...@pronoia-solutions.com> wrote:
> >> > I’ve got the basics down for doing this conversion, but there are a
> >> couple of differences between the MANIFEST.MF files generated by the two
> >> tools when SNAPSHOT versions are used.
> >> >
> >> > Bundle-Version header:
> >> > By default, given a version in a POM like "1.2.3-SNAPSHOT”:
> >> > - the maven-bundle-plugin converts the version to “X.X.X.SNAPSHOT"
> >> > - the bnd-maven-plugin changes the version "X.X.X.<timestamp>"
> >> > There is a new instruction in the upcoming 3.2.0 release of the
> >> bad-maven-plugin that will allow preserving the “.SNAPSHOT” in the
> >> Bundle-Version header.
> >> >
> >> > I’m assuming we want to preserve the “.SNAPSHOT” in the Bundle-Version
> >> header, so we’ll need to wait for version 3.2.0 of the bnd-maven-plugin
> >> >
> >> > Export-Package header:
> >> > - the maven-bundle-plugin includes “.SNAPSHOT” in the version of
> >> exported packages - i.e. org.apache.camel;version=“2.18.0-SNAPSHOT"
> >> > - the bnd-maven-plugin does not include “.SNAPSHOT” in the version of
> >> the exported packages - i.e. org.apache.camel;version=“2.18.0”
> >> > The bad-maven-plugin can be configured to do this by adding a
> >> “packageinfo” file for every exported package
> >> >
> >> > Do we need to keep the “.SNAPSHOT” in the exported package versions?
> >> >
> >> >
> >>
> >>
> >>
> >> --
> >> Claus Ibsen
> >> -----------------
> >> http://davsclaus.com @davsclaus
> >> Camel in Action 2: https://www.manning.com/ibsen2
> >>
> >
> >
> >
> > --
> >
> > Apache Member
> > Apache Karaf <http://karaf.apache.org/> Committer & PMC
> > OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer
> &
> > Project Lead
> > blog <http://notizblog.nierbeck.de/>
> > Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
> >
> > Software Architect / Project Manager / Scrum Master
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>
--
Apache Member
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
blog <http://notizblog.nierbeck.de/>
Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
Software Architect / Project Manager / Scrum Master
Re: [DISCUSS] - Moving from maven-bundle-plugin to bnd-maven-plugin
and SNAPSHOT versions
Posted by Claus Ibsen <cl...@gmail.com>.
On Wed, Apr 6, 2016 at 8:49 AM, Achim Nierbeck <bc...@googlemail.com> wrote:
> Hi,
>
> just wanted to give my 2 cents here.
> I'm watching the bnd-maven-plugin for a while now, from my perspective it's
> not quite there yet, that's why I would stick with the maven-bundle-plugin
> for a while.
>
Yeah all the sister Apache projects like Karaf / ServiceMix / CXF /
ActiveMQ etc are also using it.
Though it begs the question - why 2 plugins?
Why cant they work together and make 1 good plugin. There adoption of
OSGi do not need more confusion and projects that start to stall. Look
at blueprint that is semi dead - not updated website and whatnot.
> regards, Achim
>
>
> 2016-04-06 7:46 GMT+02:00 Claus Ibsen <cl...@gmail.com>:
>
>> Hi
>>
>> It all sound promising. But there is plenty of changes already for
>> 2.18 in the build system. We should IMHO keep this version as-is to
>> avoid too many changes. Building OSGi bundles is really complex for a
>> project the size as Apache Camel. We need to get what we have now out
>> to the community.
>>
>> Changing to a new plugin seems a bit risky to me at this stage.
>>
>> For the next release Camel 2.19 or what the version is, then it can be
>> on the roadmap and then other issues we discover such as what you
>> found that required a version 3.2.0 etc can be ironed out.
>>
>>
>>
>>
>>
>>
>> On Tue, Apr 5, 2016 at 8:58 PM, Quinn Stevenson
>> <qu...@pronoia-solutions.com> wrote:
>> > I’ve got the basics down for doing this conversion, but there are a
>> couple of differences between the MANIFEST.MF files generated by the two
>> tools when SNAPSHOT versions are used.
>> >
>> > Bundle-Version header:
>> > By default, given a version in a POM like "1.2.3-SNAPSHOT”:
>> > - the maven-bundle-plugin converts the version to “X.X.X.SNAPSHOT"
>> > - the bnd-maven-plugin changes the version "X.X.X.<timestamp>"
>> > There is a new instruction in the upcoming 3.2.0 release of the
>> bad-maven-plugin that will allow preserving the “.SNAPSHOT” in the
>> Bundle-Version header.
>> >
>> > I’m assuming we want to preserve the “.SNAPSHOT” in the Bundle-Version
>> header, so we’ll need to wait for version 3.2.0 of the bnd-maven-plugin
>> >
>> > Export-Package header:
>> > - the maven-bundle-plugin includes “.SNAPSHOT” in the version of
>> exported packages - i.e. org.apache.camel;version=“2.18.0-SNAPSHOT"
>> > - the bnd-maven-plugin does not include “.SNAPSHOT” in the version of
>> the exported packages - i.e. org.apache.camel;version=“2.18.0”
>> > The bad-maven-plugin can be configured to do this by adding a
>> “packageinfo” file for every exported package
>> >
>> > Do we need to keep the “.SNAPSHOT” in the exported package versions?
>> >
>> >
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> http://davsclaus.com @davsclaus
>> Camel in Action 2: https://www.manning.com/ibsen2
>>
>
>
>
> --
>
> Apache Member
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
> Project Lead
> blog <http://notizblog.nierbeck.de/>
> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>
> Software Architect / Project Manager / Scrum Master
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: [DISCUSS] - Moving from maven-bundle-plugin to bnd-maven-plugin
and SNAPSHOT versions
Posted by Achim Nierbeck <bc...@googlemail.com>.
Hi,
just wanted to give my 2 cents here.
I'm watching the bnd-maven-plugin for a while now, from my perspective it's
not quite there yet, that's why I would stick with the maven-bundle-plugin
for a while.
regards, Achim
2016-04-06 7:46 GMT+02:00 Claus Ibsen <cl...@gmail.com>:
> Hi
>
> It all sound promising. But there is plenty of changes already for
> 2.18 in the build system. We should IMHO keep this version as-is to
> avoid too many changes. Building OSGi bundles is really complex for a
> project the size as Apache Camel. We need to get what we have now out
> to the community.
>
> Changing to a new plugin seems a bit risky to me at this stage.
>
> For the next release Camel 2.19 or what the version is, then it can be
> on the roadmap and then other issues we discover such as what you
> found that required a version 3.2.0 etc can be ironed out.
>
>
>
>
>
>
> On Tue, Apr 5, 2016 at 8:58 PM, Quinn Stevenson
> <qu...@pronoia-solutions.com> wrote:
> > I’ve got the basics down for doing this conversion, but there are a
> couple of differences between the MANIFEST.MF files generated by the two
> tools when SNAPSHOT versions are used.
> >
> > Bundle-Version header:
> > By default, given a version in a POM like "1.2.3-SNAPSHOT”:
> > - the maven-bundle-plugin converts the version to “X.X.X.SNAPSHOT"
> > - the bnd-maven-plugin changes the version "X.X.X.<timestamp>"
> > There is a new instruction in the upcoming 3.2.0 release of the
> bad-maven-plugin that will allow preserving the “.SNAPSHOT” in the
> Bundle-Version header.
> >
> > I’m assuming we want to preserve the “.SNAPSHOT” in the Bundle-Version
> header, so we’ll need to wait for version 3.2.0 of the bnd-maven-plugin
> >
> > Export-Package header:
> > - the maven-bundle-plugin includes “.SNAPSHOT” in the version of
> exported packages - i.e. org.apache.camel;version=“2.18.0-SNAPSHOT"
> > - the bnd-maven-plugin does not include “.SNAPSHOT” in the version of
> the exported packages - i.e. org.apache.camel;version=“2.18.0”
> > The bad-maven-plugin can be configured to do this by adding a
> “packageinfo” file for every exported package
> >
> > Do we need to keep the “.SNAPSHOT” in the exported package versions?
> >
> >
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>
--
Apache Member
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
blog <http://notizblog.nierbeck.de/>
Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
Software Architect / Project Manager / Scrum Master
Re: [DISCUSS] - Moving from maven-bundle-plugin to bnd-maven-plugin
and SNAPSHOT versions
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
It all sound promising. But there is plenty of changes already for
2.18 in the build system. We should IMHO keep this version as-is to
avoid too many changes. Building OSGi bundles is really complex for a
project the size as Apache Camel. We need to get what we have now out
to the community.
Changing to a new plugin seems a bit risky to me at this stage.
For the next release Camel 2.19 or what the version is, then it can be
on the roadmap and then other issues we discover such as what you
found that required a version 3.2.0 etc can be ironed out.
On Tue, Apr 5, 2016 at 8:58 PM, Quinn Stevenson
<qu...@pronoia-solutions.com> wrote:
> I’ve got the basics down for doing this conversion, but there are a couple of differences between the MANIFEST.MF files generated by the two tools when SNAPSHOT versions are used.
>
> Bundle-Version header:
> By default, given a version in a POM like "1.2.3-SNAPSHOT”:
> - the maven-bundle-plugin converts the version to “X.X.X.SNAPSHOT"
> - the bnd-maven-plugin changes the version "X.X.X.<timestamp>"
> There is a new instruction in the upcoming 3.2.0 release of the bad-maven-plugin that will allow preserving the “.SNAPSHOT” in the Bundle-Version header.
>
> I’m assuming we want to preserve the “.SNAPSHOT” in the Bundle-Version header, so we’ll need to wait for version 3.2.0 of the bnd-maven-plugin
>
> Export-Package header:
> - the maven-bundle-plugin includes “.SNAPSHOT” in the version of exported packages - i.e. org.apache.camel;version=“2.18.0-SNAPSHOT"
> - the bnd-maven-plugin does not include “.SNAPSHOT” in the version of the exported packages - i.e. org.apache.camel;version=“2.18.0”
> The bad-maven-plugin can be configured to do this by adding a “packageinfo” file for every exported package
>
> Do we need to keep the “.SNAPSHOT” in the exported package versions?
>
>
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: [DISCUSS] - Moving from maven-bundle-plugin to bnd-maven-plugin
and SNAPSHOT versions
Posted by Matt Pavlovich <ma...@gmail.com>.
I think its important to consider that Camel moving to bnd-maven-plugin
will mean most users will do the same, or inherit their projects from a
camel-parent pom or camel-bom. I suggest that end-user Camel projects be
included as a use case, along with the Camel source tree itself.
On 4/5/16 1:58 PM, Quinn Stevenson wrote:
> I’ve got the basics down for doing this conversion, but there are a couple of differences between the MANIFEST.MF files generated by the two tools when SNAPSHOT versions are used.
>
> Bundle-Version header:
> By default, given a version in a POM like "1.2.3-SNAPSHOT”:
> - the maven-bundle-plugin converts the version to “X.X.X.SNAPSHOT"
> - the bnd-maven-plugin changes the version "X.X.X.<timestamp>"
> There is a new instruction in the upcoming 3.2.0 release of the bad-maven-plugin that will allow preserving the “.SNAPSHOT” in the Bundle-Version header.
>
> I’m assuming we want to preserve the “.SNAPSHOT” in the Bundle-Version header, so we’ll need to wait for version 3.2.0 of the bnd-maven-plugin
+1 .SNAPSHOT should be maintained vs timestamp.
> Export-Package header:
> - the maven-bundle-plugin includes “.SNAPSHOT” in the version of exported packages - i.e. org.apache.camel;version=“2.18.0-SNAPSHOT"
> - the bnd-maven-plugin does not include “.SNAPSHOT” in the version of the exported packages - i.e. org.apache.camel;version=“2.18.0”
> The bad-maven-plugin can be configured to do this by adding a “packageinfo” file for every exported package
>
> Do we need to keep the “.SNAPSHOT” in the exported package versions?
I believe this may be OSGi runtime specific, but I know having a
.$OTHERSTUFF after the X.Y.Z is valid in Karaf+Felix.
Interesting idea using the "2.18.0" for exports on packages. I could see
that being handy.
-Matt