You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicemix.apache.org by bquenin <bq...@axway.com> on 2008/11/20 23:31:27 UTC
"Features" in smx4
Hi,
I have a question regarding the "feature" functionality. As I understand
it, it's a way to express a set of bundles working together providing a
"feature". Great, I've no question regarding this. But my concern is that
you may typically want to use OSGi dependency mechanisms for that.
For instance, you have this set of bundles that works together to provide
the NMR feature let's say. Why didn't you build something such as an NMR
"meta-bundle", basically empty, but declaring "Require-Bundle" header
entries that reference all the bundles you need to provision this feature ?
Maybe I'm not clear but let's say this "manifest only" bundle is only a
set of pointers to other bundle and this has basically the same purpose as
the "feature" stuff you have in smx4. It's even more flexible potentially
since you only express the dependency set without expressing a physical
location of the required bundle but ok, it's not the point.
Could you please give me some details and if my approach is wrong and why ?
Thanks =)
BQ.
--
View this message in context: http://www.nabble.com/%22Features%22-in-smx4-tp20611424p20611424.html
Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
Re: "Features" in smx4
Posted by bquenin <bq...@axway.com>.
Ok my point is I was thinking of "enhancing" (not to say hacking) somehow the
resolution mecanism of an OSGi framework to be able to, for instance, first
only install this meta package, which will obviously not resolve any
dependency since none are installed locally, and then instead of raising
errors, have something like a "remote resolver" trying to resolve the
dependency by browsing some repositories (http, maven, OBR, etc.) and
downloading the required bundle.
I agree that "feature" thing is a clean way of managing provisionning, let's
say it's another approach, but you're right the Deployment Admin spec may be
an even more clean approach =)
Thanks
Chris Custine (Apache) wrote:
>
> Specifically addressing your suggestion, "Require-Bundle" only deals with
> resolving the named bundle and has nothing to do with provisioning. So
> the
> target bundle in a Require-Bundle clause must already be installed and
> resolved in the OSGi container. The closest thing to a standardization of
> an "Uber" bundle is in the Deployment Admin spec in OSGi R4.1 but there
> are
> some limitations that make it unsuitable for the "features" functionality,
> at least in its current form.
>
> I hope that over time there will be a new spec or revision to Deployment
> Admin that will fulfill the same functionality as "features" in
> ServiceMix,
> but for now it is really a nice thin layer that works fairly well,
> particularly when used with a maven repository.
>
> Thanks,
> Chris
>
> --
> Chris Custine
> My Blog :: http://blog.organicelement.com
> Apache ServiceMix :: http://servicemix.apache.org
> Apache Directory Server :: http://directory.apache.org
>
>
> On Thu, Nov 20, 2008 at 3:31 PM, bquenin <bq...@axway.com> wrote:
>
>>
>> Hi,
>>
>> I have a question regarding the "feature" functionality. As I understand
>> it, it's a way to express a set of bundles working together providing a
>> "feature". Great, I've no question regarding this. But my concern is that
>> you may typically want to use OSGi dependency mechanisms for that.
>> For instance, you have this set of bundles that works together to
>> provide
>> the NMR feature let's say. Why didn't you build something such as an NMR
>> "meta-bundle", basically empty, but declaring "Require-Bundle" header
>> entries that reference all the bundles you need to provision this feature
>> ?
>> Maybe I'm not clear but let's say this "manifest only" bundle is only a
>> set of pointers to other bundle and this has basically the same purpose
>> as
>> the "feature" stuff you have in smx4. It's even more flexible potentially
>> since you only express the dependency set without expressing a physical
>> location of the required bundle but ok, it's not the point.
>>
>> Could you please give me some details and if my approach is wrong and why
>> ?
>>
>> Thanks =)
>> BQ.
>> --
>> View this message in context:
>> http://www.nabble.com/%22Features%22-in-smx4-tp20611424p20611424.html
>> Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
>>
>>
>
>
--
View this message in context: http://www.nabble.com/%22Features%22-in-smx4-tp20611424p20612178.html
Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
Re: "Features" in smx4
Posted by Chris Custine <cc...@apache.org>.
Specifically addressing your suggestion, "Require-Bundle" only deals with
resolving the named bundle and has nothing to do with provisioning. So the
target bundle in a Require-Bundle clause must already be installed and
resolved in the OSGi container. The closest thing to a standardization of
an "Uber" bundle is in the Deployment Admin spec in OSGi R4.1 but there are
some limitations that make it unsuitable for the "features" functionality,
at least in its current form.
I hope that over time there will be a new spec or revision to Deployment
Admin that will fulfill the same functionality as "features" in ServiceMix,
but for now it is really a nice thin layer that works fairly well,
particularly when used with a maven repository.
Thanks,
Chris
--
Chris Custine
My Blog :: http://blog.organicelement.com
Apache ServiceMix :: http://servicemix.apache.org
Apache Directory Server :: http://directory.apache.org
On Thu, Nov 20, 2008 at 3:31 PM, bquenin <bq...@axway.com> wrote:
>
> Hi,
>
> I have a question regarding the "feature" functionality. As I understand
> it, it's a way to express a set of bundles working together providing a
> "feature". Great, I've no question regarding this. But my concern is that
> you may typically want to use OSGi dependency mechanisms for that.
> For instance, you have this set of bundles that works together to provide
> the NMR feature let's say. Why didn't you build something such as an NMR
> "meta-bundle", basically empty, but declaring "Require-Bundle" header
> entries that reference all the bundles you need to provision this feature ?
> Maybe I'm not clear but let's say this "manifest only" bundle is only a
> set of pointers to other bundle and this has basically the same purpose as
> the "feature" stuff you have in smx4. It's even more flexible potentially
> since you only express the dependency set without expressing a physical
> location of the required bundle but ok, it's not the point.
>
> Could you please give me some details and if my approach is wrong and why ?
>
> Thanks =)
> BQ.
> --
> View this message in context:
> http://www.nabble.com/%22Features%22-in-smx4-tp20611424p20611424.html
> Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
>
>