Re: [osgi-dev] OSGI cmpn and enterprise jars

[Neil Bartlett]

The Compendium JAR is intended to contain all of the Compendium (i.e. non-core) OSGi APIs. However the latest Enterprise spec is newer later than the latest Compendium (4.2), which is the reason why it contains additional APIs that are not yet in the Compendium. The Compendium 4.3 JAR, when it becomes available, will contain all of the Enterprise APIs. I disagree with Holger here about the bundling. I don't see a problem with the Compendium bundle containing many unrelated packages, or with deploying that bundle into the runtime; although they do contain multiple packages that will be typically unused, those packages do not have any dependencies and they are independently versioned. Regarding the error you referenced in your original email... bundle activating (starting) has nothing to do with resolution, therefore it is irrelevant what order you start these bundles in. However if you install *and resolve* them individually then you can end up with a split class-space. This is always the case if you install some bundles, resolve them, and then later install and resolve again. You should always try to install all of the bundles you intend to use, and then resolve as a single operation. If you do this then the framework will choose the most appropriate wiring, and your hypothetical scenario with Blueprint events should not occur. Regards Neil Balázs Zsoldos 8 May 2012 12:31 Hi, thank you for the very fast response. I would like to make things a bit more clear. I would like to create separate jars that contains only the relevant packages (e.g. osgi-jdbc.jar, osgi-blueprint.jar, ...) We have a public maven repository where I would like to upload these jars. Do you have any restriction or recommendation concerning to the maven groupId:artifactId:version naming? The best would be org.osgi:osgi-blueprint:4.2.0 but if you prefer I can think in other grouId first not to occupy the standard one. Regards, Balazs Zsoldos Software Architect Mobile: +36-70/594-92-34 Everit Kft. https://www.everit.biz _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev Holger Hoffstätte 8 May 2012 11:48 AFAIK this is "historical" (always a nice excuse :) because the APIs are/were always released together for & with a core framework release. Other than that there is IMHO no practical reason or benefit, but - as your posting explains - quite a few downsides. It would be significantly easier if all official service APIs were released as separate artifacts. They have clearly separated versions and requirements; except for the core framework there is IMHO no need for arbitrarily aggregated jars. just my 0.01€, -h _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev Balázs Zsoldos 8 May 2012 11:17 Hi, I would have a couple of question about the cmpn and enterprise jars. Why are there two jars with almost the same content. I need for example the jdbc DataSourceFactory interface so I use the enterprise jar. However if I need something from the cmpn jar and I also use Blueprint I will meet the problem that there are two jars with the same package will exist. Now if: osgi enterprise starts blueprint container starts compendium starts a bundle that uses the BlueprintListener interface to catch Blueprint events starts then the bundle will not catch the events as the bundle may use different interface than the blueprint container. Is there any practical reason for this or is there a jar that merges the two? Regards, Balazs Zsoldos Software Architect Mobile: +36-70/594-92-34 Everit Kft. https://www.everit.biz _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev

_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev