Community
Participate
Working Groups
I thought we had a similar bug already opened, but I don't see it. The projects org.eclips.osgi.services and org.eclipse.osgi.util currently contain binary .class files that we get pre-compiled from OSGi. This makes these two projects very awkward. It also has caused a pretty big issue in our migration to CBI (bug 407201). For luna I think we should convert these two projects to 'normal' plugin projects that have actual source that is compiled. This will greatly simplify the two projects. It will also make generating source bundles more simple (bug 407201). In order to do this I will need to move the org.osgi.service.io package to the org.eclipse.equinox.io. This is to avoid circular dependencies between the org.eclipse.equinox.io and the org.eclipse.osgi.services project for the javax.microedition.io package. I think this is reasonable to do for the luna release. It is considered a breaking change to remove a package from a bundle, but I am not aware of any consumers of org.osgi.service.io package at eclipse. And any possible consumers should be using import package and not require-bundle on org.eclipse.osgi.services.
Actually, we should terminate these projects and have other projects that implement an OSGi service include the OSGi package source and export the package. These projects are the equivalent of having osgi.cmpn.jar as a runtime bundle which is considered a poor practice. Implementations of an OSGi spec should provide the necessary OSGi packages and not rely on a non-cohesive "utility" bundle to provide the OSGi packages at runtime.
(In reply to comment #1) > Actually, we should terminate these projects and have other projects that > implement an OSGi service include the OSGi package source and export the > package. > > These projects are the equivalent of having osgi.cmpn.jar as a runtime > bundle which is considered a poor practice. Implementations of an OSGi spec > should provide the necessary OSGi packages and not rely on a non-cohesive > "utility" bundle to provide the OSGi packages at runtime. We cannot do that for RCP. Anything that imports org.osgi.services.cm would then be forced to have a cm implementation that exports the package. This is not something we will be able to do. org.eclipse.osgi.services needs to be there for RCP at least.
(In reply to comment #2) > We cannot do that for RCP. Why? Can't RCP change? > Anything that imports org.osgi.services.cm would > then be forced to have a cm implementation that exports the package. This > is not something we will be able to do. Or RCP needs to include the package itself in case there is no CM installed. > org.eclipse.osgi.services needs to > be there for RCP at least. In that case, where RCP can't/wont change, then they should be fine with the current version of org.eclipse.osgi.services. So we do not need to change it. If RCP needs a later version of CM, then it will need to change anyway and can adapt. Lets not "improve" the bad practice. Lets pull it from all but the RCP distro.
Here is the issue: RCP includes org.eclipse.equinox.ds. The SCR impl must import org.osgi.service.cm. We don't want to include a CM implementation in RCP so we need some bundle to export org.osgi.services.cm, but we prefer that bundle to not be the implementation of CM. There are similar cases where an OSGi service impl must import the org.osgi.services.event package, but we don't force an event admin implementation to be present. So we either need one bundle per osgi package or something akin to the org.eclipse.osgi.services bundle to work around these things.
(In reply to comment #4) This is the same issue I faced in the OSGi build for RI and CT. The answer is still not a non-cohesive bundle like org.eclipse.osgi.services which is essentially an analog to osgi.cmpn.jar. The answer is a small bundle which contains just the package you need such as org.osgi.service.cm or org.osgi.service.event.
(In reply to comment #5) > (In reply to comment #4) > > This is the same issue I faced in the OSGi build for RI and CT. The answer > is still not a non-cohesive bundle like org.eclipse.osgi.services which is > essentially an analog to osgi.cmpn.jar. The answer is a small bundle which > contains just the package you need such as org.osgi.service.cm or > org.osgi.service.event. So, for cases where we don't want to package the service package with the impl we make a bundle that contains the single package? Or do we have one bundle for that purpose? If we are going to make breaking changes like this then we might as well stop providing the org.eclipse.osgi.util bundle altogether (bug 411412).
Renaming bug in light of current discussions.
org.eclipse.osgi.services currently contains the following packages: org.osgi.service.cm org.osgi.service.component org.osgi.service.component.annotations org.osgi.service.device org.osgi.service.event org.osgi.service.http org.osgi.service.io org.osgi.service.log org.osgi.service.metatype org.osgi.service.provisioning org.osgi.service.upnp org.osgi.service.useradmin org.osgi.service.wireadmin I propose we do the following: org.osgi.service.cm: Move to new org.eclipse.equinox.service.cm bundle org.osgi.service.component Move to org.eclipse.equinox.ds impl bundle org.osgi.service.component.annotations Do not ship, no need for these at runtime org.osgi.service.device Move to org.eclipse.equinox.device impl bundle org.osgi.service.event Move to org.eclipse.equinox.event impl bundle or Move to new org.eclipse.equinox.service.event bundle - Not sure where org.eclipse.equinox.event is included, if in RCP then we can likely just move the package to the equinox.event impl bundle org.osgi.service.http Move to new org.eclipse.equinox.service.http bundle org.osgi.service.io Move to org.eclipse.equinox.io impl bundle org.osgi.service.log Already in org.eclipse.osgi since we have a log service impl there org.osgi.service.metatype Move to org.eclipse.equinox.metatype impl bundle (not sure on this one) org.osgi.service.provisioning Move to org.eclipse.equinox.ip impl bundle org.osgi.service.upnp Stop shipping altogether org.osgi.service.useradmin Move to org.eclipse.equinox.useradmin impl bundle org.osgi.service.wireadmin Move to org.eclipse.equinox.wireadmin impl bundle In summary: - Add three new service interface bundles to avoid having to pull in impl bundles when not needed: org.eclipse.equinox.service.cm org.eclipse.equinox.service.event org.eclipse.equinox.service.http - Move the other service packages which we have implementations for into the equinox impl bundes - Stop shipping all the other service packages (e.g upnp).
(In reply to comment #8) > - Add three new service interface bundles to avoid having to pull in impl > bundles when not needed: > > org.eclipse.equinox.service.cm > org.eclipse.equinox.service.event > org.eclipse.equinox.service.http > I think the BSNs for these three bundles should be: org.eclipse.osgi.service.cm org.eclipse.osgi.service.event org.eclipse.osgi.service.http To try and distinguish them from the equinox impl equivalent: org.eclipse.equinox.cm org.eclipse.equinox.event org.eclipse.equinox.http.* I also would add some mandatory directives to the BSN to discourage require-bundle: Bundle-SymbolicName: org.eclipse.osgi.service.cm; mandatory:="requireBundle"; requireBundle="DoNotUse"
(In reply to comment #8) Some tweaks: > I propose we do the following: > > org.osgi.service.cm: > Move to new org.eclipse.equinox.service.cm bundle Move to org.eclipse.equinox.cm impl bundle (impl bundle should contain the pkg also) > org.osgi.service.http > Move to new org.eclipse.equinox.service.http bundle Move to org.eclipse.equinox.http impl bundle (impl bundle should contain the pkg also) [Not sure which bundle since there are many of them. Perhaps all of them?]
(In reply to comment #9) > I think the BSNs for these three bundles should be: > > org.eclipse.osgi.service.cm > org.eclipse.osgi.service.event > org.eclipse.osgi.service.http > +1 > To try and distinguish them from the equinox impl equivalent: > > org.eclipse.equinox.cm > org.eclipse.equinox.event > org.eclipse.equinox.http.* > > I also would add some mandatory directives to the BSN to discourage > require-bundle: > > Bundle-SymbolicName: > org.eclipse.osgi.service.cm; > mandatory:="requireBundle"; > requireBundle="DoNotUse" We should put that on all bundles! :-)
org.eclipse.equinox.event is included in RCP so I don't think we should create the org.eclipse.osgi.service.event bundle. That leaves us with only the following two bundles for the RCP feature: org.eclipse.osgi.service.cm org.eclipse.osgi.service.http All other service packages must come from the service impl bundles.
(In reply to comment #10) > (In reply to comment #8) > > Some tweaks: > > > I propose we do the following: > > > > org.osgi.service.cm: > > Move to new org.eclipse.equinox.service.cm bundle > Move to org.eclipse.equinox.cm impl bundle (impl bundle should contain > the pkg also) > > > org.osgi.service.http > > Move to new org.eclipse.equinox.service.http bundle > Move to org.eclipse.equinox.http impl bundle (impl bundle should contain > the pkg also) > [Not sure which bundle since there are many of them. Perhaps all of > them?] These will leave our repo with some strange options that will cause a deployment operation guess which artifact to pull down to provide the package at runtime. I would prefer us to limit the org.osgi packages to a single artifact in our repo if possible.
(In reply to comment #13) > These will leave our repo with some strange options that will cause a > deployment operation guess which artifact to pull down to provide the > package at runtime. I would prefer us to limit the org.osgi packages to a > single artifact in our repo if possible. Perhaps then these API package only bundles should be part of RCP if it does not want to use an implementation? Why should those who want to use an implementation have to use 2 bundles (API package bundle and impl bundle) for cm and http? This is special casing these bundles just for RCP.
(In reply to comment #10) > > org.osgi.service.http > > Move to new org.eclipse.equinox.service.http bundle > Move to org.eclipse.equinox.http impl bundle (impl bundle should contain > the pkg also) > [Not sure which bundle since there are many of them. Perhaps all of > them?] The org.eclipse.equinox.http is the impl bundle that should contain the org.osgi.service.http. This is the 'base' bundle that is used to implement an http service based on some container implementation (jetty, servlet bridge etc). It turns out that org.eclipse.equinox.http is not in RCP. I think we may be able to get by with only including the org.osgi.service.http package in the org.eclipse.equinox.http impl bundle. CM is the only real problem child since we do not want to include the CM impl bundle everywhere that DS impl is needed.
(In reply to comment #15) > CM is the only real problem child since we do not want to include the CM > impl bundle everywhere that DS impl is needed. So the final issue is DS impl need cm package? Why not put cm package in DS impl and also export/import the package (or import with resolution:=optional)? Then DS will either import the package or just use the contained version. Remember to import wide since the DS impl bundle does not actually implement CM.
(In reply to comment #8) > org.osgi.service.component > Move to org.eclipse.equinox.ds impl bundle > > org.osgi.service.component.annotations > Do not ship, no need for these at runtime How can we make the annotations available at development in PDE? Currently, I'm able by including a bundle from an Equinox p2 repo in my target definition and that's it. If they are not available in the repo, there must be something else. I'm afraid anything else sounds like complicating the workflow which doesn't help with OSGi adoption/learning curve. (In reply to comment #10) > > org.osgi.service.http > > Move to new org.eclipse.equinox.service.http bundle > Move to org.eclipse.equinox.http impl bundle (impl bundle should contain > the pkg also) > [Not sure which bundle since there are many of them. Perhaps all of > them?] So every service implementation should also ship the API as well? Does the OSGi best practice really recommends duplicating source code just for the sake of reducing the number of bundles in a system? Doesn't that contradict the re-use aspect of modularity? FWIW, I also implement the HTTP service spec and we have also plans for providing an alternative implementation of CM. However, I am not interested in maintaining and synchronizing the source of the services API myself. This would be a manual task that must be document and is prone to errors. What if one team decided to update the API in their bundle but the other team has no plans yet and both are participating in the release train? Or even worse, one (potentially less experienced) team does an update but doesn't get the OSGi metadata right? That sounds like an interesting event for the release train repo. The current approach (by having a dedicated API bundles maintained within the Equinox project) avoids some mistakes _by design_. I really appreciate the work done by the OSGi experts.
(In reply to comment #17) > (In reply to comment #8) > > org.osgi.service.component > > Move to org.eclipse.equinox.ds impl bundle > > > > org.osgi.service.component.annotations > > Do not ship, no need for these at runtime > > How can we make the annotations available at development in PDE? > > Currently, I'm able by including a bundle from an Equinox p2 repo in my > target definition and that's it. If they are not available in the repo, > there must be something else. I'm afraid anything else sounds like > complicating the workflow which doesn't help with OSGi adoption/learning > curve. > You need to put the annotations jar on your project's class path. Since it is not a runtime package, it is inappropriate to model it as a runtime package (export/import). In the framework project, we have the annotations jar in the repo and reference it. > (In reply to comment #10) > > > org.osgi.service.http > > > Move to new org.eclipse.equinox.service.http bundle > > Move to org.eclipse.equinox.http impl bundle (impl bundle should contain > > the pkg also) > > [Not sure which bundle since there are many of them. Perhaps all of > > them?] > > So every service implementation should also ship the API as well? Does the > OSGi best practice really recommends duplicating source code just for the > sake of reducing the number of bundles in a system? Doesn't that contradict > the re-use aspect of modularity? > I am sorry but how many implementations are we talking about here? A very small number and each of them carrying the API package for the API it provides is a small price to pay to avoid a dependency on some other bundle holding the API package. > FWIW, I also implement the HTTP service spec and we have also plans for > providing an alternative implementation of CM. However, I am not interested > in maintaining and synchronizing the source of the services API myself. This > would be a manual task that must be document and is prone to errors. Really? That seems overly dramatic. Your implementation provides a specific version of the API. So your implementation carrying its own copy of the API package is the least of the burdens you would have in providing your implementation. Experience has shown that having non-cohesive API bundles (e.g. osgi.cmpn.jar or org.eclipse.osgi.services) at runtime creates problems. If a bundle wants to provide an implementation of a different version of the service than contained in the non-cohesive bundle, it then drags in another non-cohesive bundle. So the solution is either small API bundles (one API package per bundle) or each implementation also carries the API package for the API it provides. The latter is fine tradeoff between minimizing dependencies between bundles and having too many bundles. The small duplication of API packages in a system only occurs when a system has multiple version of the implementation anyway in which case you need multiple versions of the API package. Note: I am not saying each API consumer must have its own copy of the package. Just each API provider. > > What if one team decided to update the API in their bundle but the other > team has no plans yet and both are participating in the release train? Again, how many API providers are we talking about? How many CM implementations there in Eclipse? > Or > even worse, one (potentially less experienced) team does an update but > doesn't get the OSGi metadata right? That sounds like an interesting event > for the release train repo. The current approach (by having a dedicated API > bundles maintained within the Equinox project) avoids some mistakes _by > design_. I really appreciate the work done by the OSGi experts. The OSGi experts recommend against having such non-cohesive API bundles. :-)
(In reply to comment #18) > You need to put the annotations jar on your project's class path. Since it > is not a runtime package, it is inappropriate to model it as a runtime > package (export/import). In the framework project, we have the annotations > jar in the repo and reference it. Eclipse PDE tooling provides a classpath container that constructs the project classpath based on metadata of the runtime model. That's a convenient development model for people. Elements on the classpath must be bundles and can be consumed from various locations using a target platform. Those locations are typically repositories (p2, OBR) providing runtime artifacts. Bndtools is similar but (AFAIK) does allow for some more flexibility here. What you are proposing makes the life of developers more complicated. Instead of consuming packages from well established channels (eg., Equinox Target Components) they are now required to clone a Git repo with tons of other stuff just to consume one package? I'm sorry, but that's doesn't sound pragmatic/user friendly to me. It might be possible to modify to tooling. But the proposal discussed here does not include/sponsor such work. Please continue providing the package in some bundle that can be consumed within a target platform. > The OSGi experts recommend against having such non-cohesive API bundles. :-) Well, that looks like the decision is made already. Anyway, just wanted to raise my concerns. They might be irrelevant given the small number of implementations, though.
http://dev.eclipse.org/mhonarc/lists/eclipse-dev/msg09598.html and the summary talk about removing the whole 'org.eclipse.osgi.services' bundle, but comment 0 talks about converting it into a "normal" bundle and (re-)remove 'org.osgi.service.io' from it. Can someone clarify?
(In reply to comment #20) > http://dev.eclipse.org/mhonarc/lists/eclipse-dev/msg09598.html and the > summary talk about removing the whole 'org.eclipse.osgi.services' bundle, > but comment 0 talks about converting it into a "normal" bundle and > (re-)remove 'org.osgi.service.io' from it. Can someone clarify? Comment 0 was Tom's initial position which I argued against in later comments.
(In reply to comment #19) > Eclipse PDE tooling provides a classpath container that constructs the > project classpath based on metadata of the runtime model. That's a > convenient development model for people. Elements on the classpath must be > bundles and can be consumed from various locations using a target platform. > Those locations are typically repositories (p2, OBR) providing runtime > artifacts. Bndtools is similar but (AFAIK) does allow for some more > flexibility here. > > What you are proposing makes the life of developers more complicated. > Instead of consuming packages from well established channels (eg., Equinox > Target Components) they are now required to clone a Git repo with tons of > other stuff just to consume one package? I'm sorry, but that's doesn't sound > pragmatic/user friendly to me. > > It might be possible to modify to tooling. But the proposal discussed here > does not include/sponsor such work. > > Please continue providing the package in some bundle that can be consumed > within a target platform. This is because PDE uses "manifest-first" where the manifest controls both the compilation class visibility and runtime class visibility. Is it wrong to have these always be identical and is a flaw in "manifest-first" model and thus PDE. Class visibility at compilation can be different (generally wider) than class visibility at runtime. Annotations which are not RUNTIME retention is a prime example. PDE needs to allow for types to be visible at compile time without requiring them to also be visible at runtime. It is wrong to require bundles containing classes which use such annotations to have a runtime dependency on the annotation's package. It is even more wrong to do this just because of a limitation in the tooling. I am all for a change to PDE to support this. But, in the interim, I do not support exporting the annotation package just to make PDE work since in order for PDE to give bundles visibility to the annotation package, the bundles must import the package in their manifest which will then also improperly import the package at runtime.
(In reply to comment #22) > > I am all for a change to PDE to support this. But, in the interim, I do not > support exporting the annotation package just to make PDE work since in > order for PDE to give bundles visibility to the annotation package, the > bundles must import the package in their manifest which will then also > improperly import the package at runtime. AFAIK PDE supports "Extra Classpath Entries" on the Build tab in the PDE editor, specifically so that compile time jars can be added. But the compile time annotations will still need to be delivered, probably via p2 (for PDE target platforms and for maven/tycho). And consumed (it currently seems to take jars from the workspace). Before removing the annotations, then, someone better negotiate with PDE to make sure they can support it. PW
(In reply to comment #23) > AFAIK PDE supports "Extra Classpath Entries" on the Build tab in the PDE > editor, specifically so that compile time jars can be added. Yes, it does and CBI supports the same, but understanding the build.properties jars.extra.classpath setting. I also think this only supports paths that are relative to your project folder (workspace). > > But the compile time annotations will still need to be delivered, probably > via p2 (for PDE target platforms and for maven/tycho). And consumed (it > currently seems to take jars from the workspace). Before removing the > annotations, then, someone better negotiate with PDE to make sure they can > support it. > > PW Does PDE DS tooling currently support the DS annotations? If not then I don't see the issue with removing these annotations.
(In reply to comment #24) > Does PDE DS tooling currently support the DS annotations? If not then I > don't see the issue with removing these annotations. There is an extension for PDE that supports this: https://github.com/ecliptical/ds-annotations There's also a request open to integrate that support into PDE (bug 376950).
(In reply to comment #24) > Yes, it does and CBI supports the same, but understanding the > build.properties jars.extra.classpath setting. I also think this only > supports paths that are relative to your project folder (workspace). The UI offers jars from the workspace, but the extra classpath entries are specified as plug-in paths (platform:/plugin/org.apache.ant/lib/ant.jar). This means you can specify any plug-in in your target platform. Paul's comment is correct, we would still need a way to deliver the annotations to the target platform (via p2 repo most likely). (In reply to comment #25) > There is an extension for PDE that supports this: > https://github.com/ecliptical/ds-annotations > > There's also a request open to integrate that support into PDE (bug 376950). We haven't made a decision on whether to integrate the annotations support into PDE. Mostly because of concerns over ongoing support, though it will take a non-trivial amount of time to do the integration as well.
After reading through this bug, I'm still not sure I fully understand what the agreed upon outcome is... However, relating back to Tom's email in comment 20, I would fully +1 any breaking change if it means moving more towards best practices. (IMO) Eclipse is the reference example of the OSGi specification (if there is such a thing), and every effort should be made to "practice what we preach". This is not to say any breaking change should be taken lightly under the guise of best practices, it would have to be well thought out. But most developers I know (including me) have looked to the workbench for examples when initially trying to learn/figure out OSGi. Not too sure how this would jive with [1], but Eclipse 5 seems like a long ways off.. JD [1] http://wiki.eclipse.org/Version_Numbering
(In reply to comment #27) > After reading through this bug, I'm still not sure I fully understand what > the agreed upon outcome is... > Nothing has been agreed to as of yet. I will bring this issue forward to eclipse leadership. From my point of view, this is a breaking change, but one that will break folks that are really doing something they should not be (requiring org.eclipse.osgi.services as a bundle). The org.eclipse.osgi.services bundle has a mixed bag of unrelated packages. No bundle should ever need to have every package the services bundle exports. Import-Package is the best approach to obtaining the org.osgi.service packages. If this turns out to be a big issue for things like RCP then I will have to revert back to my original proposal of removing the org.osgi.services.io package so I can get a sane build. Even doing that is considered a breaking change (but a should be to a much lesser degree).
Progress update. I have released the changes to org.eclipse.osgi.services and org.eclipse.osgi.util to be built like normal bundles instead of the hacky way we used constructed them from pre-built osgi classes. As stated in comment 0, this required me to move the org.osgi.service.io package to org.eclipse.equinox.io.
Done all I'm going to do for M1. Moving to M2.
Marking as fixed since this is all we are going to do for Luna (build the classes in the osgi.util and osgi.services bundles).
*** Bug 430842 has been marked as a duplicate of this bug. ***
What about removing the services bundle entirely?
(In reply to BJ Hargrave from comment #33) > What about removing the services bundle entirely? Bug 431633 opened. Not happening in Luna.
