Community
Participate
Working Groups
For Equinox 3.8 we are moving from Servlet 2.x to Servlet 3.0; see bug 341643 and bug 309529. It is therefore necessary for us to ensure that the changes are built and tested correctly. This is a high level bug report to gather the requirements for this work. - The following two plug-ins have been changed to enable support for Servlet 3.0: org.eclipse.equinox.http.servlet org.eclipse.equinox.jsp.jasper - It is important to note that while these plug-ins now work under Servlet 3.0, they must continue to execute under Servlet 2.x. - We need to stop building the bundle org.eclipse.equinox.http.servlet, since it is no longer required now that we have Jetty in Equinox. - We need to stop building the old org.mortbay.* plug-ins, since they are no longer necessary now that Jetty is in Equinox. - We need to stop building older versions of Jetty (org.eclipse.equinox.http.jetty5 and org.eclipse.equinox.http.jetty6.), since we now have Jetty 8 (org.eclipse.equinox.http.jetty8) in Equinox. - We need to assess the Eclipse Platform and Equinox dependencies on Servlet 2.x and consider each use and any adoptions that moving to Servlet 3.0 will cause.
(In reply to comment #0) > - We need to stop building the bundle org.eclipse.equinox.http.servlet, since > it is no longer required now that we have Jetty in Equinox. What ever you do, don't stop building org.eclipse.equinox.http.servlet, that is required by the org.eclipse.equinox.http.jetty bundles. I think you meant bundle org.eclipse.equinox.http. I had opened bug 362217 for that. > > - We need to stop building the old org.mortbay.* plug-ins, since they are no > longer necessary now that Jetty is in Equinox. Clarification: we need to stop including/shipping the org.mortbay.* bundles. These come from orbit, we don't build them. > > - We need to stop building older versions of Jetty > (org.eclipse.equinox.http.jetty5 and org.eclipse.equinox.http.jetty6.), since > we now have Jetty 8 (org.eclipse.equinox.http.jetty8) in Equinox. I mentioned this in bug 362217, but should probably open a separate bug about this.
Okay, to summarize this is what I think we need to do equinox.http bundle removed from the following features org.eclipse.equinox.server.simple master-equinox (buildtime feature I own) org.eclipse.equinox.sdk org.eclipse.equinox.serverside.sdk mortbay.jetty, mortbay.jetty.server, mortbay.jetty.util bundles removed from the following features master-equinox (buildtime feature I own) org.eclipse.equinox.jmx.server org.eclipse.equinox.server.jetty org.eclipse.equinox.serverside.sdk org.eclipse.help I'm a bit confused by >> We need to stop building older versions of Jetty (org.eclipse.equinox.http.jetty5 and org.eclipse.equinox.http.jetty6.), since we now have Jetty 8 (org.eclipse.equinox.http.jetty8) in Equinox. Where is the new version of jetty, I don't see it in the build yet -bash-3.00$ ls -d *equinox.http.jetty* org.eclipse.equinox.http.jetty_1.1.100 org.eclipse.equinox.http.jetty_2.0.0 org.eclipse.equinox.http.jetty.source_2.0.100.N20111107-2000
(In reply to comment #2) > Where is the new version of jetty, I don't see it in the build yet > -bash-3.00$ ls -d *equinox.http.jetty* > org.eclipse.equinox.http.jetty_1.1.100 > org.eclipse.equinox.http.jetty_2.0.0 > org.eclipse.equinox.http.jetty.source_2.0.100.N20111107-2000 These two equinox jetty bundles refer to the following entries in the core.map: plugin@org.eclipse.equinox.http.jetty,2.0.0=GIT,tag=v20111010-1614,repo=git://git.eclipse.org/gitroot/equinox/rt.equinox.bundles.git,path=bundles/org.eclipse.equinox.http.jetty6 plugin@org.eclipse.equinox.http.jetty,1.1.100=GIT,tag=v20111010-1614,repo=git://git.eclipse.org/gitroot/equinox/rt.equinox.bundles.git,path=bundles/org.eclipse.equinox.http.jetty5 I have just added a third entry for jetty8 to the core.map and released the change to master: plugin@org.eclipse.equinox.http.jetty,3.0.0=GIT,tag=v20111107-1631,repo=git://git.eclipse.org/gitroot/equinox/rt.equinox.bundles.git,path=bundles/org.eclipse.equinox.http.jetty8 The org.eclipse.equinox.http.jetty bundle that depends on jetty 8 will now be version 3.0: Here is a mapping between the equinox.http.jetty bundles and their jetty version dependencies: org.eclipse.equinox.http.jetty v=1.x ---> Jetty 5 org.eclipse.equinox.http.jetty v=2.x ---> Jetty 6 org.eclipse.equinox.http.jetty v=3.x ---> Jetty 8 We want to stop building the org.eclipse.equinox.http.jetty versions 1.x and 2.x versions since they depend on the old mortbay jetty versions. We want to start building the org.eclipse.equinox.http.jetty version 3.0.0 which depends on the new eclipse jetty 8 version. Sorry for the confusion.
(In reply to comment #2) > mortbay.jetty, mortbay.jetty.server, mortbay.jetty.util bundles removed from > the following features > master-equinox (buildtime feature I own) > org.eclipse.equinox.jmx.server > org.eclipse.equinox.server.jetty > org.eclipse.equinox.serverside.sdk > org.eclipse.help Note that you will need to add the following jetty 8 bundles to these features then. org.eclipse.jetty.continuation_8.0.1.v20110908 org.eclipse.jetty.http_8.0.1.v20110908 org.eclipse.jetty.io_8.0.1.v20110908 org.eclipse.jetty.security_8.0.1.v20110908 org.eclipse.jetty.server_8.0.1.v20110908 org.eclipse.jetty.servlet_8.0.1.v20110908 org.eclipse.jetty.util_8.0.1.v20110908 The exact versions are not important, but they must be 8.x versions. The latest release of jetty 8 is 8.0.4 I suggest we start with that p2 repository: http://download.eclipse.org/jetty/updates/jetty-bundles-8.x/8.0.4.v20111024/ Hugues how long do you retain the p2 repos for the releases? I imagine it is indefinitely but want to confirm. We will also need to lock down what version of jetty we want to ultimately be consumed into Juno so that we can ramp down properly some time in May.
(In reply to comment #4) > > http://download.eclipse.org/jetty/updates/jetty-bundles-8.x/8.0.4.v20111024/ > > Hugues how long do you retain the p2 repos for the releases? I imagine it is > indefinitely but want to confirm. I added Jesse to the cc list. Yes we will keep the p2repo we end-up using indefinitely. > We will also need to lock down what version > of jetty we want to ultimately be consumed into Juno so that we can ramp down > properly some time in May. Yes thanks for reminding us about it.
Created attachment 206706 [details] patch for features still in cvs
Thanks Tom for catching my mistakes... a case for wanting to edit the description! Sorry about that. Kim, I have a test project called org.eclipse.equinox.http.servlet.tests that exercises org.eclipse.equinox.http.servlet. It's currently in my github repository since I am not an Equinox committer. I'm sufficiently green at git that I'm having some trouble getting it pushed to another git repository that Tom has recommended I use.
Since we are not going to build org.eclipse.equinox.http the feature org.eclipse.equinox.server.simple is pretty useless. It only contains a single bundle which is the javax.servlet bundle. I think we should stop building this feature.
We also need the new servlet 3.0 API bundles!! <unit id="javax.el" version="2.2.0.v201108011116"/> <unit id="javax.el.source" version="2.2.0.v201108011116"/> <unit id="javax.servlet.jsp" version="2.2.0.v201103241009"/> <unit id="javax.servlet.jsp.source" version="2.2.0.v201103241009"/> <unit id="javax.servlet" version="3.0.0.v201108011116"/> <unit id="javax.servlet.source" version="3.0.0.v201108011116"/> And the new jasper glassfish bundle <unit id="org.apache.jasper.glassfish" version="2.2.2.v201108011116"/> <unit id="org.apache.jasper.glassfish.source" version="2.2.2.v201108011116"/> The glassfish bundle needs to replace the current org.apache.jasper bundle we include.
The test build is still failing. The help feature requires org.apache.commons.el which requires an old version of javax.servlet. Not sure how to fix this. /builds/N201111091737/org.eclipse.releng.basebuilder/plugins/org.eclipse.pde.build_3.8.0.v20110728/scripts/genericTargets.xml:111: Processing inclusion from feature org.eclipse.help: Bundle org.apache.commons.el_1.0.0.v201101211617 failed to resolve.: Unsatisfied import package javax.servlet_[2.4.0,3.0.0). Unsatisfied import package javax.servlet.http_[2.4.0,3.0.0). Unsatisfied import package javax.servlet.jsp_[2.0.0,2.1.0). Unsatisfied import package javax.servlet.jsp.el_[2.0.0,2.1.0). Unsatisfied import package javax.servlet.jsp.resources_[2.0.0,2.1.0). Unsatisfied import package javax.servlet.jsp.tagext_[2.0.0,2.1.0). Unsatisfied import package javax.servlet.resources_[2.4.0,3.0.0). Anyways, I'll comment out the nightly build and we can look at it tomorrow.
(In reply to comment #10) > The test build is still failing. The help feature requires > org.apache.commons.el which requires an old version of javax.servlet. Not sure > how to fix this. > > /builds/N201111091737/org.eclipse.releng.basebuilder/plugins/org.eclipse.pde.build_3.8.0.v20110728/scripts/genericTargets.xml:111: > Processing inclusion from feature org.eclipse.help: Bundle > org.apache.commons.el_1.0.0.v201101211617 failed to resolve.: > Unsatisfied import package javax.servlet_[2.4.0,3.0.0). > Unsatisfied import package javax.servlet.http_[2.4.0,3.0.0). > Unsatisfied import package javax.servlet.jsp_[2.0.0,2.1.0). > Unsatisfied import package javax.servlet.jsp.el_[2.0.0,2.1.0). > Unsatisfied import package javax.servlet.jsp.resources_[2.0.0,2.1.0). > Unsatisfied import package javax.servlet.jsp.tagext_[2.0.0,2.1.0). > Unsatisfied import package javax.servlet.resources_[2.4.0,3.0.0). > > Anyways, I'll comment out the nightly build and we can look at it tomorrow. Sorry, I did not realize help used an el implementation. There is a new el implementation in orbit at. In my testing help seemed to function fine without one. Anyway we are going to have to drop the org.apache.commons.el bundle for the following from orbit: plugin@com.sun.el,2.2.0=p2IU,id=com.sun.el,version=2.2.0.v201108011116,repository=http://download.eclipse.org/tools/orbit/downloads/drops/S20111018035124/repository plugin@com.sun.el.source,2.2.0=p2IU,id=com.sun.el.source,version=2.2.0.v201108011116,repository=http://download.eclipse.org/tools/orbit/downloads/drops/S20111018035124/repository
Thanks Tom, I've fixed this and started another test build.
FYI, I opened bug 363473 because I am not convinced we support el properly.
This is released for the N20111110-2000 build. There are compile errors in the ua tests. Will verify that all the new source bundles are being generated, may have missed some with all the changes required.
(In reply to comment #14) > This is released for the N20111110-2000 build. There are compile errors in the > ua tests. Simon A. Please pull in the UA tests from https://git.eclipse.org/c/platform/eclipse.platform.ua.git/ and see if you can figure out why they have compile errors. > > Will verify that all the new source bundles are being generated, may have > missed some with all the changes required. Kudos to Kim for turning this rather difficult build task around this week. Thanks!
It looks like the ua tests have MockServletRequest and MockServletResponse classes that implement servlet container interfaces. I suggest the tests be modified to use something like eazyMock instead of directly implementing such interfaces for mocking.
(In reply to comment #16) > It looks like the ua tests have MockServletRequest and MockServletResponse > classes that implement servlet container interfaces. I suggest the tests be > modified to use something like eazyMock instead of directly implementing such > interfaces for mocking. I have entered bug 363584 for these compile errors. Unfortunately we don't currently have active UA committers but we'll have to track someone down.
Created attachment 206856 [details] patch for sdk features
I also updated the javadoc to reference the updated jars.
Tom, I'd like to run a test integration build on Monday to ensure we have tagged the many features this change entailed and don't break the Tuesday build. If you could tag the Equinox features, that would be great, I have tagged the Eclipse SDK features.
(In reply to comment #20) > Tom, I'd like to run a test integration build on Monday to ensure we have > tagged the many features this change entailed and don't break the Tuesday > build. If you could tag the Equinox features, that would be great, I have > tagged the Eclipse SDK features. Done, you may do a test integration build now. FYI, I am traveling Sunday/Monday and will not be available.
Created attachment 206957 [details] patch for equinox.serverside.sdk Can someone from the Equinox team please apply this patch to fix the source generation for the equinox.serverside.sdk feature? My Equinox commit rights are still broken.
(In reply to comment #22) > Created attachment 206957 [details] > patch for equinox.serverside.sdk > > Can someone from the Equinox team please apply this patch to fix the source > generation for the equinox.serverside.sdk feature? My Equinox commit rights > are still broken. Done in commit: http://git.eclipse.org/c/equinox/rt.equinox.bundles.git/commit/?id=4ee59e0cc3fd8cd0850ac767c14cbbee065ce304 I will also tag it for the build
I think my commit broke the nightly build and Kim fixed for the I-Build.
Actually, it was my commit that broke the build :-) I reverted it for the nightly and integration build.
We have broken Javadoc generation: ../org.eclipse.equinox.http.jetty_3.0.0/src/org/eclipse/equinox/http/jetty/internal/HttpServerManager.java:21: cannot access org.eclipse.jetty.server.Connector bad class file: ../org.eclipse.jetty.server_8.0.4.v20111024.jar(org/eclipse/jetty/server/Connector.class) class file has wrong version 50.0, should be 49.0 Please remove or make sure it appears in the correct subdirectory of the classpath. import org.eclipse.jetty.server.Connector; ^ 1 error And CHKPII failures: eclipse/plugins/com.sun.el.source_2.2.0.v201108011116_jar/com/sun/el/ Messages.properties JAVA2-PRB 918 Found 1 single quote in text handled by Java MessageFormat class. Double this quote. Line: 55 929 (W) Duplicate string ID found: error.property.notfound. Lines: 68, 85 918 Found 1 single quote in text handled by Java MessageFormat class. Double this quote. Line: 87 918 Found 1 single quote in text handled by Java MessageFormat class. Double this quote. Line: 88 eclipse/plugins/org.apache.jasper.glassfish.source_2.2.2.v201108011116_jar/org/apache/jasper/resources/ messages.properties JAVA2-PRB 929 (W) Duplicate string ID found: jsp.error.page.invalid.buffer. Lines: 97, 103 929 (W) Duplicate string ID found: jsp.error.xml.invalidHighSurrogate. Lines: 415, 429 914 Separator between string ID and text should be '='. May be invalid text continuation. Line: 469 914 Separator between string ID and text should be '='. May be invalid text continuation. Line: 470 eclipse/plugins/org.apache.jasper.glassfish_2.2.2.v201108011116_jar/org/apache/jasper/resources/ messages.properties JAVA2-PRB 929 (W) Duplicate string ID found: jsp.error.page.invalid.buffer. Lines: 97, 103 929 (W) Duplicate string ID found: jsp.error.xml.invalidHighSurrogate. Lines: 415, 429 914 Separator between string ID and text should be '='. May be invalid text continuation. Line: 469 914 Separator between string ID and text should be '='. May be invalid text continuation. Line: 470 eclipse/plugins/com.sun.el_2.2.0.v201108011116_jar/com/sun/el/ Messages.properties JAVA2-PRB 918 Found 1 single quote in text handled by Java MessageFormat class. Double this quote. Line: 55 929 (W) Duplicate string ID found: error.property.notfound. Lines: 68, 85 918 Found 1 single quote in text handled by Java MessageFormat class. Double this quote. Line: 87 918 Found 1 single quote in text handled by Java MessageFormat class. Double this quote. Line: 88 Are they related?
I just fixed the chkpii errors. Not sure how to fix the javadoc generation.
(In reply to comment #26) > We have broken Javadoc generation: > > ../org.eclipse.equinox.http.jetty_3.0.0/src/org/eclipse/equinox/http/jetty/internal/HttpServerManager.java:21: > cannot access org.eclipse.jetty.server.Connector > bad class file: > ../org.eclipse.jetty.server_8.0.4.v20111024.jar(org/eclipse/jetty/server/Connector.class) > class file has wrong version 50.0, should be 49.0 > Please remove or make sure it appears in the correct subdirectory of the > classpath. > import org.eclipse.jetty.server.Connector; > ^ > 1 error > I think this is because the jetty bundles are compiled for Java 6 and require Java 6.
*** Bug 363917 has been marked as a duplicate of this bug. ***
Thanks, Tom, I fixed this and ran a successful test build this morning to verify that the javadoc is fixed.
This is probably well understood and obvious to others ... but, since I am just now connecting the dots, thought I'd ask to be sure. It sounds like Java 6 then will be the "minimum JRE" to run the IDE ... at least, that is, to have Help work? Anything else effected? I guess "infocenters" such as at eclipse.org will need to use Java 6 (if they use 3.8 or 4.2 based distributions). (I am pretty sure eclipse.org already does use 1.6 ... just asking, so I'll know for sure). If this is a "new requirement" (effectively raising minimum JRE from 1.5 to 1.6) I guess should be widely announced (but, I can't imagine anyone would care ... as long only effects "help server functions"). Thanks in advance for clarifying.
(In reply to comment #31) > This is probably well understood and obvious to others ... but, since I am just > now connecting the dots, thought I'd ask to be sure. It sounds like Java 6 then > will be the "minimum JRE" to run the IDE ... at least, that is, to have Help > work? Anything else effected? I guess "infocenters" such as at eclipse.org will > need to use Java 6 (if they use 3.8 or 4.2 based distributions). (I am pretty > sure eclipse.org already does use 1.6 ... just asking, so I'll know for sure). > If this is a "new requirement" (effectively raising minimum JRE from 1.5 to > 1.6) I guess should be widely announced (but, I can't imagine anyone would care > ... as long only effects "help server functions"). Thanks in advance for > clarifying. Good catch! Actually, we currently claim that 'help' runs on 1.4: http://www.eclipse.org/projects/project-plan.php?projectid=eclipse#appendix
(In reply to comment #31) > This is probably well understood and obvious to others ... but, since I am just > now connecting the dots, thought I'd ask to be sure. It sounds like Java 6 then > will be the "minimum JRE" to run the IDE ... Yes. RCP is not affected, but the jetty we are including in the platform requires Java 6. This doesn't necessarily mean you need Java 6 to run a help infocenter though. Our help web application itself can still be run on an older jetty version (like the one it ran last milestone), and there are potentially other ways to run the help system on different jetty versions. See bug 361022 for more discussion. It's also worth noting, our reference platforms have been purely Java 6 and above since Indigo, so there is no official change there. I will re-run my tool during the next plan update to ensure the plan appendix is updated with the latest EE information.
I think the remaining issue on this bug is that the serverside.sdk is missing some of it's source bundles. We tried this here but it broke the build. Investigating. http://git.eclipse.org/c/equinox/rt.equinox.bundles.git/commit/?id=4ee59e0cc3fd8cd0850ac767c14cbbee065ce304
Closing bug. Opened bug 365492 for remaining source bundle issues.
Created attachment 208017 [details] patch to fix equinox build page
*** Bug 356887 has been marked as a duplicate of this bug. ***
