Twitter github

OSGi, PDE and Where’s Waldo

I was reading over the OSGi survey results and noticed that people found that obtaining valid bundles is still a problem. I agree. I find obtaining bundles or setting up my development target akin to playing a game of Where’s Waldo.

Where's Waldo

As you can tell, I was never a fan of the game, but for some reason my family loved getting those books.

Last week, the PDE team had a little meeting of the minds to help think of ideas to tackle parts of that problem. There’s a lot more we can do to improve the developer experience around managing bundles since p2 is around now.

The PDE team is looking at improving the target definition story again. One aspect of the improvement is making targets managed by a p2 profile. This would make it easier to manage the target in the long run and potentially expose cool things you can do with targets. The aspect I’m mostly interested in is improving the developer experience and workflow with PDE.

I remember when I first started developing bundles, one big problem was just setting up your environment and finding the correct bundles. I remember staring at my Java source files and seeing evil compile errors for missing imports like this commons collections one.

Missing Imports

Wouldn’t it be nice to take advantage of p2 repositories to help solve that problem?

pde2

p2 repositories are rich with metadata and you can query them for many interesting things like packages.

Add Artifact

You can also query for things like bundles.

pde4

Heck, if you’re adventurous, you can also query for features!

pdefeatures

Since the target platform is managed by p2, the necessary artifacts will be downloaded and available for you to use.

pde5

No more compile errors!

pde6

We can see that the commons collections bundle is now part of our dependencies.

pde7

