tag:blogger.com,1999:blog-18772002.post1617657445292912167..comments2023-12-06T19:00:46.094+00:00Comments on OSGi Blog: Release 6 of OSGi Compendium, OSGi Enterprise and OSGi Residential specifications availableJürgen Alberthttp://www.blogger.com/profile/02725834158183495837noreply@blogger.comBlogger14125tag:blogger.com,1999:blog-18772002.post-11851406105921124932016-02-24T18:11:30.966+00:002016-02-24T18:11:30.966+00:00OSGi did not change the groupid. Other people sele...OSGi did not change the groupid. Other people selected the old groupid when they uploaded the jars to maven central.<br /><br />Also, 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.BJ Hargravehttps://www.blogger.com/profile/05791451307210957698noreply@blogger.comtag:blogger.com,1999:blog-18772002.post-65884307152972010982016-02-24T16:46:43.423+00:002016-02-24T16:46:43.423+00:00Could you also push an update with the old groupId...Could 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.kwinhttps://www.blogger.com/profile/08805255492991794235noreply@blogger.comtag:blogger.com,1999:blog-18772002.post-68855069849752123852016-01-18T17:08:58.171+00:002016-01-18T17:08:58.171+00:00You will need to directly list all the bundles you...You 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.BJ Hargravehttps://www.blogger.com/profile/05791451307210957698noreply@blogger.comtag:blogger.com,1999:blog-18772002.post-68761311871139676082016-01-18T16:59:57.405+00:002016-01-18T16:59:57.405+00:00Actually those individual bundles are lacking the ...Actually 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 kwinhttps://www.blogger.com/profile/08805255492991794235noreply@blogger.comtag:blogger.com,1999:blog-18772002.post-43060979096685766582015-11-23T14:19:55.384+00:002015-11-23T14:19:55.384+00:00Don't install osgi.cmpn as a bundle. It wont r...Don't install osgi.cmpn as a bundle. It wont resolve.BJ Hargravehttps://www.blogger.com/profile/05791451307210957698noreply@blogger.comtag:blogger.com,1999:blog-18772002.post-91711136134151372332015-11-23T05:07:51.211+00:002015-11-23T05:07:51.211+00:00I am getting the same error because i am doing thi...I am getting the same error because i am doing this. The only alternative that is working is if i use embed-dependency <br />Embed-Dependency: org.slf4j,logback-core,logback-classic,osgi.cmpn<br /><br />but i dont want to do this, is there an alternative?<br /><br />// Start OSGi Framework and OSGi bundles<br /> try {<br /> framework.init();<br /> framework.start();<Pakaihttps://www.blogger.com/profile/01885821268513432579noreply@blogger.comtag:blogger.com,1999:blog-18772002.post-46326908457036051452015-11-07T19:13:19.713+00:002015-11-07T19:13:19.713+00:00These bundles are made available if people need th...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. BJ Hargravehttps://www.blogger.com/profile/05791451307210957698noreply@blogger.comtag:blogger.com,1999:blog-18772002.post-71381752026847167332015-11-07T19:01:50.489+00:002015-11-07T19:01:50.489+00:00Ok thanks. but I'm wondering... as far I know ...Ok 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.<br />Using these new runtime bundles in this context (before implementors do remove those spec packages from their bundles) wouldn't bring some wire/Cristiano Gaviãohttps://www.blogger.com/profile/14887987648892135349noreply@blogger.comtag:blogger.com,1999:blog-18772002.post-19223059222521691342015-11-05T09:30:20.939+00:002015-11-05T09:30:20.939+00:00Yes, these jars can be installed as bundles and us...Yes, these jars can be installed as bundles and used at runtime.BJ Hargravehttps://www.blogger.com/profile/05791451307210957698noreply@blogger.comtag:blogger.com,1999:blog-18772002.post-84483225647547151502015-11-03T21:18:34.170+00:002015-11-03T21:18:34.170+00:00BJ, I saw at maven centrak that was released on ja...BJ, I saw at maven centrak that was released on jar for almost every spec, for example: org.osgi.service.deploymentadmin.<br />They are runtime bundles, right? <br />Can you explain how the new bundles was planed to be used? by implementers and final users?Cristiano Gaviãohttps://www.blogger.com/profile/14887987648892135349noreply@blogger.comtag:blogger.com,1999:blog-18772002.post-67274152732505091182015-08-14T21:08:29.872+00:002015-08-14T21:08:29.872+00:00Yes, it is intentional. The compendium jar was nev...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.BJ Hargravehttps://www.blogger.com/profile/05791451307210957698noreply@blogger.comtag:blogger.com,1999:blog-18772002.post-3503503602113046372015-08-14T21:01:15.051+00:002015-08-14T21:01:15.051+00:00I recently upgraded to osgi.cmpn:6.0.0. When I sta...I recently upgraded to osgi.cmpn:6.0.0. When I start Felix, I get the following error:<br /><br />org.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 toAnonymoushttps://www.blogger.com/profile/07813054841038848421noreply@blogger.comtag:blogger.com,1999:blog-18772002.post-76020079366219227212015-08-13T12:21:44.763+00:002015-08-13T12:21:44.763+00:00Yes. This is the first time that the OSGi Alliance...Yes. 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 BJ Hargravehttps://www.blogger.com/profile/05791451307210957698noreply@blogger.comtag:blogger.com,1999:blog-18772002.post-58347936959386001792015-08-13T08:01:11.838+00:002015-08-13T08:01:11.838+00:00Is there a reason for the change in artifactId fro...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.leffatushttps://www.blogger.com/profile/00537137122833251842noreply@blogger.com