felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alin Dreghiciu" <adreghi...@gmail.com>
Subject Re: SpringSource Bundle Repository Bundles will only contain standard OSGi manifest headers
Date Sat, 03 May 2008 23:14:12 GMT
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
<adrian.colyer@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
>  -~----------~----~----~----~------~----~------~--~---
>
>

Mime
View raw message