I am pleased to announce that the OSGi Expert Groups and the OSGi membership has approved Release 6 of the OSGi Compendium, OSGi Enterprise and OSGi Residential specifications. They are now available for download from OSGi at http://www.osgi.org/Specifications/HomePage. You can download the specification PDFs, the API JAR files, and also the javadoc.
For you maven users, I also released the API JAR files to Maven Central and Jcenter. The maven coordinates are org.osgi:osgi.cmpn:6.0.0, org.osgi:osgi.enterprise:6.0.0, and org.osgi:osgi.residential:6.0.0. (I just uploaded these, so it make take a bit of time for them to be visible.)
Now time for some vacation... :-)
Is there a reason for the change in artifactId from org.osgi.compendium to osgi.cmpn? This requires a lot of POM changes rather than a simple version change in a BOM.
ReplyDeleteYes. This is the first time that the OSGi Alliance itself released the companion code jars to maven central. We now build the necessary maven metadata as part of the regular OSGi builds thanks to maven support improvements in bnd. As part of this, we regularized the artifact id to be identical to the Bundle-SymbolicName of the jar. Prior to this release, 3rd parties put the OSGi companion code jars in maven central and they unfortunately used an improper artifact id.
DeleteCould you also push an update with the old groupId and artifactId containing a modified pom with a relocation entry (https://maven.apache.org/guides/mini/guide-relocation.html). That way it is much easier for others to figure out what the new official GAV is.
DeleteOSGi did not change the groupid. Other people selected the old groupid when they uploaded the jars to maven central.
DeleteAlso, I think the element is for the old version to point to the new GAV. Since OSGi did not build or release the older version, we can't update them with elements.
I recently upgraded to osgi.cmpn:6.0.0. When I start Felix, I get the following error:
ReplyDeleteorg.osgi.framework.BundleException: Unable to resolve org.apache.felix.http.jetty [14](R 14.0): missing requirement [org.apache.felix.http.jetty [14](R 14.0)] osgi.wiring.package; (&(osgi.wiring.package=org.osgi.service.http.context)(version>=1.0.0)(!(version>=1.1.0))) [caused by: Unable to resolve osgi.cmpn [16](R 16.0): missing requirement [osgi.cmpn [16](R 16.0)] osgi.compile.time.only; (&(must.not.resolve=*)(!(must.not.resolve=*)))] Unresolved requirements: [[org.apache.felix.http.jetty [14](R 14.0)] osgi.wiring.package; (&(osgi.wiring.package=org.osgi.service.http.context)(version>=1.0.0)(!(version>=1.1.0)))]
It appears that the compendium jar you uploaded has a manifest entry that indicates it is only intended to be used at compile-time-only. Is this intentional? Is there a different jar I should be deploying at runtime?
Yes, it is intentional. The compendium jar was never meant to be used at runtime but people abused it anyway. So for R6 we have added an unresolvable requirement to prevent this. The latest Felix Http implementation (used as the RI in OSGi), already includes the OSGi http packages.
DeleteI am getting the same error because i am doing this. The only alternative that is working is if i use embed-dependency
DeleteEmbed-Dependency: org.slf4j,logback-core,logback-classic,osgi.cmpn
but i dont want to do this, is there an alternative?
// Start OSGi Framework and OSGi bundles
try {
framework.init();
framework.start();
BundleContext context = framework.getBundleContext();
List installedBundles = new ArrayList();
String filePath = args[0];
InputStream in = new FileInputStream(filePath);
Properties p = new Properties();
p.load(in);
if (p.size() == 0) {
System.err.println("No OSGi bundles being found in properties " + filePath);
System.exit(ERR_OSGI_ZERO_BUNDLE);
}
for(Object bundle : p.keySet()) {
if (bundle.toString().contains(BUNDLE_PREFIX)) {
System.out.println("Found Bundle: " + p.getProperty(bundle.toString()));
installedBundles.add(context.installBundle("file://" + p.getProperty(bundle.toString())));
}
}
if (installedBundles.size() == 0) {
System.err.println("No OSGi bundles being found in properties " + filePath);
System.exit(ERR_OSGI_ZERO_BUNDLE);
}
for (Bundle bundle : installedBundles) {
if (bundle.getHeaders().get(Constants.FRAGMENT_HOST) == null) {
System.out.println("Bundle start ");
bundle.start();
}
}
System.out.println("Wait For stop ");
framework.waitForStop(0);
System.exit(SUCCESS);
Don't install osgi.cmpn as a bundle. It wont resolve.
DeleteBJ, I saw at maven centrak that was released on jar for almost every spec, for example: org.osgi.service.deploymentadmin.
ReplyDeleteThey are runtime bundles, right?
Can you explain how the new bundles was planed to be used? by implementers and final users?
Yes, these jars can be installed as bundles and used at runtime.
DeleteOk thanks. but I'm wondering... as far I know big part of spec implementations that I've already worked embeds the related spec packages into its own bundle jar. The exception is with equinox that has them in one services bundle.
DeleteUsing these new runtime bundles in this context (before implementors do remove those spec packages from their bundles) wouldn't bring some wire/classloading issues?
These bundles are made available if people need them. They can be used at compiler time and at runtime. It is still a best practice for implementation bundles to contain and export the spec packages they implement. If they also import these packages, then there should be no problem also installing these bundles at runtime.
DeleteActually those individual bundles are lacking the necessary transitive dependencies. E.g. org.osgi.service.component.runtime.ServiceComponentRuntime#disableComponent refers to the class org.osgi.util.promise.Promise. That is a problem at compile time, as just referencing "org.osgi.service.component" is not enough, all transitive dependencies need to be listed as well in your own dependencies section, although those are only used. Would you consider providing a those artifacts with a pom.xml which includes all the transitive dependencies?
DeleteYou will need to directly list all the bundles you need to depend upon. Since we build OSGi in a bnd based build and not a maven build, it is not possible to have the pom accurately reflect the jar dependencies.
Delete