BndTools release

[Alexander]

Hi all,

On the OSGi blog Peter mentions some work on integrating BndTools with
Maven (m2-eclipse) during the hackaton. I'd like to know if there is a
release date for these changes. For one of the projects I am working
on, we need to use Maven for dependency management. But for OSGi I'd
like to use BndTools. Having some possibilities to use a combination
of both would greatly help me setting up an environment which fits the
company policy.

TiA,

Alex

[Peter Kriens]

Watch this space ... we need a small change in bndtools to not build anymore and leave it up to maven. We also need a new version for m2-eclipse since it must pickup the bnd.bnd file, then some documentation, and we need some testing ...

Kind regards,

Peter Kriens

[Alexander Broekhuis]

Hi,

Thx for the reply,

As I am not familiar with m2-eclipse, does all of this also work with Maven from the commandline?

If needed, I can help testing.

2011/10/17 Peter Kriens <peter....@aqute.biz>

--
Met vriendelijke groet,

Alexander Broekhuis

[Peter Kriens]

That would be helpful, could you also with the documentation once it works?

Kind regards,

Peter Kriens

[Alexander Broekhuis]

Yes we can also pick some of that up. Since we probably need some documentation ourselves, so sharing is no problem.

2011/10/17 Peter Kriens <peter....@aqute.biz>

[Leen Toelen]

Hi,

for most of my projects I use bndtools to maintain bnd.bnd. In the
maven pom I use maven-bundle-plugin whihc is than triggered by
jenkins.

Combining these two works like a charm.

<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<version>2.0.0</version>
<extensions>true</extensions>
<configuration>
<instructions>
<_include>bnd.bnd</_include>
</instructions>
</configuration>
</plugin>

Regards,
Leen

[Neil Bartlett]

Thanks Leen. Yes this is basically the way to make the two tools work together, but we will make this work more smoothly.

For example, recent versions of m2e include much better incremental builder support than older versions, even with plug-ins such as maven-bundle-plugin in use. Therefore m2e will take over the incremental building, so in Bndtools we need to detect that m2e is present and not perform the builds ourselves.

This leaves us with providing the bnd file editor, and running OSGi applications (including hot-replace of rebuilt bundles). We think we can do a much better job at managing runtimes using OBR, because Maven's model of runtime dependencies is badly broken.

Rgds

Neil

[Alexander Broekhuis]

Hi,

Interesting solution :). How does all of this relate to dependency management used in Maven? Although I can agree with the objections, we use a Maven repository (Nexus) and this is one of the parts of the process I cannot change.

Nexus is used to retrieve dependencies, but also to release artifacts. Is this possible using maven+bndtools?

Also, Maven uses a model in which one project is one bundle, can this be ignored using maven+bndtools? Having a separate (no 1 to 1 relation) development model and deployment models makes much more sense.

2011/10/17 Neil Bartlett <njbar...@gmail.com>

[Neil Bartlett]

Yes, supporting Nexus repositories is fairly simple. We can do it already using a Repository Plugin into bnd, but we will soon enhance it to use OBR metadata.

Regarding multi-bundle projects: if you are using Maven then you should stick with one output artefact per project. You will be continuously fighting Maven if you try to break this rule.

Rgds

Neil

[Alexander Broekhuis]

Thanks for the reply.

2011/10/17 Neil Bartlett <njbar...@gmail.com>

Yes, supporting Nexus repositories is fairly simple. We can do it already using a Repository Plugin into bnd, but we will soon enhance it to use OBR metadata.

I have used the repository plugin, and for using artifacts this was ok, but at that time it was not yet possible to upload to Nexus, has this changed recently?

 

Regarding multi-bundle projects: if you are using Maven then you should stick with one output artefact per project. You will be continuously fighting Maven if you try to break this rule.

To bad, this might be a problem for some of our projects. But I will have to look at it to see how it can fit.

[Martin Ellis]

Hi Neil,

Could you clarify something here, please?

On 17 October 2011 08:40, Neil Bartlett <njbar...@gmail.com> wrote:
> recent versions of m2e include much better incremental builder
> support than older versions, even with plug-ins such as maven-bundle-plugin
> in use. Therefore m2e will take over the incremental building, so in
> Bndtools we need to detect that m2e is present and not perform the builds
> ourselves.

Do you just mean that m2e will take over incremental compilation? Or,
do you mean m2e will also be updating the manifest, and/or creating a
jar?

The reason I ask is that I haven't found a way to get m2e to run the
'process-classes' phase of the maven lifecycle, which is the phase to
which I have attached the bundle plugin.

> This leaves us with providing the bnd file editor, and running OSGi
> applications (including hot-replace of rebuilt bundles). We think we can do
> a much better job at managing runtimes using OBR, because Maven's model of
> runtime dependencies is badly broken.

Hmm. I'm not sure exactly why you say it's broken, but it's still
usable for assembling bundles in to a distributable runtime package.
I'd be a little worried about having bndtools determine the runtime
jars during development, only to have maven pick a different set for
offline builds.

