Community
Participate
Working Groups
I have a very simple project 1. Plugin 1. Required bundle dependency (org.eclipse.equinox.http.registry) 1. Import package (javax.servlet) and when I build I get the following: [ERROR] -> [Help 1] org.apache.maven.InternalErrorException: Internal error: java.lang.RuntimeException: org.osgi.framework.BundleException: Bundle org.example cannot be resolved Resolution errors: Bundle org.example - Missing Constraint: Import-Package: javax.servlet; version="2.3.0" I've shared the simple project on github [1]. [1] https://github.com/irbull/tycho_sample 1. git clone https://github.com/irbull/tycho_sample 2. cd tycho_sample 3. mvn clean install
Also, I've tried removing the version constraints and it didn't help. If I add the bundle (javax.servlet) to the required bundles, then it builds fine -- although it doesn't work because I really need an import package here.
I can reproduce exactly the same bug, but never found time to create a small reproducible test case, thanks Ian :) FWIW, Paul W. had the same issue but it somehow automatically got fixed switching from Tycho 0.10.0 to 0.11.0 ; see https://issues.sonatype.org/browse/TYCHO-602
I saw Paul's bug and it gave me hope, but in the end I couldn't get it working with any version of Tycho. It seems the Riena guys are also having the same problem (last comment). Paul does use the famous "makeWorkForPaul" flag, so maybe that's it ;-). In all seriousness, it appears that the choice of requiredBundles affects this. For example, if I change which bundles I require, I can get things to build. So there is a chance that this bug is slightly different than Tycho-602.
Can this possibly be a p2 bug??? Running the build with "-X -Dtycho.debug.resolver=org.example" tells Tycho to dump intermediate p2 resolution state , i.e. all available IUs, sliced set and resolved results, for org.example project. From the log it appears that javax.servlet 2.5.0.v201103041518 bundle is selected by the slicer as expected, but then dropped by the projector. @Ian can you help us troubleshoot this from p2 end? Any other comments you may have about Tycho use of P2 will also be very welcome. I can provide standalone p2 test case similar to what I attached to Bug 326624 if you don't want to dive into Tycho code just yet ;-) Tycho resolver code in question is https://github.com/sonatype/sonatype-tycho/blob/master/tycho-p2-resolver/tycho-p2-resolver-impl/org.eclipse.tycho.p2.resolver.impl/src/main/java/org/eclipse/tycho/p2/impl/resolver/ProjectorResolutionStrategy.java Below is the relevant part of debug log output [INFO] Root IUs: <?xml version='1.0' encoding='UTF-8'?> <units size='1'> <unit id='org.example' version='1.0.0.qualifier' singleton='false'> <update id='org.example' range='[0.0.0,1.0.0.qualifier)' severity='0'/> <properties size='4'> <property name='org.eclipse.equinox.p2.name' value='Example'/> <property name='maven-groupId' value='org.example'/> <property name='maven-artifactId' value='org.example'/> <property name='maven-version' value='1.0.0-SNAPSHOT'/> </properties> <provides size='3'> <provided namespace='org.eclipse.equinox.p2.iu' name='org.example' version='1.0.0.qualifier'/> <provided namespace='osgi.bundle' name='org.example' version='1.0.0.qualifier'/> <provided namespace='org.eclipse.equinox.p2.eclipse.type' name='bundle' version='1.0.0'/> </provides> <requires size='2'> <required namespace='osgi.bundle' name='org.eclipse.equinox.http.registry' range='1.1.100'/> <required namespace='java.package' name='javax.servlet' range='2.3.0'/> </requires> <artifacts size='1'> <artifact classifier='osgi.bundle' id='org.example' version='1.0.0.qualifier'/> </artifacts> <touchpoint id='org.eclipse.equinox.p2.osgi' version='1.0.0'/> <touchpointData size='1'> <instructions size='2'> <instruction key='manifest'> Bundle-ManifestVersion: 2
Import-Package: javax.servlet;version="2.3.0"
Bundle-Version: 1.0.0.qualifier
Require-Bundle: org.eclipse.equinox.http.registry;bundle-version="1.1.100"
Manifest-Version: 1.0
Bundle-SymbolicName: org.example
Bundle-Name: Example
Bundle-RequiredExecutionEnvironment: JavaSE-1.6
 </instruction> <instruction key='zipped'> true </instruction> </instructions> </touchpointData> </unit> </units> [INFO] Extra IUs: <?xml version='1.0' encoding='UTF-8'?> <units size='1'> <unit id='org.example' version='1.0.0.qualifier' singleton='false'> <update id='org.example' range='[0.0.0,1.0.0.qualifier)' severity='0'/> <properties size='4'> <property name='org.eclipse.equinox.p2.name' value='Example'/> <property name='maven-groupId' value='org.example'/> <property name='maven-artifactId' value='org.example'/> <property name='maven-version' value='1.0.0-SNAPSHOT'/> </properties> <provides size='3'> <provided namespace='org.eclipse.equinox.p2.iu' name='org.example' version='1.0.0.qualifier'/> <provided namespace='osgi.bundle' name='org.example' version='1.0.0.qualifier'/> <provided namespace='org.eclipse.equinox.p2.eclipse.type' name='bundle' version='1.0.0'/> </provides> <requires size='2'> <required namespace='osgi.bundle' name='org.eclipse.equinox.http.registry' range='1.1.100'/> <required namespace='java.package' name='javax.servlet' range='2.3.0'/> </requires> <artifacts size='1'> <artifact classifier='osgi.bundle' id='org.example' version='1.0.0.qualifier'/> </artifacts> <touchpoint id='org.eclipse.equinox.p2.osgi' version='1.0.0'/> <touchpointData size='1'> <instructions size='2'> <instruction key='manifest'> Bundle-ManifestVersion: 2
