You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Alin Dreghiciu <ad...@gmail.com> on 2008/05/04 01:14:12 UTC
Re: SpringSource Bundle Repository Bundles will only contain standard OSGi manifest headers
I will cross post this message also to Felix dev list:
It is very god that the bundles from SBP does not contain this headers
as containing them would made them unusable on standard framework
implementations and it would be petty that all of this huge effort of
osgi-fying common libraries would work only with S2AP. Basically I'm
quite grateful for this effort and I think many are. I was looking and
asking for such a thing about one year ago and would be great if we
could combine this with the ones from Felix Commons and Eclipse Orbit
(any ideas). I guess that if would have asked there would be people
willing to donate / contribute to it. BTW, how can we contribute to
this effort? For example ion Felix you create jira issues and attach a
maven pom to it.
My worries are related to bundles people would build and as
Import-Bundle/Import-Library look easy to use people will ignore the
inherent "danger" of using this manifest headers, use them in the
bundles they build and then run into troubles as they may try to
deploy them into a standard osgi framework implementation. I would not
repeat here the problems this headers bring as I think are quite good
covered in Neil's blog and comments
(http://neilbartlett.name/blog/2008/05/01/springsource-app-platform-is-a-curates-egg/)
More, as I would guess people that use them will be Spring users so I
would guess that the "problems" will be less if they were supported as
part of Spring DM, but as I can see there is not the case as I cannot
see any reference to them in Spring DM source code so I suppose they
are part of DMK.
I'm also wondering why you did not bring them through the OSGi
Alliance process (RPF/RFC) if you consider them as an important
feature? Time constraints as in they should be available now not by
the timeframe of R5?
Another feature witch "bothers" me is the PAR. In some aspects this is
similar to the new packaging introduced by Deployment Admin (indeed
this is more complex) and I'm wondering why you did not go that way or
if it was not enough agin why you did not bring the necessary changes
/ new features via OSGi Alliance.
I know that Spring vision is that is better to have a battle field
proven standard then a committee one but OSGi Alliance CPEG / EEG is
not JCP and from what I follow on the OSGi Alliance standardization
process the discussions only lead to better solutions as more people
with different experiences and use cases in the field participate.
Alin Dreghiciu
http://www.ops4j.org - New Energy for OSS Communities - Open
Participation Software.
http://www.qi4j.org - New Energy for Java - Domain Driven
Development.
http://malaysia.jayway.net - Great People working on Great Projects at
Great Places
On Sat, May 3, 2008 at 7:47 PM, Adrian Colyer
<ad...@springsource.com> wrote:
> I wanted to clarify a question that came up on the felix-dev list (to which
> I'm not subscribed so I can't post):
>
> All of the bundles in the SpringSource Bundle Repository will contain only
> standard OSGi manifest headers: they are intended for use with Spring
> Dynamic Modules on any OSGi Service Platform, not just for use with the
> SpringSource Application Platform.
>
> The library definition files in the repository *are* particular to the
> SpringSource AP, and simply contain a list of bundle import statements
> (symbolic name and version range) that define a group of bundles commonly
> used together to achieve some end.
>
> Regards, Adrian.
>
>
> Adrian Colyer
> CTO
> SpringSource Limited
> http://www.springsource.com
>
> Registered in England and Wales: No. 5187766 Registered Office: A2
> Yeoman Gate, Yeoman Way, Worthing, West Sussex. BN13 3QZ.
>
>
> E-mails should be checked by the recipient to ensure that there are no
> viruses and SpringSource does not accept any responsibility if this is
> not done. Any views or opinions presented are solely those of the
> author and do not necessarily represent those of SpringSource.
>
>
>
>
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google Groups
> "Spring and OSGi" group.
> To post to this group, send email to spring-osgi@googlegroups.com
> To unsubscribe from this group, send email to
> spring-osgi-unsubscribe@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/spring-osgi?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
>
Re: SpringSource Bundle Repository Bundles will only contain standard OSGi manifest headers
Posted by Adrian Colyer <ad...@springsource.com>.
Hi Alin,
> It is very god that the bundles from SBP does not contain this headers
We try our best, but I don't think we've quite hit *that* level yet ;)
> BTW, how can we contribute to
> this effort? For example ion Felix you create jira issues and attach a
> maven pom to it.
We have a JIRA instance (linked from the repository FAQ) that can be
used for reporting problems with existing bundles, and for requesting
additional bundles to be added. Attachments of bundles with existing
manifests is always especially welcome. We will check the manifest to
ensure it meets the repository standards (imports and exports
versioned where applicable, matching ivy and pom files, Bundle-Name,
Version, and SymbolicName all specified) and to make sure that it
resolves successfully against all of the other bundles in the
repository. We also require that all of the mandatory dependencies of
a bundle be satisfied through the repository before it gets added.
This may take a couple of iterations (JIRA is good for this), and
then we'll post it publicly. A governance model like this is both a
blessing and a curse :- it creates additional work on our part, and
it means it takes slightly longer for new bundles to be added. On the
flip-side it preserves the quality guarantees associated with the
repository so that end users can trust the artefacts in there.
> My worries are related to bundles people would build and as
> Import-Bundle/Import-Library look easy to use people will ignore the
> inherent "danger" of using this manifest headers, use them in the
> bundles they build and then run into troubles as they may try to
> deploy them into a standard osgi framework implementation.
> More, as I would guess people that use them will be Spring users so I
> would guess that the "problems" will be less if they were supported as
> part of Spring DM, but as I can see there is not the case as I cannot
> see any reference to them in Spring DM source code so I suppose they
> are part of DMK.
These headers are not part of Spring Dynamic Modules. Supporting
these headers involves manifest rewriting at bundle install time, and
Spring Dynamic Modules does not get involved with bundle install. It
is relatively simple to provide tools that turn any manifest using
Import-Bundle and Import-Library into one that uses only Import-
Package (the translation would have to be based on the local
repository a user was using to resolve against, since both Import-
Bundle and Import-Library use version ranges to indicate the bundles
whose packages should be imported). To alleviate any fears of being
"stuck" with a manifest that can't easily be used on a Service
Platform that doesn't support these headers I'm very happy to commit
to shipping these tools with the SpringSource Application Platform.
> I'm also wondering why you did not bring them through the OSGi
> Alliance process (RPF/RFC) if you consider them as an important
> feature? Time constraints as in they should be available now not by
> the timeframe of R5?
I believe SpringSource has contributed as much if not more than any
other party involved in the OSGi Enterprise Expert Group. Through RFC
124 we are committed to created a standard based on both Spring
Dynamic Modules and the core Spring Container ("beans" schema)
through the OSGi Alliance, giving both of them to an "OSGi" namespace
and then implementing support for that namespace in Spring Dynamic
Modules as the RI. In my view that's a very major contribution and
shows how serious we are about supporting the OSGi Alliance and the
standards process. If we had taken the first draft of my Spring
Dynamic Modules specification and simply ratified that as an OSGi
Alliance standard (even it were possible to do such a thing) it would
have been a mistake, since through the community feedback and real-
world experience of building on Spring DM over the last 18 months
there have been many improvements. These are fed into the RFC so that
we end up with a better standard. Likewise with these new headers we
have introduced I prefer to see them proven in practice before being
standardized (should the Core Platform Expert Group ever decide they
wanted to do that). Also of course as you say, the time to take OSGi
to the Enterprise is now - not sometime in 2009 when R5 comes out.
The next meeting of the Core Platform and Enterprise Expert Groups is
at the SpringSource offices in a little over two weeks time, and I'm
sure we'll be discussing some of these issues then.
> Another feature witch "bothers" me is the PAR. In some aspects this is
> similar to the new packaging introduced by Deployment Admin (indeed
> this is more complex) and I'm wondering why you did not go that way or
> if it was not enough agin why you did not bring the necessary changes
> / new features via OSGi Alliance.
As any Enterprise Expert Group member will tell you, I've been
consistent in my message that we need support in the standard for a
scope that can represent an application. Discussions in the Core
Platform Expert Group have not yet reached a resolution on this
point. The focus of the par is to provide the simplest option
possible for the deployment and management of Spring-based
applications (collections of bundles). A par forms a unit of scoping
at runtime as well as deployment/administration time.
> I know that Spring vision is that is better to have a battle field
> proven standard then a committee one but OSGi Alliance CPEG / EEG is
> not JCP and from what I follow on the OSGi Alliance standardization
> process the discussions only lead to better solutions as more people
> with different experiences and use cases in the field participate.
The OSGi Alliance expert groups are indeed wonderful places with a
genuine emphasis on reaching the best overall technical solution. I
trust my comments above have demonstrated SpringSource's commitment
to working in and through the relevant expert groups to this end.
Regards, Adrian.
On 4 May 2008, at 00:14, Alin Dreghiciu wrote:
>
> I will cross post this message also to Felix dev list:
>
> It is very god that the bundles from SBP does not contain this headers
> as containing them would made them unusable on standard framework
> implementations and it would be petty that all of this huge effort of
> osgi-fying common libraries would work only with S2AP. Basically I'm
> quite grateful for this effort and I think many are. I was looking and
> asking for such a thing about one year ago and would be great if we
> could combine this with the ones from Felix Commons and Eclipse Orbit
> (any ideas). I guess that if would have asked there would be people
> willing to donate / contribute to it. BTW, how can we contribute to
> this effort? For example ion Felix you create jira issues and attach a
> maven pom to it.
>
> My worries are related to bundles people would build and as
> Import-Bundle/Import-Library look easy to use people will ignore the
> inherent "danger" of using this manifest headers, use them in the
> bundles they build and then run into troubles as they may try to
> deploy them into a standard osgi framework implementation. I would not
> repeat here the problems this headers bring as I think are quite good
> covered in Neil's blog and comments
> (http://neilbartlett.name/blog/2008/05/01/springsource-app-platform-
> is-a-curates-egg/)
>
> More, as I would guess people that use them will be Spring users so I
> would guess that the "problems" will be less if they were supported as
> part of Spring DM, but as I can see there is not the case as I cannot
> see any reference to them in Spring DM source code so I suppose they
> are part of DMK.
>
> I'm also wondering why you did not bring them through the OSGi
> Alliance process (RPF/RFC) if you consider them as an important
> feature? Time constraints as in they should be available now not by
> the timeframe of R5?
>
> Another feature witch "bothers" me is the PAR. In some aspects this is
> similar to the new packaging introduced by Deployment Admin (indeed
> this is more complex) and I'm wondering why you did not go that way or
> if it was not enough agin why you did not bring the necessary changes
> / new features via OSGi Alliance.
>
> I know that Spring vision is that is better to have a battle field
> proven standard then a committee one but OSGi Alliance CPEG / EEG is
> not JCP and from what I follow on the OSGi Alliance standardization
> process the discussions only lead to better solutions as more people
> with different experiences and use cases in the field participate.
>
> Alin Dreghiciu
> http://www.ops4j.org - New Energy for OSS Communities - Open
> Participation Software.
> http://www.qi4j.org - New Energy for Java - Domain Driven
> Development.
> http://malaysia.jayway.net - Great People working on Great Projects at
> Great Places
>
> On Sat, May 3, 2008 at 7:47 PM, Adrian Colyer
> <ad...@springsource.com> wrote:
>> I wanted to clarify a question that came up on the felix-dev list
>> (to which
>> I'm not subscribed so I can't post):
>>
>> All of the bundles in the SpringSource Bundle Repository will
>> contain only
>> standard OSGi manifest headers: they are intended for use with Spring
>> Dynamic Modules on any OSGi Service Platform, not just for use
>> with the
>> SpringSource Application Platform.
>>
>> The library definition files in the repository *are* particular to
>> the
>> SpringSource AP, and simply contain a list of bundle import
>> statements
>> (symbolic name and version range) that define a group of bundles
>> commonly
>> used together to achieve some end.
>>
>> Regards, Adrian.
>>
>>
>> Adrian Colyer
>> CTO
>> SpringSource Limited
>> http://www.springsource.com
>>
>> Registered in England and Wales: No. 5187766 Registered Office: A2
>> Yeoman Gate, Yeoman Way, Worthing, West Sussex. BN13 3QZ.
>>
>>
>> E-mails should be checked by the recipient to ensure that there
>> are no
>> viruses and SpringSource does not accept any responsibility if
>> this is
>> not done. Any views or opinions presented are solely those of the
>> author and do not necessarily represent those of SpringSource.
>>
>>
>>
>>
>>>
>>
>
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google
> Groups "Spring and OSGi" group.
> To post to this group, send email to spring-osgi@googlegroups.com
> To unsubscribe from this group, send email to spring-osgi-
> unsubscribe@googlegroups.com
> For more options, visit this group at http://groups.google.com/
> group/spring-osgi?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
Adrian Colyer
CTO
SpringSource Limited
http://www.springsource.com
Registered in England and Wales: No. 5187766 Registered Office: A2
Yeoman Gate, Yeoman Way, Worthing, West Sussex. BN13 3QZ.
This e-mail and any attachments transmitted with it are strictly
confidential and intended solely for the person or entity to whom they
are addressed. Unauthorised use, copying, disclosure or distribution
is prohibited. If you receive this e-mail in error please notify the
sender immediately and then delete it along with any attachments.
E-mails should be checked by the recipient to ensure that there are no
viruses and SpringSource does not accept any responsibility if this is
not done. Any views or opinions presented are solely those of the
author and do not necessarily represent those of SpringSource.
Re: SpringSource Bundle Repository Bundles will only contain standard OSGi manifest headers
Posted by Glyn Normington <gl...@apache.org>.
On 6 May 2008, at 13:26, Peter Kriens wrote:
> On 4 mei 2008, at 01:14, Alin Dreghiciu wrote:
>
>>
>> I will cross post this message also to Felix dev list:
>>
>> It is very god that the bundles from SBP does not contain this
>> headers
>> as containing them would made them unusable on standard framework
>> implementations and it would be petty that all of this huge effort of
>> osgi-fying common libraries would work only with S2AP. Basically I'm
>> quite grateful for this effort and I think many are. I was looking
>> and
>> asking for such a thing about one year ago and would be great if we
>> could combine this with the ones from Felix Commons and Eclipse Orbit
>> (any ideas). I guess that if would have asked there would be people
>> willing to donate / contribute to it. BTW, how can we contribute to
>> this effort? For example ion Felix you create jira issues and
>> attach a
>> maven pom to it.
You can request that a bundle be added by raising an issue at:
http://issuetracker.springsource.com/secure/CreateIssue!default.jspa
>>
>> My worries are related to bundles people would build and as
>> Import-Bundle/Import-Library look easy to use people will ignore the
>> inherent "danger" of using this manifest headers, use them in the
>> bundles they build and then run into troubles as they may try to
>> deploy them into a standard osgi framework implementation. I would
>> not
>> repeat here the problems this headers bring as I think are quite good
>> covered in Neil's blog and comments
>> (http://neilbartlett.name/blog/2008/05/01/springsource-app-
>> platform-is-a-curates-egg/)
Import-Bundle and Import-Library are conveniences primarily aimed at
application developers. I think the danger you allude to is real, but
small. More advanced OSGi developers who write bundles for use in
libraries will know to avoid non-standard features if portability is
a requirement.
>>
>> More, as I would guess people that use them will be Spring users so I
>> would guess that the "problems" will be less if they were
>> supported as
>> part of Spring DM, but as I can see there is not the case as I cannot
>> see any reference to them in Spring DM source code so I suppose they
>> are part of DMK.
Why do you say there would be fewer "problems" if Spring DM supported
these manifest headers? The issue seems to be one of vendor specific
vs OSGi standard headers.
>>
>> I'm also wondering why you did not bring them through the OSGi
>> Alliance process (RPF/RFC) if you consider them as an important
>> feature? Time constraints as in they should be available now not by
>> the timeframe of R5?
Absolutely - time constraints. Also, wouldn't it make sense to get
real user feedback and hone these features *before* attempting to
standardise them? OSGi is a mature standard and we wouldn't want
start lobbing in all sorts of new features which can be built in
terms of what already there.
>>
>> Another feature witch "bothers" me is the PAR. In some aspects
>> this is
>> similar to the new packaging introduced by Deployment Admin (indeed
>> this is more complex) and I'm wondering why you did not go that
>> way or
>> if it was not enough agin why you did not bring the necessary changes
>> / new features via OSGi Alliance.
Deployment packages in Deployment Admin have some similarities to
PARs and libraries in the SpringSource Application Platform, but PARs
and libraries are intended to make a clear distinction between non-
shared application code and shared libraries which can be used by
multiple applications. PARs in particular are scoped (as I described
earlier) to prevent the kind of sharing violations alluded to in
Deployment Admin. Putting it another way, if all we had wanted to
achieve was a way of packaging together groups of bundles for
deployment and management, then Deployment Admin may have been
sufficient, but we needed to do much more than this to make life easy
for Spring users.
>>
>> I know that Spring vision is that is better to have a battle field
>> proven standard then a committee one but OSGi Alliance CPEG / EEG is
>> not JCP and from what I follow on the OSGi Alliance standardization
>> process the discussions only lead to better solutions as more people
>> with different experiences and use cases in the field participate.
I agree that the OSGi Alliance is a remarkably effective standards
body, but I would make the point again that with a mature, capable
standard like OSGi R4.1, we shouldn't rush to bolt on new features
unless they are proven in the field. Meanwhile the Platform will be
careful to honour standard OSGi manifests and to rewrite non-standard
extensions in terms of the standard to ensure a high degree of
compatibility.
Glyn
Re: SpringSource Bundle Repository Bundles will only contain standard OSGi manifest headers
Posted by Peter Kriens <pe...@aqute.biz>.
Very well said ...
Kind regards,
Peter Kriens
On 4 mei 2008, at 01:14, Alin Dreghiciu wrote:
>
> I will cross post this message also to Felix dev list:
>
> It is very god that the bundles from SBP does not contain this headers
> as containing them would made them unusable on standard framework
> implementations and it would be petty that all of this huge effort of
> osgi-fying common libraries would work only with S2AP. Basically I'm
> quite grateful for this effort and I think many are. I was looking and
> asking for such a thing about one year ago and would be great if we
> could combine this with the ones from Felix Commons and Eclipse Orbit
> (any ideas). I guess that if would have asked there would be people
> willing to donate / contribute to it. BTW, how can we contribute to
> this effort? For example ion Felix you create jira issues and attach a
> maven pom to it.
>
> My worries are related to bundles people would build and as
> Import-Bundle/Import-Library look easy to use people will ignore the
> inherent "danger" of using this manifest headers, use them in the
> bundles they build and then run into troubles as they may try to
> deploy them into a standard osgi framework implementation. I would not
> repeat here the problems this headers bring as I think are quite good
> covered in Neil's blog and comments
> (http://neilbartlett.name/blog/2008/05/01/springsource-app-platform-is-a-curates-egg/
> )
>
> More, as I would guess people that use them will be Spring users so I
> would guess that the "problems" will be less if they were supported as
> part of Spring DM, but as I can see there is not the case as I cannot
> see any reference to them in Spring DM source code so I suppose they
> are part of DMK.
>
> I'm also wondering why you did not bring them through the OSGi
> Alliance process (RPF/RFC) if you consider them as an important
> feature? Time constraints as in they should be available now not by
> the timeframe of R5?
>
> Another feature witch "bothers" me is the PAR. In some aspects this is
> similar to the new packaging introduced by Deployment Admin (indeed
> this is more complex) and I'm wondering why you did not go that way or
> if it was not enough agin why you did not bring the necessary changes
> / new features via OSGi Alliance.
>
> I know that Spring vision is that is better to have a battle field
> proven standard then a committee one but OSGi Alliance CPEG / EEG is
> not JCP and from what I follow on the OSGi Alliance standardization
> process the discussions only lead to better solutions as more people
> with different experiences and use cases in the field participate.
>
> Alin Dreghiciu
> http://www.ops4j.org - New Energy for OSS Communities - Open
> Participation Software.
> http://www.qi4j.org - New Energy for Java - Domain Driven
> Development.
> http://malaysia.jayway.net - Great People working on Great Projects at
> Great Places
>
> On Sat, May 3, 2008 at 7:47 PM, Adrian Colyer
> <ad...@springsource.com> wrote:
>> I wanted to clarify a question that came up on the felix-dev list
>> (to which
>> I'm not subscribed so I can't post):
>>
>> All of the bundles in the SpringSource Bundle Repository will
>> contain only
>> standard OSGi manifest headers: they are intended for use with Spring
>> Dynamic Modules on any OSGi Service Platform, not just for use with
>> the
>> SpringSource Application Platform.
>>
>> The library definition files in the repository *are* particular to
>> the
>> SpringSource AP, and simply contain a list of bundle import
>> statements
>> (symbolic name and version range) that define a group of bundles
>> commonly
>> used together to achieve some end.
>>
>> Regards, Adrian.
>>
>>
>> Adrian Colyer
>> CTO
>> SpringSource Limited
>> http://www.springsource.com
>>
>> Registered in England and Wales: No. 5187766 Registered Office: A2
>> Yeoman Gate, Yeoman Way, Worthing, West Sussex. BN13 3QZ.
>>
>>
>> E-mails should be checked by the recipient to ensure that there are
>> no
>> viruses and SpringSource does not accept any responsibility if this
>> is
>> not done. Any views or opinions presented are solely those of the
>> author and do not necessarily represent those of SpringSource.
>>
>>
>>
>>
>>>
>>
>
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google
> Groups "Spring and OSGi" group.
> To post to this group, send email to spring-osgi@googlegroups.com
> To unsubscribe from this group, send email to spring-osgi-unsubscribe@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/spring-osgi?hl=en
> -~----------~----~----~----~------~----~------~--~---
>