(One solution to that, perhaps, would be to have an OBR-aware maven
plugin that packages up the runtime bundles.)

Martin

[Neil Bartlett]

Hello Martin,

Comments inline below.

Neil

On Monday, 17 October 2011 at 11:24, Martin Ellis wrote:

Do you just mean that m2e will take over incremental compilation? Or,
do you mean m2e will also be updating the manifest, and/or creating a
jar?

Essentially yes, though m2e has never done incremental compilation…. neither has Bndtools, that is the job of Eclipse JDT. But m2e will be updating the manifest and creating the JARs, which is part of what Bndtools would do in a non-Maven project.

The reason I ask is that I haven't found a way to get m2e to run the
'process-classes' phase of the maven lifecycle, which is the phase to
which I have attached the bundle plugin.

Stuart McCulloch from Sonatype did some work to make the maven-bundle-plugin work with m2e's incremental builds and showed a demo of this working… however I don't know about the release schedule for that work so it would be better to talk to him or ask on the m2e mailing lists.

Hmm. I'm not sure exactly why you say it's broken, but it's still
usable for assembling bundles in to a distributable runtime package.
I'd be a little worried about having bndtools determine the runtime
jars during development, only to have maven pick a different set for
offline builds.

Maven just doesn't have a good model of runtime dependencies… they are based on whole module dependencies (similar to Require-Bundle) and they must be maintained manually in the POMs, which means they can easily get out of sync with reality and often require dragging down far more dependencies than are really necessary. In other words… broken.

Please clarify the second sentence; are you talking about builds or runtime? Bndtools will not interfere at all with the build-time dependencies, whether offline, command line or in the IDE.

[Martin Ellis]

On 17 October 2011 12:05, Neil Bartlett <njbar...@gmail.com> wrote:
> Stuart McCulloch from Sonatype did some work to make the maven-bundle-plugin
> work with m2e's incremental builds and showed a demo of this working…
> however I don't know about the release schedule for that work so it would be
> better to talk to him or ask on the m2e mailing lists.

Aha. That sounds very useful. I'll keep an eye out.

> Maven just doesn't have a good model of runtime dependencies… they are based
> on whole module dependencies (similar to Require-Bundle) and they must be
> maintained manually in the POMs, which means they can easily get out of sync
> with reality and often require dragging down far more dependencies than are
> really necessary. In other words… broken.

I didn't say it was good, I said it was usable. ;o)

I think there are still benefits to using OSGi, even with Maven's
limited model of dependencies. You might ask "why use Maven for
dependencies?", but for us, it seems like the best path at the moment.
We can build everything with Maven, but not everything we have can
based on OSGi (e.g. we have Sonar and Maven plugins).

> Please clarify the second sentence; are you talking about builds or runtime?
> Bndtools will not interfere at all with the build-time dependencies, whether
> offline, command line or in the IDE.

Um... Consider a maven project that creates an assembly including an
OSGi framework, and a bunch of bundles. The version of those bundles
is specified (explicitly or implicitly) in the pom.xml files. All
bundles in the assembly are intended to be used at runtime.

I was worried whether a situation could arise in which bndtools starts
up a framework with a different set of bundle versions as compared to
the versions that were included in that assembly. That is, whether
the bundle versions included in the built product might differ to the
resolution calculated by bnd (which might be more 'accurate' in an
OSGi sense).

Martin

[Stuart McCulloch]

On 17 Oct 2011, at 07:34, Alexander wrote:

> Hi all,
>
> On the OSGi blog Peter mentions some work on integrating BndTools with
> Maven (m2-eclipse) during the hackaton. I'd like to know if there is a
> release date for these changes.

The changes to m2eclipse are already available in version 0.6.0.201110151902 of the m2e-tycho configurator from the m2e catalog.

You can see if this version is installed by looking at the About Eclipse->Installation Details->Installed Software page.

If it's not installed go to Preferences->Maven->Discovery->Open Catalog, find the Tycho entry, select the checkbox and press Finish.

Then make sure the rest of m2e is up-to-date by using Help->Check For Updates.

Note: the m2e-tycho configurator is also installed when you import an existing Maven project that uses the maven-bundle-plugin. During the import wizard there should be a page called "Setup Maven plugin connectors" with a list of Maven plugins with red/green markers. If you click the "Auto Select" button it should schedule installation of the m2e-tycho configurator.

The recent improvement in m2e (thanks to Igor Fedorenko) was automatic regeneration of the manifest when the bnd instructions in the Maven pom change, or when a bnd file included from the Maven pom changes. This, coupled with Igor's previous work integrating the Maven and Eclipse/PDE backends, means you can develop OSGi bundles incrementally in Eclipse while still being able to drop to the command-line and get the same results from Maven.

