Home » Eclipse Projects » Equinox » Is Orbit an OBR?
| Is Orbit an OBR? [message #78653] |
Thu, 07 December 2006 18:15  |
Eclipse User |
|
|
|
Originally posted by: kgilmer.gmail.com
Hello -
My company is considering various approaches to distributing bundles
publicly. I'm looking at Orbit, the Felix OBR, as well as the
OSGi.org's OBR as patterns to follow. I ran across some discussions in
the past regarding OBR and Equinox, regarding having Eclipse utilize an
OBR. It seems there is some ambiguity between Update and OBR. The wiki
pages for Orbit don't seem to confirm or deny that there is an OBR
interface to the bundles. Is this a TBD, and if not what's the stance
regarding Equinox and OBRs? Does the PDE team intend to implement a
Felix-like OBR bundle?
TIA
Ken Gilmer
Bug Labs, Inc.
|
|
|
| Re: Is Orbit an OBR? [message #78714 is a reply to message #78653] |
Fri, 08 December 2006 18:33  |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer.REMOVE.ca.ibm.com
Hey Ken,
Orbit is just a project producing bundles. These bundles may be
distributed using a variety of provisioning technologies. Currently the
plan is to make them available individually as JAR files on a downloads
page and all together in one (small number) zip file. This of course
will evolve over time.
As for OBR, there are really two aspects to this: the availability of
the OBR metadata and where/how that metadata is linked in/made
available. OSGi hosts an OBR repository and the main Eclipse Update
site for Callisto (for example) is linked in there. In the future it
seems quite reasonable for the Orbit, Equinox and other bundles to show
up there as well.
Note as well that at some point there may well be an Update site
containing these bundles. We discussed the usecases around this and
were not convinced that it made sense at this point. Most of the
usecases we are looking at supporting are dev time.
Jeff
Ken Gilmer wrote:
> Hello -
>
> My company is considering various approaches to distributing bundles
> publicly. I'm looking at Orbit, the Felix OBR, as well as the
> OSGi.org's OBR as patterns to follow. I ran across some discussions in
> the past regarding OBR and Equinox, regarding having Eclipse utilize an
> OBR. It seems there is some ambiguity between Update and OBR. The wiki
> pages for Orbit don't seem to confirm or deny that there is an OBR
> interface to the bundles. Is this a TBD, and if not what's the stance
> regarding Equinox and OBRs? Does the PDE team intend to implement a
> Felix-like OBR bundle?
>
> TIA
> Ken Gilmer
>
> Bug Labs, Inc.
|
|
|
| Re: Is Orbit an OBR? [message #78727 is a reply to message #78714] |
Fri, 08 December 2006 19:24 |
| Eclipse User |
|
|
|
Originally posted by: kgilmer.gmail.com
Hi Jeff,
Thanks for your response. It's my understanding that Update Manager
requires Eclipse plugin metadata (features, etc.) in order to work and
is therefor unsuitable for "pure" OSGi environments. If this is the
case, there doesn't seem to be an "Eclipse" way of handling provisioning
(with features like Update Manager or OBR support, such as automatic
dependency resolution). I've been playing around with the Felix OBR
bundle, trying to get it to work in Equinox. One initial problem is
that the Felix "TUI" shell is not compatible with the Equinox console.
There may be other issues as well. In general, if there was an
Equinox-compatible OBR bundle, would that be something the community
might find valuable? Are there other more promising directions for this
type of functionality in regards to Equinox?
Thanks again,
ken
Jeff McAffer wrote:
> Hey Ken,
>
> Orbit is just a project producing bundles. These bundles may be
> distributed using a variety of provisioning technologies. Currently the
> plan is to make them available individually as JAR files on a downloads
> page and all together in one (small number) zip file. This of course
> will evolve over time.
>
> As for OBR, there are really two aspects to this: the availability of
> the OBR metadata and where/how that metadata is linked in/made
> available. OSGi hosts an OBR repository and the main Eclipse Update
> site for Callisto (for example) is linked in there. In the future it
> seems quite reasonable for the Orbit, Equinox and other bundles to show
> up there as well.
>
> Note as well that at some point there may well be an Update site
> containing these bundles. We discussed the usecases around this and
> were not convinced that it made sense at this point. Most of the
> usecases we are looking at supporting are dev time.
>
> Jeff
>
>
> Ken Gilmer wrote:
>> Hello -
>>
>> My company is considering various approaches to distributing bundles
>> publicly. I'm looking at Orbit, the Felix OBR, as well as the
>> OSGi.org's OBR as patterns to follow. I ran across some discussions
>> in the past regarding OBR and Equinox, regarding having Eclipse
>> utilize an OBR. It seems there is some ambiguity between Update and
>> OBR. The wiki pages for Orbit don't seem to confirm or deny that
>> there is an OBR interface to the bundles. Is this a TBD, and if not
>> what's the stance regarding Equinox and OBRs? Does the PDE team intend
>> to implement a Felix-like OBR bundle?
>>
>> TIA
>> Ken Gilmer
>>
>> Bug Labs, Inc.
|
|
|
| Re: Is Orbit an OBR? [message #78742 is a reply to message #78727] |
Sat, 09 December 2006 04:17 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer.REMOVE.ca.ibm.com
Ken Gilmer wrote:
> Thanks for your response. It's my understanding that Update Manager
> requires Eclipse plugin metadata (features, etc.) in order to work and
> is therefor unsuitable for "pure" OSGi environments. If this is the
Pure OSGi does not spec anything wrt deployment so anything, Update
Manager, OBR, whatever is not going to be "pure". OBR has its own
metadata format.
> case, there doesn't seem to be an "Eclipse" way of handling provisioning
> (with features like Update Manager or OBR support, such as automatic
> dependency resolution). I've been playing around with the Felix OBR
> bundle, trying to get it to work in Equinox. One initial problem is
> that the Felix "TUI" shell is not compatible with the Equinox console.
> There may be other issues as well.
When you say "not compatible with" what does that mean? You should in
theory at least be able to add the Felix console bundle to an Equinox
system and use it instead of the Equinox console. BTW, there have been
some preliminary discussions around standardizing the console
contribution mechanism so this kind of issue would go away.
> In general, if there was an
> Equinox-compatible OBR bundle, would that be something the community
> might find valuable? Are there other more promising directions for this
> type of functionality in regards to Equinox?
I'm pretty sure that there are people using OBR on equinox and finding
it useful. As for being part of the mainstream Equinox provisioning
story, to date most of the product teams we encounter are not interested
in dynamic picking of prerequisites. While it is a cool approach, most
of these people are more interested in repeatability and guaranteed
configurations.
As for directions, there is a 3.3 plan item for improvements to the
Eclipse provisioning technology but so far we've been mostly talking
about it and playing with a few ideas.
So, if you would like to investigate OBR on Equinox and help us ensure
that it works, your effort and contributions would be appreciated.
Jeff
|
|
|
| Re: Is Orbit an OBR? [message #78867 is a reply to message #78742] |
Mon, 11 December 2006 16:09 |
| Eclipse User |
|
|
|
Originally posted by: kgilmer.gmail.com
Jeff McAffer wrote:
> Ken Gilmer wrote:
>> Thanks for your response. It's my understanding that Update Manager
>> requires Eclipse plugin metadata (features, etc.) in order to work and
>> is therefor unsuitable for "pure" OSGi environments. If this is the
>
> Pure OSGi does not spec anything wrt deployment so anything, Update
> Manager, OBR, whatever is not going to be "pure". OBR has its own
> metadata format.
True. I guess the point I was trying to make here was that (AFAIK) the
OBR metadata is isomorphic to a set of bundles, whereas plugin.xml
introduces concepts outside of "pure" osgi, like features.
>
>> case, there doesn't seem to be an "Eclipse" way of handling
>> provisioning (with features like Update Manager or OBR support, such
>> as automatic dependency resolution). I've been playing around with
>> the Felix OBR
>> bundle, trying to get it to work in Equinox. One initial problem is
>> that the Felix "TUI" shell is not compatible with the Equinox console.
>> There may be other issues as well.
>
> When you say "not compatible with" what does that mean? You should in
> theory at least be able to add the Felix console bundle to an Equinox
> system and use it instead of the Equinox console. BTW, there have been
> some preliminary discussions around standardizing the console
> contribution mechanism so this kind of issue would go away.
I simply mean that the Equinox shell and the Felix TUI shell do not play
nice with each other. I could probably set them to listen on different
ports, but that seems more of a hack. Standardizing the console
(especially across OSGi implementations) contribution mechanism would be
a good solution IMHO.
>
>> In general, if there was an Equinox-compatible OBR bundle, would that
>> be something the community might find valuable? Are there other more
>> promising directions for this type of functionality in regards to
>> Equinox?
>
> I'm pretty sure that there are people using OBR on equinox and finding
> it useful. As for being part of the mainstream Equinox provisioning
> story, to date most of the product teams we encounter are not interested
> in dynamic picking of prerequisites. While it is a cool approach, most
> of these people are more interested in repeatability and guaranteed
> configurations.
If the set of OBR Repository URLs are controlled for a given runtime,
actions performed by the OBR bundle should be well known and
consistent... I assume this is the case for both Update Manager and
OBR. Is there something UM has in this regard that OBR lacks?
>
> As for directions, there is a 3.3 plan item for improvements to the
> Eclipse provisioning technology but so far we've been mostly talking
> about it and playing with a few ideas.
>
> So, if you would like to investigate OBR on Equinox and help us ensure
> that it works, your effort and contributions would be appreciated.
Great! I will post back when I have some meaningful information.
cheers
ken
|
|
|
| Re: Is Orbit an OBR? [message #78880 is a reply to message #78867] |
Mon, 11 December 2006 22:02 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer.REMOVE.ca.ibm.com
Ken Gilmer wrote:
> Jeff McAffer wrote:
>> Pure OSGi does not spec anything wrt deployment so anything, Update
>> Manager, OBR, whatever is not going to be "pure". OBR has its own
>> metadata format.
>
> True. I guess the point I was trying to make here was that (AFAIK) the
> OBR metadata is isomorphic to a set of bundles, whereas plugin.xml
> introduces concepts outside of "pure" osgi, like features.
plugin.xml is not related in anyway to provisioning. Eclipse "plugins"
are OSGi bundles and are fully spec'd using Manifest.mf. The plugin.xml
content relates to extension/extension point contributions in much the
same way as OSGi Declarative Services "component.xml" files relate to
service declarations.
>> When you say "not compatible with" what does that mean? You should in
>> theory at least be able to add the Felix console bundle to an Equinox
>> system and use it instead of the Equinox console. BTW, there have
>> been some preliminary discussions around standardizing the console
>> contribution mechanism so this kind of issue would go away.
>
> I simply mean that the Equinox shell and the Felix TUI shell do not play
> nice with each other. I could probably set them to listen on different
> ports, but that seems more of a hack. Standardizing the console
> (especially across OSGi implementations) contribution mechanism would be
> a good solution IMHO.
Absolutely.
>> I'm pretty sure that there are people using OBR on equinox and finding
>> it useful. As for being part of the mainstream Equinox provisioning
>> story, to date most of the product teams we encounter are not
>> interested in dynamic picking of prerequisites. While it is a cool
>> approach, most of these people are more interested in repeatability
>> and guaranteed configurations.
>
> If the set of OBR Repository URLs are controlled for a given runtime,
> actions performed by the OBR bundle should be well known and
> consistent... I assume this is the case for both Update Manager and
> OBR. Is there something UM has in this regard that OBR lacks?
For better or worse (depending on your point of view), UM has explicit
notions of grouping (features). Features are designed by the people
producing/shipping function sets. In contrast, OBR does not have
grouping and bundle selection is done at run time by each client. It is
true that you could design custom repository.xml OBR files for each
client/client configuration but that is quite a challenge.
I fully acknowledge that OBR addresses a number of usecases where
consumers are quite happy to take arbitrary packaging/implementation of
the function they need. By the same token however, there are people who
are just not able to accept the attendant risk.
>> So, if you would like to investigate OBR on Equinox and help us ensure
>> that it works, your effort and contributions would be appreciated.
>
> Great! I will post back when I have some meaningful information.
Looking forward to it.
Jeff
|
|
|
Goto Forum:
Current Time: Fri Apr 26 16:14:17 GMT 2024
Powered by FUDForum. Page generated in 0.03450 seconds |
] 
Search
Help
Register
Login
Home
