During EclipseCon last week there was a BOF about tools for OSGi, and the day after an OSGi Tool Summit (Chris Aniszczyk posted a good summary).
Two significant challenges for the EEG emerged from these excellent discussions: complete the OBR design and define the term "application" as it relates to a collection of OSGi bundles and the resources they depend on. The OBR design work was partially completed in 2006, before the EEG started, and we had initially hoped to pick up the work from where it was left off.
At the main OSGi BOF it quickly became apparent that the Eclipse/OSGi community had diverged somewhat in this area, with Eclipse P2 taking a different approach. Among the attendees, Jason van Zyl probably put it best when he said (basically) "I don't care which one I have to follow, I just want a single standard" to support build, provisioning, and deployment lifecycle activities for OSGi. (Jason's company, Sonatype, is developing Maven based tooling for OSGi application development that promises to address a lot of these challenges.)
The challenge for Tim and me will be getting the OBR and P2 folks together and hashing out something agreeable to all. Unfortunately for Hal, he was the one to volunteer to drive this effort ;-) (The EEG work depends on volunteers to drive requirements and design docs.)
To be fair, none of us in the EEG really knew much about what was going on with P2, so it's important to take a step back and essentially reset the discussion. Unfortunately, during the January EEG F2F we identified progressing OBR as the highest priority work item...and with the strident calls for address the tooling challenges, we are going to continue to strongly focus on it.
A related topic for the EEG is the definition of an application as it relates to a deployment on an OSGi framework. A simple answer to this question is that an application is the same as a bundle, or anyway a bundle that references or includes all the other bundles it needs. But for enterprise applications, a strong requirement has been given to ensure consistency across the develop-test-deploy into production cycle.
The dynamic nature of the OSGi framework, usually one of its most attractive benefits, can be a liability in this area. So it seems there needs to be some way to formalize some metadata for what it means for a collection of bundles and associated resources to be used for a specific application. We have just started on the requirements document for this, but this is strongly related to the bundle repository/provisioning standard - the application definition is something that could be stored in and retrieved from the repository, and used to filter the collection of bundles and resources that need to be resolved and provisioned...
Should be fun!
6 years ago
Posts
Perhaps the EEG will look at the application artefacts defined by SpringSource dm Server. A "PAR" file is a JAR containing OSGi bundles which are "scoped" together to form an application. We recently added support to the 2.0 stream for "plans" which are files referring to OSGi bundles. A "scoped" "atomic" plan has similar semantics to a PAR file but collects its bundles together by reference rather than as a JAR file.
ReplyDeleteHi Glyn,
ReplyDeleteI'm sure that will come up. At least I should say that SpringSource folks have participated in the discussions so far, so hopefully the right connections are in place for that to occur.
It does sound that a scoped plan is very similar to the requirement for an "application" definition, something that can support development lifecycle activities on a collection of bundles.
In any case I'll make sure to ask about it if no one brings it up.
Thanks,
Eric