To get the best results you should also use the latest 2.4.0-SNAPSHOT of the maven-bundle-plugin (http://www.mail-archive.com/us...@felix.apache.org/msg11255.html) and add <unpackBundle>true</unpackBundle> to the configuration section of the maven-bundle-plugin (ie. outside of the instructions). This setting will make sure that any bnd generated resources, such as declarative services xml, will be unpacked and made available to PDE whenever the manifest or bundle is regenerated.

You can then incrementally develop DS components using Java annotations (http://www.aqute.biz/Blog/20091020) and have m2e/bnd keep the generated XML up-to-date (discussed under https://issues.apache.org/jira/browse/FELIX-3170).

I'll try to find time over the next week or so to put together a video to demonstrate this - but feel free to try out the latest m2e and especially the bundleplugin snapshot.

--
Cheers, Stuart

[Stuart McCulloch]

On 17 Oct 2011, at 08:25, Alexander Broekhuis wrote:

Hi,

Thx for the reply,

As I am not familiar with m2-eclipse, does all of this also work with Maven from the commandline?

The aim with the latest m2e is that Maven projects should produce the same results from inside Eclipse versus the command-line

If needed, I can help testing.

Yes please! I've attached details of the new setup in a reply to your original email, if you run into problems or have any questions just email the list and I'll try to help

[Stuart McCulloch]

On 17 Oct 2011, at 08:29, Leen Toelen wrote:

> Hi,
>
> for most of my projects I use bndtools to maintain bnd.bnd. In the
> maven pom I use maven-bundle-plugin whihc is than triggered by
> jenkins.
>
> Combining these two works like a charm.
>
> <plugin>
> <groupId>org.apache.felix</groupId>
> <artifactId>maven-bundle-plugin</artifactId>
> <version>2.0.0</version>
> <extensions>true</extensions>
> <configuration>
> <instructions>
> <_include>bnd.bnd</_include>
> </instructions>
> </configuration>
> </plugin>

Yes this is a good approach, and with the latest m2e installed it should regenerate the manifest whenever you change the instructions in bnd.bnd from Eclipse.

[Stuart McCulloch]

On 17 Oct 2011, at 08:48, Alexander Broekhuis wrote:

Hi,

Interesting solution :). How does all of this relate to dependency management used in Maven? Although I can agree with the objections, we use a Maven repository (Nexus) and this is one of the parts of the process I cannot change.

If you're just using m2e with the maven-bundle-plugin then it will use Maven dependencies during the build, and Eclipse projects/target platform when launching. With bndtools installed we should be able to include bundles pulled from OBR in the launch configuration (but this is something we still need to try out). Note: you can expose a Nexus based repository as an OBR, by using the nexus-obr-plugin.

Nexus is used to retrieve dependencies, but also to release artifacts. Is this possible using maven+bndtools?

Also, Maven uses a model in which one project is one bundle, can this be ignored using maven+bndtools? Having a separate (no 1 to 1 relation) development model and deployment models makes much more sense.

You'd still want to develop using one project per-bundle, because Maven only allows one main artifact per-project (Maven does let you attach other artifacts with different classifiers - but that is supposed to be used to attach things like sources and javadoc, rather than different bundles). However, just because you develop using one project per-bundle doesn't mean you have to have multiple projects for deployment. You could use OBR, Eclipse features, or a target platform, to manage the deployment side.

But wrt. Maven development, I strongly recommend you stick to one bundle per-project.

[Stuart McCulloch]

On 17 Oct 2011, at 08:57, Alexander Broekhuis wrote:

Thanks for the reply.

2011/10/17 Neil Bartlett <njbar...@gmail.com>

Yes, supporting Nexus repositories is fairly simple. We can do it already using a Repository Plugin into bnd, but we will soon enhance it to use OBR metadata.

I have used the repository plugin, and for using artifacts this was ok, but at that time it was not yet possible to upload to Nexus, has this changed recently? 

Note it should be possible to add this feature if required, because Nexus provides a REST API to upload artifacts and generate metadata/checksums, etc.

[Stuart McCulloch]

On 17 Oct 2011, at 11:24, Martin Ellis wrote:

> Hi Neil,
>
> Could you clarify something here, please?
>
> On 17 October 2011 08:40, Neil Bartlett <njbar...@gmail.com> wrote:
>> recent versions of m2e include much better incremental builder
>> support than older versions, even with plug-ins such as maven-bundle-plugin
>> in use. Therefore m2e will take over the incremental building, so in
>> Bndtools we need to detect that m2e is present and not perform the builds
>> ourselves.
>
> Do you just mean that m2e will take over incremental compilation? Or,
> do you mean m2e will also be updating the manifest, and/or creating a
> jar?

The way it works in the latest m2e is that Eclipse handles the incremental compilation, and the m2e-tycho configurator updates the manifest as/when required. Because m2e uses the Eclipse/PDE launcher, which expects unpacked bundles, then we don't need to always rebuild the jar. But you could request a full build by using the "Run As... mvn install" command. And with the latest maven-bundle-plugin snapshot you can ask it to selectively unpack generated resources when the manifest is regenerated, which is useful if you're using bnd to generate declarative services XML.

> The reason I ask is that I haven't found a way to get m2e to run the
> 'process-classes' phase of the maven lifecycle, which is the phase to
> which I have attached the bundle plugin.

That should be handled transparently using the latest m2e (from Eclipse Marketplace) ... just import your Maven project and use "Auto Select" on the "Setup Maven Plugin Connectors" page to install the m2e-tycho configurator. It should be able to handle executions of the maven-bundle-plugin at any stage of the lifecycle, just like CLI Maven.

>> This leaves us with providing the bnd file editor, and running OSGi
>> applications (including hot-replace of rebuilt bundles). We think we can do
>> a much better job at managing runtimes using OBR, because Maven's model of
>> runtime dependencies is badly broken.
>
> Hmm. I'm not sure exactly why you say it's broken, but it's still
> usable for assembling bundles in to a distributable runtime package.
> I'd be a little worried about having bndtools determine the runtime
> jars during development, only to have maven pick a different set for
> offline builds.

You can get that sort of fidelity with m2e and the maven-bundle-plugin, just don't add the bndtools classpath nature (we're still working on how this will participate with m2e). Our goal is to allow people to use the bndtools editors even if they don't want to use its repository/obr driven classpath.

