Comments on: OSGi Tool Summit Recap

By: Frederic

Frederic — Wed, 27 May 2009 01:41:22 +0000

>To address your layout issues, the PDE team is committed to fixing the issue in the 3.6 and 4.0 timeframe.
>We’ve been tooling bundles (plug-ins) for a long time so there’s some legacy we need to shed.
>When we receive constructive feedback from the community in terms of bugs and enhancement requests, we’re able to make progress.

That’s great news Chris! I really think there should be more collaboration between OSGi technologies in order to come up with more productivity for developers, and this Tools Summit was an excellent step.

In the mean time, for Maven users (and Spring DM users as well) you’ll find some integration tips over here:
http://forum.springsource.org/showpost.php?p=211421&postcount=3

By: Matthias Kuespert

Matthias Kuespert — Fri, 24 Apr 2009 21:38:56 +0000

Great post! Especially the “… convinced that I should rename PDE to BDE …” caught my attention: I always believed the name would make it

Mid 2007 I started a Eclipse-plugin to turn JDE into a BDE using BND – sadly it always remained a low-priority toy project. The remains are available here: http://code.google.com/p/bde/ – at least they may serve for inspiration.

Main intentions were to provide:
– a BND configuration editor
– a bundle-builder that assembles a bundle jar using BND on each source-code change
– a straightforward way to configure OSGi run/debug-configurations: one page for framework config, one for startlevel-based bundle config.
– generation of a Maven pom … but that’s obsolete now that we have m2eclipse

Unfortunately I never got to integrating the Pax toolchain – especially Runner and Exam- that sure would add more flavour …

But why ‘rename’ PDE? PDE is perfectly ok for Eclipse-plugin development – should not BDE be a layer between JDE and PDE since Eclipse is based on OSGi?

By: Simon Chemouil

Simon Chemouil — Wed, 01 Apr 2009 10:20:11 +0000

Excellent post and summary of the situation! I look forward to PDE becoming a more general OSGi bundle development environment; that would be great not only for developing non-Eclipse OSGi applications, but also for making Eclipse plugins less tied to Eclipse specifics by giving more tooling to Eclipse developers.

By: Lars

Lars — Tue, 31 Mar 2009 21:20:42 +0000

Chris, thank you, works perfectly. Very nice tool (and a good code example for Zest).

By: Chris Aniszczyk

Chris Aniszczyk — Tue, 31 Mar 2009 21:14:14 +0000

Lars, you need to focus on a particular bundle. There should be a magnifying glass or you can right click within the view and select “Focus On…”

This is how the normal plug-in dependencies view works.

Does that help?

By: Lars

Lars — Tue, 31 Mar 2009 21:12:51 +0000

I downloaded org.eclipse.pde.visualization.dependency out of cvs into a 3.5M6 and started it. The dependency graph view shows but stays empty. What do I need to select to see same data?

By: Chris Aniszczyk

Chris Aniszczyk — Tue, 31 Mar 2009 19:13:43 +0000

Thanks BJ, I clarified the classpath discussion.

I have added Maven and BND to the list. Wow, there was really a lot of representation at the summit!

By: BJ Hargrave

BJ Hargrave — Tue, 31 Mar 2009 19:10:19 +0000

Great summary of the meeting.

To be clear, OSGi does not provide a hierarchical class path. OSGi provides a directed graph class loader structure with the graph edges representing Java packages.

Don’t forget to include Maven and BND in the list of tools represented at the meeting!

By: Chris Aniszczyk

Chris Aniszczyk — Tue, 31 Mar 2009 18:54:55 +0000

I can tell you come from the Maven world Alex or have met people that live there

To address your layout issues, the PDE team is committed to fixing the issue in the 3.6 and 4.0 timeframe. We’ve been tooling bundles (plug-ins) for a long time so there’s some legacy we need to shed. When we receive constructive feedback from the community in terms of bugs and enhancement requests, we’re able to make progress.

In the end, we have our own biases on how projects should be setup. It’s my goal to have PDE flexible enough to respect people’s setup.

Thanks for your feedback.

By: Alex Blewitt

Alex Blewitt — Tue, 31 Mar 2009 18:49:26 +0000

For me, PDE’s most significant restriction is the assumption that the project’s contents are laid out in ‘expanded bundle’ format. This leads to hacks like build.properties having an ‘include’ to avoid bundling source etc or project metadata. Almost every other Java project has a set of ‘src’ and ‘resource’ folders which together are copied to the build or bin dir, which is then used as the contents of the runtime classpath.

PDE doesn’t have the concept of resources (automatically generated or otherwise) other than the top level of the project. If it were amended to allow the contents of the bundle to be the contents of the ‘bin’ or ‘build’ dir (or whatever it is defined in the .classpath) then they could be arranged as the project wanted, not as the tool wanted.

The manifest.mf is a special case of this same problem. Ideally this too should allow it to be built (eg from bnd) at rubtine but allow editing in a src folder (e.g. src/resources/META-INF/MANIFEST.MF).

Many people I know have given up on PDE (and PDE build in particular) because of these pointless restrictions. To make a general bundle environment that people will want to us, this needs to be addressed.