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
<[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
To unsubscribe from this group, send email to spring-osgi-
[EMAIL PROTECTED]
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.