[Simon Chemouil]

Hi Stuart!

This is a very nice development. Just a clarification though, does
this
help when I use ``unimported'' packages in my code, i.e will it
trigger
manifest regeneration?

As you might remember, I'm using maven-bundle-plugin with M2E and in
fact we rarely change bnd instructions (basically, all bundles simply
say don't export internal, and import whatever you need).

What we need though is the regeneration of the manifest when we start
using ``unimported'' API during development, because currently we have
to do a mvn package manually to regenerate (and extract) the manifest
or
we get NCDFEs at runtime.

If am I understanding right, the m2e-tycho-configurator doesn't do
anything about this use case, but that's where BndTools' interaction
with M2E will kick in. Please confirm :)

Also, thank you and the others involved with all these improvements in
the tooling, it is greatly appreciated (and used)! I want to add that
this Maven support and integration with M2E -- which has also vastly
improved recently -- is very welcome, even though I share the opinion
here that Maven has its flaws.

Simon

PS: Sorry if this mail gets be published twice, I sent it from my
local
MUA but Google seemed not to accept it (and silently so), so I'm
trying again.

On Oct 18, 1:56 am, Stuart McCulloch <mccu...@gmail.com> wrote:
> On 17 Oct 2011, at 07:34, Alexander wrote:
>
> > Hi all,
>
> > On the OSGi blog Peter mentions some work on integrating BndTools with
> > Maven (m2-eclipse) during the hackaton. I'd like to know if there is a
> > release date for these changes.
>
> The changes to m2eclipse are already available in version 0.6.0.201110151902 of the m2e-tycho configurator from the m2e catalog.
>
> You can see if this version is installed by looking at the About Eclipse->Installation Details->Installed Software page.
>
> If it's not installed go to Preferences->Maven->Discovery->Open Catalog, find the Tycho entry, select the checkbox and press Finish.
>
> Then make sure the rest of m2e is up-to-date by using Help->Check For Updates.
>
> Note: the m2e-tycho configurator is also installed when you import an existing Maven project that uses the maven-bundle-plugin. During the import wizard there should be a page called "Setup Maven plugin connectors" with a list of Maven plugins with red/green markers. If you click the "Auto Select" button it should schedule installation of the m2e-tycho configurator.
>
> The recent improvement in m2e (thanks to Igor Fedorenko) was automatic regeneration of the manifest when the bnd instructions in the Maven pom change, or when a bnd file included from the Maven pom changes. This, coupled with Igor's previous work integrating the Maven and Eclipse/PDE backends, means you can develop OSGi bundles incrementally in Eclipse while still being able to drop to the command-line and get the same results from Maven.
>
> To get the best results you should also use the latest 2.4.0-SNAPSHOT of the maven-bundle-plugin (http://www.mail-archive.com/us...@felix.apache.org/msg11255.html) and add <unpackBundle>true</unpackBundle> to the configuration section of the maven-bundle-plugin (ie. outside of the instructions). This setting will make sure that any bnd generated resources, such as declarative services xml, will be unpacked and made available to PDE whenever the manifest or bundle is regenerated.
>

> You can then incrementally develop DS components using Java annotations (http://www.aqute.biz/Blog/20091020) and have m2e/bnd keep the generated XML up-to-date (discussed underhttps://issues.apache.org/jira/browse/FELIX-3170).

[Ferry Huberts]

On 10/18/2011 09:48 AM, Simon Chemouil wrote:
> Hi Stuart!
>
> This is a very nice development. Just a clarification though, does
> this
> help when I use ``unimported'' packages in my code, i.e will it
> trigger
> manifest regeneration?
>
> As you might remember, I'm using maven-bundle-plugin with M2E and in
> fact we rarely change bnd instructions (basically, all bundles simply
> say don't export internal, and import whatever you need).
>
> What we need though is the regeneration of the manifest when we start
> using ``unimported'' API during development, because currently we have
> to do a mvn package manually to regenerate (and extract) the manifest
> or
> we get NCDFEs at runtime.

The new bndtools will act similar to PDE; warn you that the package you
are using is not in your imports, and even offer a quick fix :-)
After you save the file, the java builder does an incremental build, and
bnd will regenerate the manifest (through the bundle plugin).

Isn't it great? ;-)

We're working hard at fixing up the last issues before release, please
be patient.

--
Ferry Huberts

[Simon Chemouil]

On Oct 18, 10:11 am, Ferry Huberts <maili...@hupie.com> wrote:
> The new bndtools will act similar to PDE; warn you that the package you
> are using is not in your imports, and even offer a quick fix :-)
> After you save the file, the java builder does an incremental build, and
> bnd will regenerate the manifest (through the bundle plugin).
>
> Isn't it great? ;-)

Oh, I get it now -- M2E's incremental builder will now trigger the
bundle-plugin at every save regardless of BndTools, so I should be
able to try that right now (I can't find the time to try it out just
yet, but will do asap).
In general I'm using wildcard imports with bnd, so I guess I won't
have that warning often ;). I agree it's a nice thing to have when
your classpath container is not inferred from your Manifest
dependencies like PDE does.

