Hi, thank you for the very detailed answer, it was very useful. I experienced problem during using Equinox from Pax Exam or Eclipse Libra when the blueprint API was twice in the classpath during system start. It is a bit random to reproduce but with the new knowledge I will try go deeper to the problem. This may be a problem of Equinox then.
Thanks and regards, Balazs Zsoldos Software Architect Mobile: +36-70/594-92-34 Everit Kft. https://www.everit.biz On Tue, May 8, 2012 at 3:17 PM, Neil Bartlett <[email protected]> wrote: > 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 <[email protected]> > 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 > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > Holger Hoffstätte <[email protected]> > 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 > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > Balázs Zsoldos <[email protected]> > 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 > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev >
<<compose-unknown-contact.jpg>>
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
