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