> We're working hard at fixing up the last issues before release, please
> be patient.

Good luck! And I am in no rush since I won't have time to try all that
goodness on my work projects before some time.

Thanks for your reply,

Simon

[Neil Bartlett]

Actually the quickfix will be for setting up the *build* path, not the bundle imports themselves (which are best left as Import-Package: *).

Essentially if we see an unresolved import statement in Java source, we will offer two quickfixes:

1) Add to -buildpackages, so the package can be automatically resolved at build time against the OBR repositories.

2) Resolve to find bundles exporting that package, and and to -buildpath.

Note that both of these are bnd-specific builds and will not work with Maven builds. Then again, m2e may provide its own quickfixes in this area.

Rgds

Neil

[Simon Chemouil]

Hi Neil,

In that case, if I'm not mistaken, one would have to copy/paste or
write down the import statement before running into that situation.
This is useful when updating/changing the build for an existing
project where the code is already written and supposedly valid, but in
my experience when an import is not resolved by JDT's "Organize
Imports" it is quicker to simply go add the bundle to your -buildpath
or Maven dependencies manually, where we have editors with UIs with
filtering/completion, and call the magical Ctrl-Shift-O after :-).

For the record, that quickfix already exists in M2E ("Find artifact
exporting package" or something along these lines) but I've yet to see
it work ;).

Simon

On Oct 18, 10:29 am, Neil Bartlett <njbartl...@gmail.com> wrote:
> Actually the quickfix will be for setting up the *build* path, not the bundle imports themselves (which are best left as Import-Package: *).
>
> Essentially if we see an unresolved import statement in Java source, we will offer two quickfixes:
>
> 1) Add to -buildpackages, so the package can be automatically resolved at build time against the OBR repositories.
> 2) Resolve to find bundles exporting that package, and and to -buildpath.
>
> Note that both of these are bnd-specific builds and will not work with Maven builds. Then again, m2e may provide its own quickfixes in this area.
>
> Rgds
> Neil
>
>
>
>
>
>
>
> On Tuesday, 18 October 2011 at 09:23, Simon Chemouil wrote:

[Alexander Broekhuis]

Hi Stuart,

Thanks for the extensive replies, see some questions inline:

The changes to m2eclipse are already available in version 0.6.0.201110151902 of the m2e-tycho configurator from the m2e catalog.

You can see if this version is installed by looking at the About Eclipse->Installation Details->Installed Software page.

If it's not installed go to Preferences->Maven->Discovery->Open Catalog, find the Tycho entry, select the checkbox and press Finish.

Then make sure the rest of m2e is up-to-date by using Help->Check For Updates.

I've installed the latest version according to my 3.7.0 Eclipse.

Tycho Configurator: 0.6.0... (as mentioned above)

m2e: 1.0.100

maven-bundle-plugin: 2.4.0-SNAPSHOT

In a new workspace I've created a maven project (without BndTools for now), and added one simple example.

Note: the m2e-tycho configurator is also installed when you import an existing Maven project that uses the maven-bundle-plugin. During the import wizard there should be a page called "Setup Maven plugin connectors" with a list of Maven plugins with red/green markers. If you click the "Auto Select" button it should schedule installation of the m2e-tycho configurator.

I have no existing projects to test this with, creating a new project and adding the maven-bundle-plugin should work equally? I think I still have to add the tycho plugin, but can't find out how to do this. Is this needed, if so how? Some examples on the web show a plugin entry, but using those resulted in errors. I must be overlooking something simple somewhere..

 

