The rule you mentioned is the general rule, and I agree with it in most of the cases for API packages. However, as I mentioned, for blueprint, things are a bit different. You can see that by checking 121.3.1 which specifically talks about class space compatibility, and there's a reason for that as I explained (I can go though it with more details if necessary). The overall goal is to actually split the class space into separate portions.
So first, that's would be incompatible with 0.3 because it would needs an additional bundle to deploy (that will the case in 1.0 anyway with the small bundles, so please can we try to at least keep one version clean ?). Second, it would lead to serious problems when trying to have multiple blueprint extenders in the same container, which is supposed to work to some degree. And last, the only benefit of sharing API is that you should be able to update the extender without having to refresh the blueprint bundles. However, in real cases, that's rarely the case and the all the blueprint beans have to be recreated anyway, so the benefit is very low. On Tue, May 22, 2012 at 7:52 AM, Siano, Stephan <[email protected]> wrote: > > AFAIK the OSGi spec proposes to do the import and export in such cases > (section 3.5.6 of the 4.3 core spec). Personally I find it much more probable > that the compendium or enterprise bundles are present, than having two > different blueprint implementations on the same stack. I also do not see any > issues with the different blueprint implementation importing the same > org.osgi.blueprint APIs. They are specified in the spec and should always be > the same wherever they come from. > > So I essentially do think that it's a good idea to import the osgi api. > > -----Original Message----- > From: Guillaume Nodet [mailto:[email protected]] > Sent: Dienstag, 22. Mai 2012 00:44 > To: [email protected] > Subject: Re: svn commit: r1340184 - > /aries/branches/blueprint-0.3.2-fixes/blueprint-bundle/pom.xml > > I don't think that's a good idea to import the osgi api. > > It may lead to problems if multiple blueprint implementations are > deployed for some reason. > To support such a case, the blueprint bundles are supposed to import > the org.osgi.blueprint package iirc, so that the osgi framework wiring > will be correctly split and only the blueprint extender which has been > imported will actually extend the bundle. By importing the api, two > extenders can then be compatible and both would extend the bundle. > > IF the main reason is that people have the compendium bundle deployed, > well, that's a bad idea because the same problem also tend to apply > with other osgi services such as ConfigAdmin and others which usually > ship their own version of the package. > > > On Fri, May 18, 2012 at 7:42 PM, <[email protected]> wrote: >> Author: dkulp >> Date: Fri May 18 17:42:46 2012 >> New Revision: 1340184 >> >> URL: http://svn.apache.org/viewvc?rev=1340184&view=rev >> Log: >> Import the osgi blueprint stuff so it can work with a wider range of >> containers >> >> Modified: >> aries/branches/blueprint-0.3.2-fixes/blueprint-bundle/pom.xml >> >> Modified: aries/branches/blueprint-0.3.2-fixes/blueprint-bundle/pom.xml >> URL: >> http://svn.apache.org/viewvc/aries/branches/blueprint-0.3.2-fixes/blueprint-bundle/pom.xml?rev=1340184&r1=1340183&r2=1340184&view=diff >> ============================================================================== >> --- aries/branches/blueprint-0.3.2-fixes/blueprint-bundle/pom.xml (original) >> +++ aries/branches/blueprint-0.3.2-fixes/blueprint-bundle/pom.xml Fri May 18 >> 17:42:46 2012 >> @@ -40,7 +40,6 @@ >> </aries.osgi.activator> >> <aries.osgi.import> >> !org.apache.aries.blueprint*, >> - !org.osgi.service.blueprint*, >> org.eclipse.osgi.internal.loader;resolution:=optional, >> org.eclipse.osgi.framework.internal.core;resolution:=optional, >> org.eclipse.osgi.framework.adaptor;resolution:=optional, >> >> > > > > -- > ------------------------ > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > FuseSource, Integration everywhere > http://fusesource.com -- ------------------------ Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ FuseSource, Integration everywhere http://fusesource.com
