Community
Participate
Working Groups
My build started failing with this morning's I build. With these error messages, it seems related to either the javax.servlet changes or the servletbridge.extensionbundle changes. [eclipse.buildScript] Some inter-plug-in dependencies have not been satisfied. [eclipse.buildScript] Bundle org.eclipse.e4.ui.workbench.swt: [eclipse.buildScript] Another singleton version selected: org.eclipse.e4.ui.workbench.swt_0.10.0.v20111203-0150 [eclipse.buildScript] Bundle org.eclipse.ui.workbench.texteditor: [eclipse.buildScript] Another singleton version selected: org.eclipse.ui.workbench.texteditor_3.7.100.v20111115-0800 [eclipse.buildScript] Bundle org.eclipse.jdt.core.manipulation: [eclipse.buildScript] Another singleton version selected: org.eclipse.jdt.core.manipulation_1.5.0.v20111115-0800 [eclipse.buildScript] Bundle org.eclipse.osgi: [eclipse.buildScript] Another singleton version selected: org.eclipse.osgi_3.8.0.v20111111-1618 [eclipse.buildScript] Bundle org.eclipse.xtext.junit4: [eclipse.buildScript] Package uses conflict: Require-Bundle: org.eclipse.xtext; bundle-version="2.0.1" [eclipse.buildScript] Bundle org.eclipse.e4.ui.model.workbench: [eclipse.buildScript] Another singleton version selected: org.eclipse.e4.ui.model.workbench_0.10.0.v20111116-1853 [eclipse.buildScript] Bundle org.eclipse.team.ui: [eclipse.buildScript] Another singleton version selected: org.eclipse.team.ui_3.6.200.v20111118-1221 [eclipse.buildScript] Bundle org.eclipse.ui.workbench: [eclipse.buildScript] Another singleton version selected: org.eclipse.ui.workbench_3.103.0.v20111202-1638 [eclipse.buildScript] Bundle org.eclipse.ltk.core.refactoring: [eclipse.buildScript] Another singleton version selected: org.eclipse.ltk.core.refactoring_3.6.0.v20111115-0800 [eclipse.buildScript] Bundle org.eclipse.equinox.servletbridge.extensionbundle: [eclipse.buildScript] Bundle org.slf4j.api: [eclipse.buildScript] Host plug-in org.slf4j.impl.StaticLoggerBinder_0.0.0 has not been found. [eclipse.buildScript] Bundle org.eclipse.debug.core: [eclipse.buildScript] Another singleton version selected: org.eclipse.debug.core_3.7.100.v20111115-2020 [eclipse.buildScript] Bundle org.eclipse.compare: [eclipse.buildScript] Another singleton version selected: org.eclipse.compare_3.5.300.v20111123-1704 [eclipse.buildScript] Bundle org.eclipse.e4.core.services: [eclipse.buildScript] Another singleton version selected: org.eclipse.e4.core.services_1.0.0.v20111116-1503 [eclipse.buildScript] Bundle org.eclipse.debug.ui: [eclipse.buildScript] Another singleton version selected: org.eclipse.debug.ui_3.8.0.v20111201-2228 [eclipse.buildScript] Bundle org.eclipse.equinox.preferences: [eclipse.buildScript] Another singleton version selected: org.eclipse.equinox.preferences_3.4.100.v20111129-1548 [eclipse.buildScript] Bundle org.eclipse.ui.ide: [eclipse.buildScript] Another singleton version selected: org.eclipse.ui.ide_3.8.0.v20111125-1517 [eclipse.buildScript] Bundle org.eclipse.search: [eclipse.buildScript] Another singleton version selected: org.eclipse.search_3.7.100.v20111115-0800 [eclipse.buildScript] Bundle org.eclipse.ui.views: [eclipse.buildScript] Another singleton version selected: org.eclipse.ui.views_3.6.100.v20111104-1110 [eclipse.buildScript] Bundle org.eclipse.core.variables: [eclipse.buildScript] Another singleton version selected: org.eclipse.core.variables_3.2.600.v20111006-1618 [eclipse.buildScript] Bundle org.eclipse.core.resources: [eclipse.buildScript] Another singleton version selected: org.eclipse.core.resources_3.8.0.v20111129-1553 [eclipse.buildScript] Bundle org.eclipse.swt: [eclipse.buildScript] Another singleton version selected: org.eclipse.swt_3.8.0.v3813 [eclipse.buildScript] Unsatisfied import package org.eclipse.swt.accessibility2_0.0.0. [eclipse.buildScript] Unsatisfied import package org.mozilla.xpcom_0.0.0. [eclipse.buildScript] Bundle org.eclipse.e4.ui.css.core: [eclipse.buildScript] Another singleton version selected: org.eclipse.e4.ui.css.core_0.10.0.v20111205-0214 [eclipse.buildScript] Bundle org.eclipse.e4.ui.workbench.renderers.swt: [eclipse.buildScript] Another singleton version selected: org.eclipse.e4.ui.workbench.renderers.swt_0.10.0.v20111201-1641 [eclipse.buildScript] Bundle org.eclipse.e4.ui.css.swt.theme: [eclipse.buildScript] Another singleton version selected: org.eclipse.e4.ui.css.swt.theme_0.9.1.v20111205-0214 [eclipse.buildScript] Bundle org.eclipse.core.filesystem: [eclipse.buildScript] Another singleton version selected: org.eclipse.core.filesystem_1.3.200.v20111018-1451 [eclipse.buildScript] Bundle org.eclipse.core.filebuffers: [eclipse.buildScript] Another singleton version selected: org.eclipse.core.filebuffers_3.5.200.v20111115-0800 [eclipse.buildScript] Bundle org.eclipse.e4.ui.css.swt: [eclipse.buildScript] Another singleton version selected: org.eclipse.e4.ui.css.swt_0.10.0.v20111129-0439 [eclipse.buildScript] Bundle org.eclipse.jdt.core: [eclipse.buildScript] Another singleton version selected: org.eclipse.jdt.core_3.8.1.v20111202-0539 [eclipse.buildScript] Bundle org.eclipse.team.core: [eclipse.buildScript] Another singleton version selected: org.eclipse.team.core_3.6.100.v20111123-1649 [eclipse.buildScript] Bundle org.eclipse.ui.editors: [eclipse.buildScript] Another singleton version selected: org.eclipse.ui.editors_3.8.0.v20111115-0800 [eclipse.buildScript] Bundle org.eclipse.equinox.p2.metadata: [eclipse.buildScript] Another singleton version selected: org.eclipse.equinox.p2.metadata_2.1.0.v20111114-0441 [eclipse.buildScript] Bundle org.eclipse.ui: [eclipse.buildScript] Another singleton version selected: org.eclipse.ui_3.102.0.v20111115-1903 [eclipse.buildScript] Bundle org.eclipse.e4.ui.workbench: [eclipse.buildScript] Another singleton version selected: org.eclipse.e4.ui.workbench_0.10.1.v20111203-0150 [eclipse.buildScript] Bundle ch.qos.logback.slf4j: [eclipse.buildScript] Package uses conflict: Import-Package: ch.qos.logback.classic; version="0.9.19" [eclipse.buildScript] Host plug-in org.slf4j.api_[1.5.11,1.6.0) has not been found. [eclipse.buildScript] Bundle org.eclipse.jdt.ui: [eclipse.buildScript] Another singleton version selected: org.eclipse.jdt.ui_3.8.0.v20111201-2023 [eclipse.buildScript] Bundle org.eclipse.ltk.ui.refactoring: [eclipse.buildScript] Another singleton version selected: org.eclipse.ltk.ui.refactoring_3.7.0.v20111115-0800 [eclipse.buildScript] Bundle org.eclipse.e4.core.deeplink.handler: [eclipse.buildScript] Package uses conflict: Require-Bundle: org.eclipse.osgi.services; bundle-version="3.1.200" [eclipse.buildScript] Package uses conflict: Require-Bundle: org.mortbay.jetty.server; bundle-version="0.0.0" [eclipse.buildScript] Bundle org.eclipse.e4.pde.webui: [eclipse.buildScript] Package uses conflict: Import-Package: org.osgi.service.http; version="1.2.1" [eclipse.buildScript] Bundle org.eclipse.e4.pde.ui: [eclipse.buildScript] Missing required plug-in org.eclipse.e4.pde.webui_0.9.0. [eclipse.buildScript] Bundle org.eclipse.e4.ui.deeplink.typehandler.perspective: [eclipse.buildScript] Missing required plug-in org.eclipse.e4.core.deeplink.handler_0.0.0. [eclipse.buildScript] Bundle org.eclipse.e4.core.deeplink.typehandler.extensionpt: [eclipse.buildScript] Missing required plug-in org.eclipse.e4.core.deeplink.handler_0.0.0.
I'm checking my bundles for upper bounds just to be sure. Is there some other migration I must make to move to the latest 3.8 I build as a base? PW
If I take my webui bundle (which has less dependencies) I see an import package statement: Import-Package: org.eclipse.equinox.http.jetty;version="1.1.0", org.osgi.service.http;version="1.2.1" Somehow against my runnable repo, that's generating: [eclipse.buildScript] Bundle org.eclipse.e4.pde.webui: [eclipse.buildScript] Package uses conflict: Import-Package: org.osgi.service.http; version="1.2.1" osgi.enterprise 4.2.0.v201108120515 also appears to export that package. PW
It says the osgi.enterprise came from Eclipse Orbit, "OSGi Service Platform Release 4 Version 4.2, Enterprise Interfaces and Classes for use in compiling bundles." PW
osgi.enterprise_4.2.0.v201108120515.jar was included in juno 201111110900 (M3, I guess) But it hasn't been a problem until this weekend ... Tom, did the changes bump up any of the packages we provide in this area? PW
I'm assuming you don't actually need or want osgi.enterprise? It does import and export org.osgi.service.http (and, it is an optional import). If I had to guess ... and just a guess ... this might be related to the fact that Orbit still used "old" repo publisher that by default leaves optional=true greedy=true. How do you specify you orbit map files? If you just copy/paste whole p2 orbit map file (as I know some do), you might have some luck editing that map file, and leaving out osgi.enterprise?
Oh, and maybe the obvious ... I'm assuming you (and Platform) have both moved to the latest M4 Orbit S build? http://download.eclipse.org/tools/orbit/downloads/drops/S20111201180206/orbitBundles-S20111201180206.p2.map That likely needs to be coordinated.
Is this going to cause others problems, that 2 bundles in Juno M4 export the same package/same version? All it took was an Import-Package to trigger this. org.eclipse.osgi.services is a singleton, although osgi.enterprise is not.
(In reply to comment #7) > Is this going to cause others problems, that 2 bundles in Juno M4 export the > same package/same version? All it took was an Import-Package to trigger this. > > org.eclipse.osgi.services is a singleton, although osgi.enterprise is not. I don't understand why this is causing such a problem. Both bundles use substitutable exports so in the end only one exporter should be chosen as THE exporter at runtime. (In reply to comment #2) > If I take my webui bundle (which has less dependencies) I see an import package > statement: > > Import-Package: org.eclipse.equinox.http.jetty;version="1.1.0", > org.osgi.service.http;version="1.2.1" > > Somehow against my runnable repo, that's generating: > [eclipse.buildScript] Bundle org.eclipse.e4.pde.webui: > [eclipse.buildScript] Package uses conflict: Import-Package: > org.osgi.service.http; version="1.2.1" > > > osgi.enterprise 4.2.0.v201108120515 also appears to export that package. > > PW Is it possible you are picking up both versions of javax.servlet (one that exports 2.6 and one that exports 3.0)? Perhaps it is possible two of the bundles involved in the class space inconsistency are getting wired to two different javax.servlet exporters.
I've added a remove for the offending IU in my customTargets.xml: <p2.remove.iu> <repository location="file:${repoBaseLocation}/xtext" /> <iu id="osgi.enterprise" /> </p2.remove.iu> That was enough to allow my build to proceed, I think (at least past the part it stalled before). I've also updated my Orbit to point to S20111201180206. We suspect it's the javax.servlet packages in my repos, some at 2.6 and some at 3.0 that's causing the surprise. But given that juno will provide both M3 and M4 (with the bad package def and the good package def) will this continue to happen? PW
(In reply to comment #9) > But given that juno will provide both M3 and M4 (with the bad package def and > the good package def) will this continue to happen? What is the retention rate for the juno repo for milestones? Is it (M-1 to M). So for M4 will it have M3 and M4 content? or does it have M1 through M4? We may have to consider purging the repo to contain only M4 since we are downgrading a package version. in M4.
(In reply to comment #10) > (In reply to comment #9) > > But given that juno will provide both M3 and M4 (with the bad package def and > > the good package def) will this continue to happen? > > What is the retention rate for the juno repo for milestones? Is it (M-1 to M). > So for M4 will it have M3 and M4 content? or does it have M1 through M4? We > may have to consider purging the repo to contain only M4 since we are > downgrading a package version. in M4. Normally, by policy, we have M-2 to M, for 3 total ... but, yes, when there is a problem doing that due to down leveling of a feature, or something, we have been known to have just one. Since Orbit bundles (e.g. javax.servlet) should be contributed by project features, I'd be a little surprised if it'd be an issue ... but a) I have not thought it through :) and b) glad to be accommodating ... we'll just announce on cross-project list once we confirm it is a problem.
> ... I'd be a little surprised if it'd be an issue > ... but a) I have not thought it through :) Now that I've thought it though, it would not be an issue if everyone _consumed_ javax.servlet via features ... but, I doubt that would be the case ... I suspect there are some "optional" cases, and ... since most repos, I'm sure, would still be publishing "optional" as "greedy=true" then yes, those cases would "pick up" version 3.0 packages ... so ... let's plan now to have M4 be only M4. I'll announce on cross-project.
(In reply to comment #12) > > ... I'd be a little surprised if it'd be an issue > > ... but a) I have not thought it through :) > > Now that I've thought it though, it would not be an issue if everyone > _consumed_ javax.servlet via features ... but, I doubt that would be the case > ... I suspect there are some "optional" cases, and ... since most repos, I'm > sure, would still be publishing "optional" as "greedy=true" then yes, those > cases would "pick up" version 3.0 packages ... so ... let's plan now to have M4 > be only M4. I'll announce on cross-project. +1, I was going to make a similar comment. Thanks Dave.
M7 build available, I think this one can be closed.
