Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Received-SPF: pass (athena.apache.org: domain of glyn.normington@gmail.com
 designates 216.239.58.191 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:to:message-id:content-type:from:subject:date:x-mailer:sender;
        b=DcKvm0nLWjkNk3HSImY8Nh9DjPYTQDzDQihEG0s5cW9lEAp5GTEWaDa6dNzJ7aV73C1OkjdmmpDQLQK6tgVArHd/PsnULPWVJYdgeVzgAxf+KJYyqL4UprGK+Ekl7aGp2x804sPoQ6VkTd6i/HRFWYGY+yMbNMhmpYbsUAtewCQ=
Mime-Version: 1.0 (Apple Message framework v753)
To: dev@felix.apache.org
Message-Id: <E5B1E9BE-A9EA-4F34-AE14-9194E9D6E87B@apache.org>
Content-Type: multipart/alternative; boundary=Apple-Mail-1--156365700
From: Glyn Normington <glyn@apache.org>
Subject: Re: SpringSource Bundle Repository
Date: Tue, 6 May 2008 14:04:28 +0100
Sender: Glyn Normington <glyn.normington@gmail.com>

--Apple-Mail-1--156365700
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

Since I just re-joined this list, please excuse a single email with  
multiple sub-threads.

 >On another point, I downloaded Commons IO 1.4 (
 >http://tinyurl.com/5n8p4f ) which we released as an OSGi bundle and
 >they seem to have (bizarely IMO) re-packaged the original jar - but
 >without re-importing the exported packages, which the original jar's
 >manifest had, and was a recommended here. Perhaps its worth someone
 >making the case to them for that.

I just responded to the corresponding issue (http:// 
issuetracker.springsource.com/browse/BRITS-5) as follows:

 >OSGi inherited a packaging style from its earlier releases where  
each bundle imports all the packages that the bundle exports so that  
these packages could
 >be substituted by another bundle. The laudable intention is that a  
bundle should continue to function properly when some or all of its  
exported packages are
 >provided by one or more other bundles.
 >
 >However, in practice, this places stringent compatibility  
requirements on exported packages which are difficult to satisfy,  
especially in the case of
 >implementation packages, and which place an unrealistic testing  
burden on the bundle developer.
 >
 >Substitutability is even harder to get right when constructing  
bundles from JAR files which were not designed primarily for, or  
tested in, an OSGi environment.
 >So we have preferred, in general, not to import each package  
exported from a bundle. Rather than constructing bundles of loosely  
coupled content which can
 >be substituted by other bundles, it is more robust for each bundle  
to provide a relatively tightly coupled collection of packages which  
cooperate with other
 >bundles via services.

There are a number of trade-off's like this in the SpringSource  
Application Platform and the BRITS repository to make them easy to  
use by Spring developers.

The design point was that expert OSGi users could use standard OSGi  
R4.1 features supported by the Platform in the normal way, but that  
we needed to make things easier for enterprise developers with no  
OSGi experience.

 >I think there could be another issue, which I wasn't aware of  
initially,
 >in that they introduce some new manifest headers for specifying
 >dependencies. If they do this for their repository bundles, then it
 >might not be so useful for us...I am not sure what it means for us, so
 >it will have to be investigated too.

To reiterate Adrian's earlier statement, none of the bundles in BRITS  
use the SpringSource Application Platform specific manifest headers.  
We aim that BRITS will be more generally useful than for just the  
Platform.

 >Except for the third-party dependencies, it sounds an awful lot like
 >the deployment packages introduced in the R4.1 spec. I would have to
 >take a more detailed look to see how the two compare exactly, the
 >benefits you quoted are still a bit "inprecise". For example, how do
 >PAR files form an explicit scope around all the bundles in the
 >application? Is the application hidden, is there some security
 >mechanism in place, or what?

The Platform rewrites the manifests of the bundles of an application  
(i.e. a PAR file) to use mandatory matching attributes to form a  
scope. For example the following bundle of an application called  
"MyApp" version 1.0:

Manifest-Version: 1.0
Bundle-Name: MyBundle
Bundle-ManifestVersion: 2
Bundle-SymbolicName: MyBundle
Export-Package: my.package.p
Bundle-Version: 1

is scoped to:

Manifest-Version: 1.0
Bundle-Name: MyBundle
Platform-Scope: MyApp-1
Bundle-ManifestVersion: 2
Bundle-SymbolicName: MyApp-1-MyBundle
Export-Package:  
my.package.p;platform_scope="MyApp-1";mandatory:="platform_scope"
Bundle-Version: 1

 >From what I understood is just the way to express the dependency on
 >their new introduced "libraries" so a kind of require-bundle on a
 >larger scale. Even require bundle looks to me as too coarse grain
 >dependency and has it's issues so an import library, which is a set of
 >bundles only looks like trouble. Especially when there is poor
 >documented behavior for now and related to conflicting packages in
 >case you are importing different libraries with same exported
 >packages. But I can imagine that is an attractive option for users as
 >is less to write and care. But this can add frustration later on when
 >you wanna deploy your bundle in regular osgi framework.

import-library is converted into package imports during manifest  
rewriting, so you get the clean semantics of import-package with none  
of the semantic rough edges of require-bundle.

Glyn


--Apple-Mail-1--156365700--