2008/5/6 Glyn Normington <[EMAIL PROTECTED]>: > 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. >
Hi Glyn, are you saying that BRITS will continue to re-bundle existing OSGi bundles, such as the latest commons-* releases to fit in with this export-only policy? ideally the commons bundles will eventually move towards only exporting their API rather than everything (including the implementation), but I would expect the API to continue to be imported and exported, unless there was a compelling reason not to do this... anyway, I'm sure the maintainers of re-bundled artifacts would be interested in any improvements to their bundle manifests (as long as the new manifest works for the general case, and is not just tuned for use in Spring) -- Cheers, Stuart