The recent improvement in m2e (thanks to Igor Fedorenko) was automatic regeneration of the manifest when the bnd instructions in the Maven pom change, or when a bnd file included from the Maven pom changes. This, coupled with Igor's previous work integrating the Maven and Eclipse/PDE backends, means you can develop OSGi bundles incrementally in Eclipse while still being able to drop to the command-line and get the same results from Maven.

Is this in the version of Tycho/M2e which I am using? Or should I install some development build? If so, where can I find these? I tried to use the milestone update site as explained on [1], but that resulted in an error (no update site at that location?).

If this is already in the current version, is there something I need to enable? I am not seeing the automatic updates, while building through maven works.

 

To get the best results you should also use the latest 2.4.0-SNAPSHOT of the maven-bundle-plugin (http://www.mail-archive.com/us...@felix.apache.org/msg11255.html) and add <unpackBundle>true</unpackBundle> to the configuration section of the maven-bundle-plugin (ie. outside of the instructions). This setting will make sure that any bnd generated resources, such as declarative services xml, will be unpacked and made available to PDE whenever the manifest or bundle is regenerated.

 How can I test and verify this behavior?

Thanks for the help!

[1]: http://wiki.eclipse.org/M2E_updatesite_and_gittags 

[Martin Ellis]

On 18 October 2011 01:40, Stuart McCulloch <mcc...@gmail.com> wrote:
> You can get that sort of fidelity with m2e and the maven-bundle-plugin, just don't add the bndtools classpath nature (we're still working on how this will participate with m2e). Our goal is to allow people to use the bndtools editors even if they don't want to use its repository/obr driven classpath.

This is very welcome news, indeed! :o)

Martin

[Stuart McCulloch]

On 18 Oct 2011, at 08:48, Simon Chemouil wrote:

> Hi Stuart!
>
> This is a very nice development. Just a clarification though, does
> this
> help when I use ``unimported'' packages in my code, i.e will it
> trigger
> manifest regeneration?
>
> As you might remember, I'm using maven-bundle-plugin with M2E and in
> fact we rarely change bnd instructions (basically, all bundles simply
> say don't export internal, and import whatever you need).
>
> What we need though is the regeneration of the manifest when we start
> using ``unimported'' API during development, because currently we have
> to do a mvn package manually to regenerate (and extract) the manifest
> or
> we get NCDFEs at runtime.
>
> If am I understanding right, the m2e-tycho-configurator doesn't do
> anything about this use case, but that's where BndTools' interaction
> with M2E will kick in. Please confirm :)

When you save the file JDT will do an incremental build and notify the m2e-tycho-configurator. The tycho configurator requests a manifest regeneration via the maven-bundle-plugin, using the configuration from the pom.xml (and any included bnd files). Eclipse will then pick up this new manifest when launching the application, etc. You can use the "PDE Tools->Open Manifest" menu option to view the manifest - it might not show up in the package explorer as it's a generated/derived file. Also note that the jar won't get updated on every incremental build, but you can request that with "Run As...->Maven install".

The part we still need to work on is the behaviour when both bndtools and m2e natures are attached to a project, because you'll typically want the bndtool editors but not necessarily its buildpath container (since that's already provided by m2e).

[Stuart McCulloch]

On 18 Oct 2011, at 09:37, Simon Chemouil wrote:

> Hi Neil,
>
> In that case, if I'm not mistaken, one would have to copy/paste or
> write down the import statement before running into that situation.
> This is useful when updating/changing the build for an existing
> project where the code is already written and supposedly valid, but in
> my experience when an import is not resolved by JDT's "Organize
> Imports" it is quicker to simply go add the bundle to your -buildpath
> or Maven dependencies manually, where we have editors with UIs with
> filtering/completion, and call the magical Ctrl-Shift-O after :-).
>
> For the record, that quickfix already exists in M2E ("Find artifact
> exporting package" or something along these lines) but I've yet to see
> it work ;).

Yes, that's still being worked on - you can use the "Maven->Add dependency" menu item to search for dependencies by group/artifact, etc. Just remember to use Ctrl-Space in the various fields to get context completion rather than hit return, which will just close the dialog. I don't believe it suggests dependencies based on missing packages, but that is something that could be added in the future via the Maven index. In fact there was a recent update to the index to add OSGi metadata like Bundle-SymbolicName, etc. which would also be useful when locating OSGi dependencies to add to your pom.xml.

[Stuart McCulloch]

On 18 Oct 2011, at 09:56, Alexander Broekhuis wrote:

Hi Stuart,

Thanks for the extensive replies, see some questions inline:

The changes to m2eclipse are already available in version 0.6.0.201110151902 of the m2e-tycho configurator from the m2e catalog.

You can see if this version is installed by looking at the About Eclipse->Installation Details->Installed Software page.

If it's not installed go to Preferences->Maven->Discovery->Open Catalog, find the Tycho entry, select the checkbox and press Finish.

Then make sure the rest of m2e is up-to-date by using Help->Check For Updates.

I've installed the latest version according to my 3.7.0 Eclipse.

Tycho Configurator: 0.6.0... (as mentioned above)

m2e: 1.0.100