Import-Package: javax.servlet;version="2.3.0"
Bundle-Version: 1.0.0.qualifier
Require-Bundle: org.eclipse.equinox.http.registry;bundle-version="1.1.100"
Manifest-Version: 1.0
Bundle-SymbolicName: org.example
Bundle-Name: Example
Bundle-RequiredExecutionEnvironment: JavaSE-1.6
 </instruction> <instruction key='zipped'> true </instruction> </instructions> </touchpointData> </unit> </units> [INFO] Slice: org.eclipse.equinox.log 1.2.200.v20110502 org.eclipse.equinox.util 1.0.300.v20110502 org.eclipse.equinox.registry 3.5.100.v20110502 org.eclipse.osgi.services 3.3.0.v20110110 org.eclipse.equinox.log 1.2.200.v20110314 org.eclipse.osgi.services 3.3.0.v20101018 org.eclipse.equinox.registry 3.5.100.v20101101 org.eclipse.core.jobs 3.5.100.v20110214 org.eclipse.equinox.servletbridge.extensionbundle 1.2.0.v20100503 org.eclipse.equinox.registry 3.5.0.v20100503 javax.servlet 2.5.0.v201012071420 org.eclipse.equinox.supplement 1.4.0.v20110411 org.eclipse.osgi.services 3.2.100.v20100503 org.eclipse.equinox.supplement 1.4.0.v20101022 org.eclipse.osgi 3.7.0.v20110511 org.eclipse.osgi 3.7.0.v20101022 org.eclipse.equinox.http.registry 1.1.100.v20101101 org.eclipse.osgi 3.7.0.v20110513 org.eclipse.equinox.common 3.6.0.v20110506 org.eclipse.equinox.registry 3.5.100.v20110207 org.eclipse.equinox.registry 3.5.100.v20101018 org.eclipse.core.jobs 3.5.100.v20100823 javax.servlet 2.5.0.v201103041518 org.eclipse.equinox.io 1.0.300.v20101204 org.eclipse.osgi.services 3.3.0.v20110411 org.eclipse.core.jobs 3.5.0.v20100515 org.eclipse.equinox.supplement 1.3.100.v20100910 org.eclipse.osgi 3.7.0.v20110524 org.eclipse.equinox.common 3.6.0.v20100503 org.eclipse.osgi 3.7.0.v20110427 org.eclipse.equinox.log 1.2.200.v20101204 org.eclipse.equinox.io 1.0.300.v20110502 org.eclipse.osgi 3.7.0.v20110124-0830 org.example 1.0.0.qualifier javax.servlet 2.5.0.v200910301333 org.eclipse.equinox.log 1.2.100.v20100503 org.eclipse.osgi 3.6.100.v20100730 org.eclipse.equinox.http.registry 1.1.100.v20110502 org.eclipse.osgi 3.7.0.v20100910 org.eclipse.equinox.common 3.6.0.v20110523 org.eclipse.core.jobs 3.5.100.v20110404 org.eclipse.equinox.io 1.0.200.v20100503 org.eclipse.osgi.services 3.3.0.v20110513 org.eclipse.equinox.common 3.6.0.v20110110 org.eclipse.equinox.common 3.6.0.v20110427 org.eclipse.equinox.registry 3.5.100.v20110321 org.eclipse.equinox.supplement 1.3.100.v20100730 org.eclipse.osgi 3.7.0.v20101207 org.eclipse.osgi 3.7.0.v20110304 a.jre.javase 1.6.0 org.eclipse.equinox.supplement 1.4.0.v20110502 javax.servlet 2.4.0.v200806031604 org.eclipse.equinox.supplement 1.4.0.v20101115 org.eclipse.equinox.log 1.2.200.v20110110 org.eclipse.equinox.supplement 1.4.0.v20110110 org.eclipse.equinox.util 1.0.200.v20100503 org.eclipse.core.jobs 3.5.100.v20101008 [INFO] Resolved IUs: org.eclipse.equinox.common 3.6.0.v20110523 org.eclipse.osgi 3.7.0.v20110524 org.eclipse.core.jobs 3.5.100.v20110404 org.eclipse.osgi.services 3.3.0.v20110513 org.eclipse.equinox.registry 3.5.100.v20110502 org.eclipse.equinox.servletbridge.extensionbundle 1.2.0.v20100503 org.eclipse.equinox.http.registry 1.1.100.v20110502 a.jre.javase 1.6.0 org.example 1.0.0.qualifier