That’s just one example of how to improve the bundle developer workflow using p2. The PDE team is exploring many options so if you have ideas on how to improve developer workflow, please let the PDE team know.

  • http://intellectualcramps.blogspot.com/ David Carver

    One thing I hope you guys keep in mind, especially with IntelliJ having open source versions, and OSGI support, is that not everybody is using P2. I would hope that you can come up with something working across the various tooling vendors supporting OSGI to come up with a common way of doing it. This way people aren’t locked into one particular IDE’s way of working.

  • http://intellectualcramps.blogspot.com David Carver

    One thing I hope you guys keep in mind, especially with IntelliJ having open source versions, and OSGI support, is that not everybody is using P2. I would hope that you can come up with something working across the various tooling vendors supporting OSGI to come up with a common way of doing it. This way people aren’t locked into one particular IDE’s way of working.

  • http://www.ibm.com/software Matthew Perrins

    Having just spent the last 3 hrs solving a problem related to bundles and target platforms, I am all for this tooling, its needed as more target platforms will appear for very diverse OSGi runtimes, from Enterprise Software to Client Software.

  • http://www.ibm.com/software Matthew Perrins

    Having just spent the last 3 hrs solving a problem related to bundles and target platforms, I am all for this tooling, its needed as more target platforms will appear for very diverse OSGi runtimes, from Enterprise Software to Client Software.

  • http://aniszczyk.org/ Chris Aniszczyk

    David, this is the reason I am PUSHING for p2.

    p2 is open for people to contribute their own repository implementations. For example, this is how p2 is able to read the old update site format that Eclipse Update Manager used (check the org.eclipse.equinox.p2.updatesite bundle). I know the p2 team is investigating working with OBR which is another OSGi repository format. To work with Maven, someone would have to write a p2 repository implementation that would generate the proper p2 metadata when reading a repository. Then like magic, PDE would work with other repositories.

  • http://aniszczyk.org Chris Aniszczyk

    David, this is the reason I am PUSHING for p2.

    p2 is open for people to contribute their own repository implementations. For example, this is how p2 is able to read the old update site format that Eclipse Update Manager used (check the org.eclipse.equinox.p2.updatesite bundle). I know the p2 team is investigating working with OBR which is another OSGi repository format. To work with Maven, someone would have to write a p2 repository implementation that would generate the proper p2 metadata when reading a repository. Then like magic, PDE would work with other repositories.

  • http://instilsoft.com/ Tara

    We have over 150+ production bundles, and 500 projects in total in our workspace. On top of this we have a number of 3rd party bundles in our target platform.

    Overall we find PDE works a treat, but a couple of small things would certainly help.

    For us, as we add new bundles and fragments on an almost weekly basis, having to manually edit one’s manifest files becomes a bit of a drag. It would be great if you could extend quick-fix to offer an import package fix when a type is not found. That is, update the manifest and the types import statements. (Assuming that it is exported by another project in your workspace or bundle in your target platform.)

    Taking it further, if the type is known to exist somewhere in a project in your workspace (not in a target platform bundle), but it’s package is not exported from any project, then offer to export the package from the relevant project, as well as import it.

    This one is slightly more dubious. Lesser developers may start exporting packages that were never meant to be exported – the mental process of partitioning your bundles is extremely important and the ‘labour’ involved in manually editing 2 manifests (import & export) may actually be worth it. They may stop and think more. But still, it would be a welcome feature.

    I know you’re not a Maven fan-boy, but shipping with a Maven p2 binding would make a lot of people happy :) (Unless you know of someone who is already developing one?)

  • http://instilsoft.com Tara

    We have over 150+ production bundles, and 500 projects in total in our workspace. On top of this we have a number of 3rd party bundles in our target platform.

    Overall we find PDE works a treat, but a couple of small things would certainly help.

    For us, as we add new bundles and fragments on an almost weekly basis, having to manually edit one’s manifest files becomes a bit of a drag. It would be great if you could extend quick-fix to offer an import package fix when a type is not found. That is, update the manifest and the types import statements. (Assuming that it is exported by another project in your workspace or bundle in your target platform.)

    Taking it further, if the type is known to exist somewhere in a project in your workspace (not in a target platform bundle), but it’s package is not exported from any project, then offer to export the package from the relevant project, as well as import it.

    This one is slightly more dubious. Lesser developers may start exporting packages that were never meant to be exported – the mental process of partitioning your bundles is extremely important and the ‘labour’ involved in manually editing 2 manifests (import & export) may actually be worth it. They may stop and think more. But still, it would be a welcome feature.

    I know you’re not a Maven fan-boy, but shipping with a Maven p2 binding would make a lot of people happy :) (Unless you know of someone who is already developing one?)

  • http://aniszczyk.org/ Chris Aniszczyk

    @Tara, let me reply to some of your points.

    “For us, as we add new bundles and fragments on an almost weekly basis, having to manually edit one’s manifest files becomes a bit of a drag. It would be great if you could extend quick-fix to offer an import package fix when a type is not found…”

    This is possible now in PDE if things are setup correctly. In essence, if it’s on the “global classpath” PDE will find it and offer you a quickfix. To get your target on the global classpath, you can go to the plug-ins view and find the button that will add all the bundles to “Java search.” In Eclipse 3.6, there’s a new preference that will add all bundles in your target to the “global classpath” so you will always see these quickfix options. If you need help setting this up, let me know.

    “Taking it further, if the type is known to exist somewhere in a project in your workspace (not in a target platform bundle), but it’s package is not exported from any project, then offer to export the package from the relevant project, as well as import it.”

    If you set things up as mentioned above, you will see a quickfix for this.

    So with the new work the PDE team is doing to integrate with p2 repositories, you’ll have the ability to search for bundles, features and packages within your target and across p2 repositories. Hopefully people like you can comment and offer feedback so we get the workflow right.

    “I know you’re not a Maven fan-boy…”

    I don’t have a problem with Maven, I think it served a purpose in the pre-OSGi world. Now that OSGi is popular, I don’t think Maven is enough. The Maven team has realized this and started to work on Maven3 which is to solve some of the problems that occur when using OSGi.

    “…but shipping with a Maven p2 binding would make a lot of people happy”

    I’m all for this but the PDE team isn’t going to write one. I hope that someone from the community could contribute this to the p2 project. I don’t know if the Maven community has an interest in contributing the work as it seems to be an all-or-nothing approach with Maven. If I knew how to call Maven APIs to read POMs and all that good stuff, it would probably take a couple days to write a basic repository implementation usable by p2. I believe the Buckminster project at Eclipse is doing some exploration in how to interact with Maven repositories so you could try pinging them.

  • http://aniszczyk.org Chris Aniszczyk

    @Tara, let me reply to some of your points.

    “For us, as we add new bundles and fragments on an almost weekly basis, having to manually edit one’s manifest files becomes a bit of a drag. It would be great if you could extend quick-fix to offer an import package fix when a type is not found…”

    This is possible now in PDE if things are setup correctly. In essence, if it’s on the “global classpath” PDE will find it and offer you a quickfix. To get your target on the global classpath, you can go to the plug-ins view and find the button that will add all the bundles to “Java search.” In Eclipse 3.6, there’s a new preference that will add all bundles in your target to the “global classpath” so you will always see these quickfix options. If you need help setting this up, let me know.

    “Taking it further, if the type is known to exist somewhere in a project in your workspace (not in a target platform bundle), but it’s package is not exported from any project, then offer to export the package from the relevant project, as well as import it.”

    If you set things up as mentioned above, you will see a quickfix for this.

    So with the new work the PDE team is doing to integrate with p2 repositories, you’ll have the ability to search for bundles, features and packages within your target and across p2 repositories. Hopefully people like you can comment and offer feedback so we get the workflow right.

    “I know you’re not a Maven fan-boy…”

    I don’t have a problem with Maven, I think it served a purpose in the pre-OSGi world. Now that OSGi is popular, I don’t think Maven is enough. The Maven team has realized this and started to work on Maven3 which is to solve some of the problems that occur when using OSGi.

    “…but shipping with a Maven p2 binding would make a lot of people happy”

    I’m all for this but the PDE team isn’t going to write one. I hope that someone from the community could contribute this to the p2 project. I don’t know if the Maven community has an interest in contributing the work as it seems to be an all-or-nothing approach with Maven. If I knew how to call Maven APIs to read POMs and all that good stuff, it would probably take a couple days to write a basic repository implementation usable by p2. I believe the Buckminster project at Eclipse is doing some exploration in how to interact with Maven repositories so you could try pinging them.

  • http://instilsoft.com/ Tara

    Thanks Chris – missed that button on the plugin view.

    Also, I have only just and rather belatedly discovered Tycho – it purports to be p2 compliant and a friendly replacement for the PDE headless build (which we also use). More info can be found here http://www.chariotsolutions.com/slides/pdfs/ete2009-MavenAndTheFutureofOSGi.pdf and here http://www.sonatype.com/people/2009/03/the-future-of-maven-osgi-join-the-tycho-users-mailing-list/.

    Keep up the good work

  • http://instilsoft.com Tara

    Thanks Chris – missed that button on the plugin view.

    Also, I have only just and rather belatedly discovered Tycho – it purports to be p2 compliant and a friendly replacement for the PDE headless build (which we also use). More info can be found here http://www.chariotsolutions.com/slides/pdfs/ete2009-MavenAndTheFutureofOSGi.pdf and here http://www.sonatype.com/people/2009/03/the-future-of-maven-osgi-join-the-tycho-users-mailing-list/.

    Keep up the good work

  • http://www.amandashoeswholesale.com/closeout/ Closeout Shoes

    This is a very good idea! Just want to say thank you for the information, you have to share. Just continue to write such a position. I will be your faithful reader. Thank you again.