maven-bundle-plugin: 2.4.0-SNAPSHOT

Yes, that's what I've got in my local demo/test installation

In a new workspace I've created a maven project (without BndTools for now), and added one simple example.

Note: the m2e-tycho configurator is also installed when you import an existing Maven project that uses the maven-bundle-plugin. During the import wizard there should be a page called "Setup Maven plugin connectors" with a list of Maven plugins with red/green markers. If you click the "Auto Select" button it should schedule installation of the m2e-tycho configurator.

I have no existing projects to test this with, creating a new project and adding the maven-bundle-plugin should work equally? I think I still have to add the tycho plugin, but can't find out how to do this. Is this needed, if so how? Some examples on the web show a plugin entry, but using those resulted in errors. I must be overlooking something simple somewhere.. 

The simplest approach is to create a Maven project, either by hand or using the "quickstart" archetype. Then change the packaging to be "bundle" and make sure you have the maven-bundle-plugin in the pom.xml (or a parent pom) with <extensions>true</extensions> so it picks up the bundle lifecycle. The default bundleplugin settings will create a valid OSGi bundle, but you can customise them as necessary. For example, if you want to put your bnd instructions in a file called "bnd.bnd" your pom.xml might look like:

<!-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -->

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">

  <modelVersion>4.0.0</modelVersion>

  <groupId>examples</groupId>

  <artifactId>test</artifactId>

  <version>1.0-SNAPSHOT</version>

  <packaging>bundle</packaging>

  <properties>

    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>

  </properties>

  <build>

    <plugins>

      <plugin>

        <groupId>org.apache.felix</groupId>

        <artifactId>maven-bundle-plugin</artifactId>

        <version>2.4.0-SNAPSHOT</version>

        <extensions>true</extensions>

        <configuration>

          <unpackBundle>true</unpackBundle>   <!-- this will unpack any bnd generated files -->

          <instructions>

            <_include>bnd.bnd</_include>    <!-- or put the bnd instructions directly in the pom -->

          </instructions>

        </configuration>

      </plugin>

    </plugins>

  </build>

</project>

<!-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -->

The use the "Maven->Update Project Configuration..." to refresh the Eclipse project metadata. The .project file should contain the following builders and natures:

        <buildSpec>

                <buildCommand>

                        <name>org.eclipse.jdt.core.javabuilder</name>

                        <arguments>

                        </arguments>

                </buildCommand>

                <buildCommand>

                        <name>org.eclipse.m2e.core.maven2Builder</name>

                        <arguments>

                        </arguments>

                </buildCommand>

        </buildSpec>

        <natures>

                <nature>org.eclipse.pde.PluginNature</nature>

                <nature>org.eclipse.jdt.core.javanature</nature>

                <nature>org.eclipse.m2e.core.maven2Nature</nature>

        </natures>

and the .classpath file should contain the following containers:

        <classpathentry kind="src" output="target/classes" path="src/main/java"/>

        <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/>

        <classpathentry kind="con" path="org.eclipse.m2e.MAVEN2_CLASSPATH_CONTAINER"/>

        <classpathentry kind="output" path="target/classes"/>

You should have both "Maven" and "PDE Tools" elements in your project menu - also make sure that you've selected "Project->Build Automatically" to get incremental builds.

The recent improvement in m2e (thanks to Igor Fedorenko) was automatic regeneration of the manifest when the bnd instructions in the Maven pom change, or when a bnd file included from the Maven pom changes. This, coupled with Igor's previous work integrating the Maven and Eclipse/PDE backends, means you can develop OSGi bundles incrementally in Eclipse while still being able to drop to the command-line and get the same results from Maven.

Is this in the version of Tycho/M2e which I am using? Or should I install some development build? If so, where can I find these? I tried to use the milestone update site as explained on [1], but that resulted in an error (no update site at that location?).

No, it's all been released from the m2e side - the only snapshot you need is the latest maven-bundle-plugin 2.4.0-SNAPSHOT (use "mvn -U install" to update this)

If this is already in the current version, is there something I need to enable? I am not seeing the automatic updates, while building through maven works.

Check the Eclipse project files as mentioned above, and use "Maven->Update Project Configuration..." to refresh them if elements are missing.

Note also that the jar file won't update for incremental builds - only the manifest, which you can view from Eclipse by using "PDE Tools->Open Manifest"