(In reply to comment #4) > Can this possibly be a p2 bug??? > It could very well be a p2 bug. Pascal thought that too. > > Running the build with "-X -Dtycho.debug.resolver=org.example" tells Tycho to > dump intermediate p2 resolution state , i.e. all available IUs, sliced set and > resolved results, for org.example project. From the log it appears that > javax.servlet 2.5.0.v201103041518 bundle is selected by the slicer as expected, > but then dropped by the projector. > > @Ian can you help us troubleshoot this from p2 end? Any other comments you may > have about Tycho use of P2 will also be very welcome. I can provide standalone > p2 test case similar to what I attached to Bug 326624 if you don't want to dive > into Tycho code just yet ;-) Yep, I'd be happy to help figure this one out. Let me look at the debug output you have and see if I can make heads-or-tails of this.
I spent some more time on this. The projector actually correctly resolves the problem and but picks org.eclipse.equinox.servletbridge.extensionbundle 1.2.0.v20100503 as the provider of javax.servlet, see IU below. <unit id='org.eclipse.equinox.servletbridge.extensionbundle' version='1.2.0.v20100503' singleton='false'> <update id='org.eclipse.equinox.servletbridge.extensionbundle' range='[0.0.0,1.2.0.v20100503)' severity='0'/> <properties size='1'> <property name='org.eclipse.equinox.p2.name' value='Servletbridge Extension bundle'/> </properties> <provides size='8'> <provided namespace='org.eclipse.equinox.p2.eclipse.type' name='bundle' version='1.0.0'/> <provided namespace='java.package' name='javax.servlet' version='2.5.0'/> <provided namespace='java.package' name='org.eclipse.equinox.servletbridge' version='1.1.0'/> <provided namespace='java.package' name='javax.servlet.http' version='2.5.0'/> <provided namespace='java.package' name='javax.servlet.resources' version='2.5.0'/> <provided namespace='osgi.fragment' name='org.eclipse.osgi' version='1.2.0.v20100503'/> <provided namespace='org.eclipse.equinox.p2.iu' name='org.eclipse.equinox.servletbridge.extensionbundle' version='1.2.0.v20100503'/> <provided namespace='osgi.bundle' name='org.eclipse.equinox.servletbridge.extensionbundle' version='1.2.0.v20100503'/> </provides> <requires size='1'> <required namespace='osgi.bundle' name='org.eclipse.osgi' range='0.0.0'/> </requires> <artifacts size='1'> <artifact classifier='osgi.bundle' id='org.eclipse.equinox.servletbridge.extensionbundle' version='1.2.0.v20100503'/> </artifacts> <touchpoint id='org.eclipse.equinox.p2.osgi' version='1.0.0'/> <touchpointData size='1'> <instructions size='1'> <instruction key='manifest'> Bundle-ManifestVersion: 2
X-Deploy-Export-Package: javax.servlet;version="2.5",javax.servlet.http;version ="2.5",javax.servlet.resources;version="2.5",org.eclipse.equinox.servletbridge;version="1.1"
Bundle-Version: 1.2.0.v20100503
Manifest-Version: 1.0
Eclipse-SourceReferences: scm:cvs:pserver:dev.eclipse.org:/cvsroot/rt:org.eclipse.equinox/server-side/bundles/org.eclipse.equinox.servletbridge.extensionbundle;tag=v20100503
Bundle-SymbolicName: org.eclipse.equinox.servletbridge.extensionbundle
Bundle-Name: Servletbridge Extension bundle
Fragment-Host: system.bundle; extension:=framework </instruction> </instructions> </touchpointData> </unit> This IU, however, does not match the bundle manifest (see below). The tool that generated the IU seems to confuse X-Deploy-Export-Package with Export-Package or wrong provided capabilities were introduced via p2.inf. Either way, this is not a Tycho bug, but I'll keep this bugzilla open until we find where the wrong p2 metadata comes from. Manifest-Version: 1.0 Fragment-Host: system.bundle; extension:=framework Bundle-Name: Servletbridge Extension bundle Bundle-SymbolicName: org.eclipse.equinox.servletbridge.extensionbundle Eclipse-SourceReferences: scm:cvs:pserver:dev.eclipse.org:/cvsroot/rt: org.eclipse.equinox/server-side/bundles/org.eclipse.equinox.servletbr idge.extensionbundle;tag=v20100503 Bundle-Version: 1.2.0.v20100503 Bundle-ManifestVersion: 2 X-Deploy-Export-Package: javax.servlet;version="2.5",javax.servlet.htt p;version ="2.5",javax.servlet.resources;version="2.5",org.eclipse.eq uinox.servletbridge;version="1.1"
org.eclipse.equinox.servletbridge.extensionbundle p2 metadata states that this bundle provides javax.servlet package, even though the bundle does not actually provide this package.
This bundle is used for a special case where we install a p2 managed equinox on an app server and want to expose the servlet api from the underlying servlet container. You can find a few more details on X-Deploy and the p2.inf in bug 291396. I'm not sure what has changed suddenly in terms of resolution as this bundle has not been touched in nearly two years.
(In reply to comment #8) > This bundle is used for a special case where we install a p2 managed equinox on > an app server and want to expose the servlet api from the underlying servlet > container. > > You can find a few more details on X-Deploy and the p2.inf in bug 291396. I'm > not sure what has changed suddenly in terms of resolution as this bundle has > not been touched in nearly two years. I don't think anything has changed here. Instead, I think we are using a target that includes all of the Equinox SDK which includes the serverside feature that has this org.eclipse.equinox.servletbridge.extensionbundle bundle. This is not new, it was also included in the Helios Equinox SDK.
What is expected to stop P2 from picking org.eclipse.equinox.servletbridge.extensionbundle as a provider of javax.servlet package?
(In reply to comment #10) > What is expected to stop P2 from picking > org.eclipse.equinox.servletbridge.extensionbundle as a provider of > javax.servlet package? Actually, nothing should be needed. The raw bundle jar org.eclipse.equinox.servletbridge.extensionbundle does not actually export the javax.servlet packages. The manifest for this bundle has this: X-Deploy-Export-Package: javax.servlet;version="2.5", javax.servlet.http;version ="2.5", javax.servlet.resources;version="2.5", org.eclipse.equinox.servletbridge;version="1.1" It does NOT actually have an Export-Package statement. So perhaps it is a p2 bug that is parsing this header as if it is a real Export-Package. Moving to p2 to clarify and validate this.
(In reply to comment #11) > It does NOT actually have an Export-Package statement. So perhaps it is a p2 > bug that is parsing this header as if it is a real Export-Package. Moving to > p2 to clarify and validate this. This is not a p2 bug. The project has p2.inf file that explicitly adds javax.servlet and few other packages as provided p2 capabilities.
(In reply to comment #12) > This is not a p2 bug. The project has p2.inf file that explicitly adds > javax.servlet and few other packages as provided p2 capabilities. Yes, Igor is right. There is a p2.inf file that explicitly instructs p2 to add the javax.servlet exported package (nothing about X-Deploy) to the IU. I don't think the servletbridge.extension bundle should include this capability if the bundle it represents doesn't actually export this package. (And yes, this IU is in the Indigo repository). This will likely hit anybody who uses tycho to build server side wars against Indigo. It could also hit anybody who put an import package dependency against javax.servlet.
(In reply to comment #13) > I don't think the servletbridge.extension bundle should include this capability > if the bundle it represents doesn't actually export this package. This bundle is a framework extension bundle and at runtime it really does export the javax.servlet api and provides the p2 metadata to prevent another provider of javax.servlet from being downloaded when we're doing runtime provisioning. > > This will likely hit anybody who uses tycho to build server side wars against > Indigo. It could also hit anybody who put an import package dependency against > javax.servlet. This IU is typically a root so if there was a property we could add to the p2.inf to make it less attractive to others I'd be game. Ian, I'm mainly out of the p2 loop so could use a hand. Is there something we could do with greedy, optional, or any new magic p2 metadata properties. maybe something like... require.#.namespace = osgi.bundles require.#.name = org.eclipse.equinox.http.servletbridge <-- generally needed require.#.greedy = false
Similar bugs... bug 276000 bug 306279
Igor, could you please attach to the bug report the snippet necessary to add through a pom.xml a dependency on a p2 IU. Ian currently has a workaround that relies on explicitly adding a dependency on the javax.servlet bundle but this is not really ideal. Also on the tycho side, is there a way that we could flag the case where the extensionbundle is brought in and put out a warning or something so it is easier for ppl to figure out what is going on. Finally to avoid having to do any magic with the extensiond bundle, what would be necessary is to address bug #346174.
(In reply to comment #16) > Igor, could you please attach to the bug report the snippet necessary to add > through a pom.xml a dependency on a p2 IU. Ian currently has a workaround that > relies on explicitly adding a dependency on the javax.servlet bundle but this > is not really ideal. This is not possible using current versions of Tycho. Please open an enhancement request but make sure to elaborate underlying use case and how you want to solve it because I am not sure I fully understand the solution. > > Also on the tycho side, is there a way that we could flag the case where the > extensionbundle is brought in and put out a warning or something so it is > easier for ppl to figure out what is going on. We can't change released versions of Tycho, so this won't help vast majority of existing users. Also, this problem will affect anyone who use P2 to resolve import-package javax.serlvet (and few others), so P2 seems like more appropriate place to hardcode this hack.
*** Bug 355922 has been marked as a duplicate of this bug. ***
*** Bug 357217 has been marked as a duplicate of this bug. ***
Igor closed Bug 357217. JFYI, it contains ziped projects to reproduce the issue.
(In reply to comment #16) > Igor, could you please attach to the bug report the snippet necessary to add > through a pom.xml a dependency on a p2 IU. Ian currently has a workaround that > relies on explicitly adding a dependency on the javax.servlet bundle but this is > not really ideal. Did you try the following to fix your build: - Add an extra compile time dependency to javax.servlet through jars.extra.classpath? - Restrict your target platform by not using all of indigo but only a subset which doesn't include the org.eclipse.equinox.servletbridge.extensionbundle. This is possible by defining the Tycho target platform [1] through a target file with includeMode="slicer". But really the real problem is to have org.eclipse.equinox.servletbridge.extensionbundle generally available in the release train repository. (In reply to comment #14) > (In reply to comment #13) > > This will likely hit anybody who uses tycho to build server side wars against > > Indigo. It could also hit anybody who put an import package dependency against > > javax.servlet. > > This IU is typically a root so if there was a property we could add to the > p2.inf to make it less attractive to others I'd be game. IUs can have a filter condition which prevents them from being used unless their filter evaluates to true. In that way, you could prevent that the extensionbundle is installed in normal installations. Achieving this with p2.inf means [2] could be a bit tricky however. I don't see how it is possible to add a filter to the current IU (note: both IUs and requirements can have filters - here we would need the former). As a workaround you could create an extra IU with an IU filter, and add an unfiltered dependency to the extra IU. This would have the same effect. [1] http://wiki.eclipse.org/Tycho/Target_Platform [2] http://wiki.eclipse.org/Equinox/p2/Customizing_Metadata
(In reply to comment #21) Not sure if this helps or not, but a simple reproduction of this issue can be seen by following this recipe (which targets the helios repo): 1) Download the zip example here: http://software.2206966.n2.nabble.com/attachment/6253726/0/jxservlet.zip 2) unzip and mvn clean package - it works! 3) Add the following line to the end of the MANIFEST.MF: Require-Bundle: org.eclipse.core.runtime 4) mvn clean package - it fails with: Missing Constraint: Import-Package: javax.servlet.http Could it be the case that the presence of the Require-Bundle: is triggering the problem? NOTE: this sample is using the 0.11.0 sonatype version, but it continues to fail with 0.12.0 and 0.13.0 if you update the POM I didn't follow all the discussion above - is there any hope of a workaround? This is killing my ability to generate a war-embedded project.
Created attachment 207649 [details] tycho project that demonstrates issue Attached the zip file mentioned in my previous comment for ease of reference.
(In reply to comment #22) > I didn't follow all the discussion above - is there any hope of a workaround? > This is killing my ability to generate a war-embedded project. Did you read the last comment before yours?
(In reply to comment #24) I did read that comment (though I'm not sure I fully grokked it). I tried what I felt was a similar approach by defining a target platform that specifically un-included the extensionbundle (unchecked in the content pane). My tycho build refers to this target platform definition. The issue persisted with the same presentation. Why is it that adding the Require-Bundle entry to the manifest triggers the problem in the example I posted in comment #22? Although I waited over an hour for the helios p2 site to resolve in the target-platform editor to see for myself - does the helios p2 include that extensionbundle at all? I must admit, the p2 resolution foo seems like black-magic to me. But I don't understand why adding the Require-Bundle triggers the problem in the test example, and how the problem is extensionbundle related if I filtered the extensionbundle from my target platform definition in my actual build and still see the problem. I don't mean to sound as if I'm ranting - just feel I'm spending a disproportionate amount of time trying to get a clean build that works with servletbridge. > (In reply to comment #22) > > I didn't follow all the discussion above - is there any hope of a workaround? > > This is killing my ability to generate a war-embedded project. > Did you read the last comment before yours?
(In reply to comment #25) > (In reply to comment #24) > I tried what > I felt was a similar approach by defining a target platform that specifically > un-included the extensionbundle (unchecked in the content pane). My tycho build > refers to this target platform definition. The issue persisted with the same > presentation. This is not quite the same: the selection on the "content" pane is unfortunately not supported by Tycho - and there is not even a warning about this in the build log (bug 365553). Sorry for that.
BTW, this is all just discussions about workarounds, e.g. in Tycho. I haven't seen any activities from the Equinox team addressing the root cause of the problems (cf. comment #21).
This problem also impedes the RAP project's build. We're also very much interested in a fix.
FYI: Tycho 0.14.0 adds a new target platform filtering syntax [1] that should make it reasonably easy to work around this bug (in the Tycho build). Still, I believe that this bug shall be fixed. [1] http://wiki.eclipse.org/index.php?title=Tycho/Target_Platform#Filtering
(In reply to comment #29) > FYI: Tycho 0.14.0 adds a new target platform filtering syntax [1] that > should make it reasonably easy to work around this bug (in the Tycho build). > Still, I believe that this bug shall be fixed. > > [1] http://wiki.eclipse.org/index.php?title=Tycho/Target_Platform#Filtering Just to cross-reference, see bug 398201. This issue is interfering with us using Tycho/Maven to _build_ the platform, including the servletbridge.extensionbundle. Do any reader of this bug know how to specify a negative requirement in servletbridge.extensionbundle so we could change its p2.inf file (or similar) so that, say, if "platform ui was present, do not include this extension in the resolution"?
(In reply to comment #30) > Do any reader of this bug know how to specify a negative requirement in > servletbridge.extensionbundle so we could change its p2.inf file (or > similar) so that, say, if "platform ui was present, do not include this > extension in the resolution"? Reading my own docs [1], we could try something like this: requires.0.name = platform.ui.whatever.the.iu.id.is requires.0.namespace = org.eclipse.equinox.p2.iu requires.0.min = 0 requires.0.max = 0 We would put this in the p2.inf file, and locate that next to the MANIFEST.MF. [1] http://eclipsesource.com/blogs/2012/03/15/publishing-negative-requirements/
(In reply to comment #30) Another example can be found in the RAP feature: http://git.eclipse.org/c/rap/org.eclipse.rap.git/tree/features/org.eclipse.rap.feature/p2.inf Note that I had to include this in the build.properties when building with Tycho/Maven. And in a bundle it needs to be located next to the MANIFEST.MF as Ian mentioned above.
Ian, thanks for the blog post. When did this happen! I'm always the last to hear of cool stuff. (And, I see in the blog it was Juno M6). Markus, thanks for concrete examples. Sadly, doesn't seem to help our CBI-based builds get past the problem in bug 398201 .. or, more exactly, transforms into a ?worse? problem. I think a negative requirement is still good for this bundle, but might take more work so split up "IDE" vs. "server" stuff. I tried several things, with all similar results. For example, add negative requirement on swt ... provides.0.namespace = java.package provides.0.name = javax.servlet provides.0.version = 2.5 provides.1.namespace = java.package provides.1.name = javax.servlet.http provides.1.version = 2.5 provides.2.namespace = java.package provides.2.name = javax.servlet.resources provides.2.version = 2.5 provides.3.namespace = java.package provides.3.name = org.eclipse.equinox.servletbridge provides.3.version = 1.1 requires.4.name = org.eclipse.swt requires.4.namespace = org.eclipse.equinox.p2.iu requires.4.min = 0 requires.4.max = 0 But for our CBI-based build, that results in following error [ERROR] Cannot resolve project dependencies: [ERROR] Software being installed: org.eclipse.equinox.sdk.feature.group 3.9.0.qualifier [ERROR] Cannot satisfy dependency: org.eclipse.equinox.p2.installer 1.0.300.qualifier depends on: bundle org.eclipse.swt 0.0.0 [ERROR] Cannot satisfy dependency: org.eclipse.equinox.p2.sdk.feature.group 3.8.0.qualifier depends on: org.eclipse.equinox.p2.installer 0.0.0 [ERROR] Cannot satisfy dependency: org.eclipse.equinox.sdk.feature.group 3.9.0.qualifier depends on: org.eclipse.equinox.p2.sdk.feature.group 0.0.0 [ERROR] Cannot satisfy dependency: org.eclipse.equinox.sdk.feature.group 3.9.0.qualifier depends on: org.eclipse.equinox.serverside.sdk.feature.group 0.0.0 [ERROR] Cannot satisfy dependency: org.eclipse.equinox.serverside.sdk.feature.group 3.8.0.qualifier depends on: org.eclipse.equinox.servletbridge.extensionbundle 0.0.0 [ERROR] Cannot satisfy dependency: org.eclipse.equinox.servletbridge.extensionbundle 1.2.100.qualifier depends on: org.eclipse.swt 0.0.0 I assume this had more to do with feature nesting, rather that plugin dependencies? Perhaps something related to extensions? I'll also make a note, if I (on my local system) just to remove the "fake" provides for javax.serlet*, then our Tycho/Maven build on master succeeds. Suggestions welcome.
(In reply to comment #33) > but might take more work so split up "IDE" vs. "server" stuff. Yes, a divorce is the solution ;-) Split off the build of the server stuff from the IDE build, and *please* don't merge them back together afterwards. The fact that the server stuff is in the release train repository causes a lot of pain to the consumers of Equinox. Fingers crossed that this is finally getting addressed properly now.
(In reply to comment #34) > (In reply to comment #33) > > but might take more work so split up "IDE" vs. "server" stuff. > Yes, a divorce is the solution ;-) Split off the build of the server stuff > from the IDE build, and *please* don't merge them back together afterwards. > > The fact that the server stuff is in the release train repository causes a > lot of pain to the consumers of Equinox. Fingers crossed that this is > finally getting addressed properly now. I think whether or not this is in the release train repository is a different issue and should have another bug open for it. You might detail how it "causes a lot of pain to the consumers of Equinox." If you mean because you want to build against the common repo, that's one thing, if if means it interferes with you building a product or installing your stuff, that's another thing. Thanks for bringing up that angle.
I just had a quick call with Tom and Simon about this. Our proposal is that we remove the servlet bridge feature from our build entirely (in Kepler). At the core of it, the p2 metadata of the extensionbundle is flawed - it doesn't accurately describe what that bundle provides. The intent is that it describes what is available in the environment but that is not something we can capture in the p2 metadata. This disconnect is the root of all the build grief people are having around it. Also, it is not clear that what we are building today is providing significant value. Consumers are likely doing their own build anyway to produce a WAR file and the built form we provide is not a useful input for that. It is also quite common to generate an extensionbundle automatically rather than consume the one we provide. If it does turn out to be useful to be providing a built form of the servlet bridge, perhaps a separate build can be created that does not feed into the release train repository. But to be clear there are no active equinox committers working in this area, and the onus will be on someone who needs this to step up and contribute to producing a build for it. Please speak up quickly either for or against, as this is blocking people's Tycho builds and they deserve a speedy resolution.
> > Please speak up quickly either for or against, as this is blocking people's > Tycho builds and they deserve a speedy resolution. I'm for it ... the less we build the better :) ... Especially if it contains invalid metadata. But in the interest of full disclosure I have gotten past my blocking bug with this issue ... seemed cured by the version of Java we were using ... but I see that more as "luck" and could come back again someday, such as in the next release of Java? (we moved from jdk1.7.0 to jdk1.7.0_11.) Not much time left till M5 ... but ... that'd be ideal pull this out?. Though might need to do several I builds this week to make sure we were ready for rampdown. M6 would work as well, I guess.
The RAP project provides an Equinox target feature that contains the servletbridge and servletbridge.extensionbundle. Would we still get the bundles from the Equinox p2 repository? This target feature is part of our contribution to Kepler, so unless we change something, we'd re-contribute it to the aggregator. Both bundles are expected in the current target by the WAR product tooling, a Libra component that is used by parts of our community to create WAR files for RAP applications. But if the auto-generated extensionbundle can be used in a WAR file just as well, we could keep it out of the target and request a change in the WAR product tools.
(In reply to comment #38) > The RAP project provides an Equinox target feature that contains the > servletbridge and servletbridge.extensionbundle. Would we still get the > bundles from the Equinox p2 repository? The proposal is "no". > This target feature is part of our contribution to Kepler, so unless we > change something, we'd re-contribute it to the aggregator. > > Both bundles are expected in the current target by the WAR product tooling, > a Libra component that is used by parts of our community to create WAR files > for RAP applications. But if the auto-generated extensionbundle can be used > in a WAR file just as well, we could keep it out of the target and request a > change in the WAR product tools. Sounds like there will be no change for M5 until we get the technical issues worked out, but yes, I think someone from Libra needs to get involved to provide a solution that doesn't depend on this literal bundle that has incorrect metadata (incorrect in current contexts). Adding Kaloyan to CC list. Kaloyan, can someone from Libra evaluate alternatives and/or comment on this issue?
(In reply to comment #39) > The proposal is "no". Does this apply only to the extensionbundle or do you plan to remove the servletbridge entirely? I've made a quick test manipulating an existing WAR file and found that it works just as well with the generated extensionbundle instead of the bundle that we include explicitly. If this holds true, I don't see any reason for us to include the extensionbundle in our target feature anymore. I've opened bug 398780 against the WAR products tooling to request to remove the dependency to the extensionbundle.
(In reply to comment #40) > Does this apply only to the extensionbundle or do you plan to remove the > servletbridge entirely? The idea is to remove the entire servletbridge feature. The bundles that make up that feature (minus extensionbundle) would still be available I think. The reasoning is that removing the entire feature is better than just removing the single bundle and leaving a broken feature. If you use p2 director to provision this feature minus extensionbundle then there is an install-time problem because there are no bundles claiming to export javax.servlet. > I've made a quick test manipulating an existing WAR file and found that it > works just as well with the generated extensionbundle instead of the bundle > that we include explicitly. If this holds true, I don't see any reason for > us to include the extensionbundle in our target feature anymore. I am likely just missing it, but what can the feature be used for in this form (without extension bundle). If you are generating a war file then you don't need an Eclipse feature for that right? Is it still useful at development time for provisioning a target platform?
(In reply to comment #41) > (In reply to comment #40) > > Does this apply only to the extensionbundle or do you plan to remove the > > servletbridge entirely? > > The idea is to remove the entire servletbridge feature. The bundles that > make up that feature (minus extensionbundle) would still be available I > think. ... I looked, and the org.eclipse.equinox.server.servletbridge feature contains: org.eclipse.equinox.http.servlet org.eclipse.equinox.http.servletbridge org.eclipse.equinox.servletbridge.extensionbundle The org.eclipse.equinox.serverside.sdk feature includes the org.eclipse.equinox.server.servletbridge feature as well as the bundles org.eclipse.equinox.http.servletbridge org.eclipse.equinox.servletbridge.extensionbundle But does not contain the bundle org.eclipse.equinox.http.servlet So, sounds at worse, we'd have to also include, directly, the org.eclipse.equinox.http.servlet bundle into the org.eclipse.equinox.serverside.sdk feature. Can't imagine that'd hurt anything? (And, FYI, this may ripple through a lot, so definitely a "post M5" work item). There are several pom.xml files that exclude, via filters, the org.eclipse.equinox.servletbridge.extensionbundle so presumably we should "clean up" those, as well?
Thanks for checking David. Yes I think it is best for post-M5 at this point. Although we have a workaround in our own build this continues to be a problem for others. Tom can you comment on whether those bundle/feature changes make sense to you? The "org.eclipse.equinox.http.servlet" bundle is also in org.eclipse.help feature but it likely makes sense in the Equinox serverside SDK as well (I'm just not sure what use case the serverside SDK was designed for).
(In reply to comment #39) > Kaloyan, can someone from Libra evaluate alternatives and/or comment on this > issue? Holger Staudacher is the committer who contributed and maintains the WAR Products feature in Libra. He should be able to help with the requested change.
(In reply to comment #41) > I am likely just missing it, but what can the feature be used for in this > form (without extension bundle). If you are generating a war file then you > don't need an Eclipse feature for that right? Is it still useful at > development time for provisioning a target platform? It's not directly needed for development, just for creating a WAR file directly from the IDE. The WAR product tool expects the servletbridge bundle in the target platform. Maybe the target platform is not an ideal place to get it from, but this approach ensures that the tool always finds and includes the matching version of the servlet bridge.
Marking as p2 to help remind this needs attention and decisions right after M5 ... if it is to be fixed for Kepler, it really should be fixed for M6.
I still think we should remove the servletbridge feature and ensure the extensionbundle is removed from any other feature early in M6. There is still the org.eclipse.equinox.serverside.sdk feature that can be used to populate target platforms. The term SDK in that feature name makes it clear this is a development time feature that isn't meant to be directly deployed in a product. To be clear the changes are: 1) Remove feature org.eclipse.equinox.server.servletbridge entirely 2) Change org.eclipse.equinox.serverside.sdk as follows: - Remove included feature org.eclipse.equinox.server.servletbridge - Remove included bundle org.eclipse.equinox.servletbridge.extensionbundle
(In reply to comment #47) > I still think we should remove the servletbridge feature and ensure the > extensionbundle is removed from any other feature early in M6. There is > still the org.eclipse.equinox.serverside.sdk feature that can be used to > populate target platforms. The term SDK in that feature name makes it clear > this is a development time feature that isn't meant to be directly deployed > in a product. > > To be clear the changes are: > > 1) Remove feature org.eclipse.equinox.server.servletbridge entirely > 2) Change org.eclipse.equinox.serverside.sdk as follows: > - Remove included feature org.eclipse.equinox.server.servletbridge > - Remove included bundle > org.eclipse.equinox.servletbridge.extensionbundle I assume when you said "early in M6", you mean "early in the 6 weeks for M6" ... so ... now would be a good time? :) And, I'm sure, will take some struggle to fix in PDE builds AND in CBI builds.
(In reply to comment #48) > I assume when you said "early in M6", you mean "early in the 6 weeks for M6" > ... so ... now would be a good time? :) Because we (RAP) are consumers of these bundles... I assume the extensionbundle is still included in M6, at least I can find S-4.3M6-201303141330/plugins/org.eclipse.equinox.servletbridge.extensionbundle_1.2.100.v20130225-1702.jar Will it be removed in M7?
Created attachment 228736 [details] possible patch to remove extension bundle As far as I can tell this is the minimal changes required to remove the org.eclipse.equinox.servletbridge.extensionbundle from our features. John, is that all that is needed or do we also need to remove the org.eclipse.equinox.servletbridge.extensionbundle project altogether to avoid CBI from building it and publishing the artifact to our repository?
(In reply to comment #50) > John, is that all that is needed or do we also need to remove the > org.eclipse.equinox.servletbridge.extensionbundle project altogether to > avoid CBI from building it and publishing the artifact to our repository? It also needs to be removed from the pom.xml at the root of the repository. That is what causes it to actually get built: http://git.eclipse.org/c/equinox/rt.equinox.bundles.git/tree/pom.xml
(In reply to comment #51) > It also needs to be removed from the pom.xml at the root of the repository. > That is what causes it to actually get built: > > http://git.eclipse.org/c/equinox/rt.equinox.bundles.git/tree/pom.xml Thanks John. I went ahead and released a fix with: http://git.eclipse.org/c/equinox/rt.equinox.bundles.git/commit/?id=a1a4aeafc79dcdab2289b45e6f8c87ed0dbb4e26 Will have to verify in the nightly build.(In reply to comment #49) > (In reply to comment #48) > Will it be removed in M7? Yes, that is the plan.
This bug occurs in M6 e.g. exporting org.eclipse.rap.demo as WAR and then running on Tomcat. Then I get the error message "Missing Constraint: Import-Package: javax.servlet" Is this that bug? This bug is not fixed when removing org.eclipse.equinox.servletbridge.extensionbundle from the war product. Any other quick fix available? Now will this bug be fixed in M7? And for those developers who already migrated from M5 to M6 (the bug not occured in M5), is there a way to update something against the nightly build which presumably fixes this bug? what features do I have to update? what is the update site or a corresponding zip file? The Kepler M5 downloads are not provided any longer and I deleted the M5 installation, so actually I cant build a working WAR file anymore.. any advise?
(In reply to comment #53) > "Missing Constraint: Import-Package: javax.servlet" I'm pretty sure you are hit by bug 398780. > The Kepler M5 downloads are not provided any longer and I deleted the M5 > installation, so actually I cant build a working WAR file anymore.. Speaking of RAP: The RAP version that has been contributed to Kepler M5 is identical with our RAP 2.0 release, Kepler M6 contains the RAP 2.1 M1. Here are some deep links to old p2 repositories that should help in your case. Please keep in mind that these URLs may be removed in the future without further notice. RAP 2.0 Kepler M5 http://archive.eclipse.org/rt/rap/2.0/RC3-20130205-1849.kepler/ Kepler M5 http://download.eclipse.org/releases/kepler/201302080900/
Should rt.equinox.bundles/features/org.eclipse.equinox.server.servletbridge/feature.xml also be updated so that org.eclipse.equinox.servletbridge.extensionbundle is removed? https://git.eclipse.org/r/17646
(In reply to Lars Vogel from comment #55) > Should > rt.equinox.bundles/features/org.eclipse.equinox.server.servletbridge/feature. > xml > also be updated so that org.eclipse.equinox.servletbridge.extensionbundle is > removed? > > https://git.eclipse.org/r/17646 I mark this bug as closed again. I had problems with the Eclipse SDK build and thought this could be related. But the build works again since a while.