To get the best results you should also use the latest 2.4.0-SNAPSHOT of the maven-bundle-plugin (http://www.mail-archive.com/us...@felix.apache.org/msg11255.html) and add <unpackBundle>true</unpackBundle> to the configuration section of the maven-bundle-plugin (ie. outside of the instructions). This setting will make sure that any bnd generated resources, such as declarative services xml, will be unpacked and made available to PDE whenever the manifest or bundle is regenerated.

 How can I test and verify this behavior?

I'll try to put together a simple example for distribution, but basically just create a new Java class with "@aQute.bnd.annotation.component.Component" on the type and put "Service-Component: *" in your bnd instructions. That should be enough to trigger bnd to generate DS XML, which will then be unpacked automatically - as long as you have the <unpackBundle>true</unpackBundle> setting in your bundleplugin configuration as shown above.

[Alexander Broekhuis]

2011/10/18 Stuart McCulloch <mcc...@gmail.com>

The simplest approach is to create a Maven project, either by hand or using the "quickstart" archetype. Then change the packaging to be "bundle" and make sure you have the maven-bundle-plugin in the pom.xml (or a parent pom) with <extensions>true</extensions> so it picks up the bundle lifecycle. The default bundleplugin settings will create a valid OSGi bundle, but you can customise them as necessary. For example, if you want to put your bnd instructions in a file called "bnd.bnd" your pom.xml might look like:

Thanks for the example, besides some minor changes this is basically the same as what I created.

Note also that the jar file won't update for incremental builds - only the manifest, which you can view from Eclipse by using "PDE Tools->Open Manifest"

This is what I was looking for! :). So if I understand it correctly, m2e will only take care of updating the manifest file, in combination with BndTools, does BndTools recreate the actual bundle?

 

I'll try to put together a simple example for distribution, but basically just create a new Java class with "@aQute.bnd.annotation.component.Component" on the type and put "Service-Component: *" in your bnd instructions. That should be enough to trigger bnd to generate DS XML, which will then be unpacked automatically - as long as you have the <unpackBundle>true</unpackBundle> setting in your bundleplugin configuration as shown above.

I've created a small example with a simple bnd file, using the PDE Tools the Manifest can be checked, and it is updated automatically.

Now on to added BndTools. Is it best to wait for the new release? Or can I build it myself/download a developer build somewhere?

[Stuart McCulloch]

On 19 Oct 2011, at 07:39, Alexander Broekhuis wrote:

2011/10/18 Stuart McCulloch <mcc...@gmail.com>

The simplest approach is to create a Maven project, either by hand or using the "quickstart" archetype. Then change the packaging to be "bundle" and make sure you have the maven-bundle-plugin in the pom.xml (or a parent pom) with <extensions>true</extensions> so it picks up the bundle lifecycle. The default bundleplugin settings will create a valid OSGi bundle, but you can customise them as necessary. For example, if you want to put your bnd instructions in a file called "bnd.bnd" your pom.xml might look like:

Thanks for the example, besides some minor changes this is basically the same as what I created.

Note also that the jar file won't update for incremental builds - only the manifest, which you can view from Eclipse by using "PDE Tools->Open Manifest"

This is what I was looking for! :). So if I understand it correctly, m2e will only take care of updating the manifest file, in combination with BndTools, does BndTools recreate the actual bundle?

Actually you shouldn't need to package the full bundle when working in Eclipse, because the built-in launcher can work with unpacked bundles (other OSGi runtimes should also be able to handle directory-based bundles). So m2e will keep the manifest up to date as you work, and you can choose launch/test your code using either the "OSGi framework" or "Eclipse application" run configurations (assuming you don't have bndtools installed). If you do need the actual bundle jar, you can use the "Run As...->Maven install" menu item to package and install it.

We're still working on bndtools integration wrt. launching; this might require us to package the bundle first (but not on every incremental build, just when launching).

 

I'll try to put together a simple example for distribution, but basically just create a new Java class with "@aQute.bnd.annotation.component.Component" on the type and put "Service-Component: *" in your bnd instructions. That should be enough to trigger bnd to generate DS XML, which will then be unpacked automatically - as long as you have the <unpackBundle>true</unpackBundle> setting in your bundleplugin configuration as shown above.

I've created a small example with a simple bnd file, using the PDE Tools the Manifest can be checked, and it is updated automatically.

Now on to added BndTools. Is it best to wait for the new release? Or can I build it myself/download a developer build somewhere?

You can build bndtools locally - http://bndtools.org/doc/development/ - just be aware that things are moving quite fast at the moment, so expect the occasional disruption.

At some point we'll have a stable preview build available from a separate update site. 

[Alexander Broekhuis]

Hi,

Actually you shouldn't need to package the full bundle when working in Eclipse, because the built-in launcher can work with unpacked bundles (other OSGi runtimes should also be able to handle directory-based bundles). So m2e will keep the manifest up to date as you work, and you can choose launch/test your code using either the "OSGi framework" or "Eclipse application" run configurations (assuming you don't have bndtools installed). If you do need the actual bundle jar, you can use the "Run As...->Maven install" menu item to package and install it.

We're still working on bndtools integration wrt. launching; this might require us to package the bundle first (but not on every incremental build, just when launching).

My goal is to use BndTools as well, but this also works. Thanks for the hints.

You can build bndtools locally - http://bndtools.org/doc/development/ - just be aware that things are moving quite fast at the moment, so expect the occasional disruption.

At some point we'll have a stable preview build available from a separate update site. 

I'll try to compile it myself, but won't put to much effort in it. Hopefully it won't take to long for a new release! ;).

Keep up the good work!