| Summary: | Adopt new orbit and Jetty builds | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | John Arthorne <john.arthorne> | ||||
| Component: | Releng | Assignee: | Kim Moir <kim.moir> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | daniel_megert, david_williams, gunnar, hmalphettes, jesse.mcconnell, kim.moir, sja.eclipse, tjwatson | ||||
| Version: | 4.1 | ||||||
| Target Milestone: | 3.8 M4 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows 7 | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
John Arthorne
It would be preferable to be a stable build as integration builds are often deleted which causes build breakage. The "candidate" for the stable build, which has the new javax.servlet in it, has been promoted to http://download.eclipse.org/tools/orbit/downloads/drops/I20111201180206/ I'll rename this (or subsequent I build) to S build on Friday afternoon. So should be ready (mirrored) in time for next weeks builds. I'd be nice if someone could "test" this I-build version in runtime targets, or similar, as a quick sanity check ... but, I know, Kim, there are issues with using it in a build (need to wait till it mirrors, URL will change soon, etc.) so I'm not suggesting that ... I'm just saying its there. According to Tom (bug 309529 comment 46), we also need a new Jetty. We can use this bug to track both since they need to be coordinated. Tom can you let us known if/when/where a new Jetty build is available with the fixed range on javax.servlet? (In reply to comment #3) > According to Tom (bug 309529 comment 46), we also need a new Jetty. We can use > this bug to track both since they need to be coordinated. Tom can you let us > known if/when/where a new Jetty build is available with the fixed range on > javax.servlet? Jesse, let us know when you have a jetty version that uses the new 2.6 package versions of javax.servlet. Thanks. (In reply to comment #2) > I'd be nice if someone could "test" this I-build version in runtime targets, or > similar, as a quick sanity check ... but, I know, Kim, there are issues with > using it in a build (need to wait till it mirrors, URL will change soon, etc.) > so I'm not suggesting that ... I'm just saying its there. I did quickly look at the javax.servlet bundle in this build, and confirmed the package version was correctly moved backwards to 2.6. that will likely be a little while, I am trying to get our bundles smacked around for the latest release candidate as it is... once I have this working we can look at making those changes in jetty 8 and rolling another RC btw, when do you expect to have these? (In reply to comment #7) > btw, when do you expect to have these? Unfortunately we need them very soon so we can update to the M4 stable orbit build for our Juno M4 build which needs to be finalized by the end of next week. ok, i just need to beat hudson into submission and get a clean build again for this stuff and then I can look at getting an RC1 out with those changes. I'll shoot for tomorrow or early next week Monday would be ideal. Our builds toward 3.8M4 actually start tomorrow but Monday is the day that we build our candidate that the teams test on Tuesday. ok, I'll see what I can do (In reply to comment #11) > ok, I'll see what I can do Thanks Jesse (and Hugues!). See bug360245 comment 38 and bug360245 comment 39. There is a new 8.1 snapshot we could use for a test build, but I think the jetty team will get us a more official build (by Monday?). Also note that I found a potential breaking change in the jetty 8.1 snapshot build. We can react to the change, but I am not sure if this was intentional break by the jetty team or not. it was planned, though a but unfortunate, part of the reason for 8.1 as opposed to 8.0.6 I am trying to get a jetty8 p2 repo built through our normal mechanism but its proving problematic, there is some bad zip file being pulled that kills the process atm. if we can get that fixed I'll be rolling an RC1 for you guys I released a couple more fixes to react to the package version change for javax.servlet (http://git.eclipse.org/c/equinox/rt.equinox.bundles.git/commit/?id=99045c57555e484066bb0caa6d9a9ffbf1d52f7f). I imagine we will be picking up all the latest versions of the orbit bundles but the following MUST all be in sync and from the latest orbit build: javax.servlet.jsp javax.servlet org.apache.jasper.glassfish Kim, I am ready for a test build using the jetty snapshot at: http://download.eclipse.org/jetty/updates/jetty-bundles-8.x/8.1.0.SNAPSHOT/ Since the version of jetty moved to 8.1.0 do we need to go through and update all of our features? (In reply to comment #14) > Since the version of jetty moved to 8.1.0 do we need to go through and update > all of our features? To answer my own question, I don't think so because we use open versions (0.0.0) to include the jetty bundles in our features. The build.properties for some of the features currently specify 8.0.4.qualifier to include the jetty source bundles. I'll fix this. Created attachment 207850 [details] patch for master equinox and sdk features (still in cvs) commit to update maps http://git.eclipse.org/c/platform/eclipse.platform.releng.maps.git/commit/?id=e686380c2dca8f28c14e309fe60c17ad8a187429 Test build seems to be proceeding, I have tagged the master-equinox and sdk features for Sunday's integration build. I'll the update the remaining bundles in the Orbit map on Monday. (In reply to comment #18) > Test build seems to be proceeding, I have tagged the master-equinox and sdk > features for Sunday's integration build. I'll the update the remaining bundles > in the Orbit map on Monday. I have also released my changes to the integration branch for the build. Thanks Kim. NOTE: You must also update the version numbers in /org.eclipse.platform.doc.isv/platformOptions.txt to avoid Javadoc generation breakage. This was released for I20111205-1300 http://git.eclipse.org/c/platform/eclipse.platform.releng.maps.git/commit/?id=b31f247700a4278004b085ec6351d86aec22ba5b Jesse, when can we expect non-snapshot bundles that we can consume them for our milestone? CC'ing Hugues, Please see comment 22. Tom, Jesse took care of building it. Sorry for the delay. Jesse/Hugues Noticed that the qualifier is "RC0", in earlier builds it was a number. Is there a plan to change this? It should be RC1 for what I gave you... but this was a release candidate, we'll be pushing out a proper 7.6.0.v201112## release within a week or three jesse Yes, I meant RC1 :-) Thanks for the clarification. I expect we'll update the to the release once it's available. Closing. Having problems building with the new bundles, reopening. what sort of issues? (In reply to comment #30) > what sort of issues? During our build we run the p2.director and getting this error: Cannot satisfy dependency: From: Eclipse SDK 3.8.0.I20111207-1435 (org.eclipse.sdk.ide 3.8.0.I20111207-1435) To: org.eclipse.sdk.feature.group [3.8.0.v20111207-7Q83A7DQK3C2g8rs0qFpVANXGlm1_h-c5UeJAKeIj4NVL] [p2.director] Cannot complete the install because one or more required items could not be found. [p2.director] Software being installed: Eclipse SDK 3.8.0.I20111207-1435 (org.eclipse.sdk.ide 3.8.0.I20111207-1435) [p2.director] Missing requirement: Jetty Http Service 3.0.0.v20111202-1436 (org.eclipse.equinox.http.jetty 3.0.0.v20111202-1436) requires 'package org.eclipse.jetty.http [8.0.0,9.0.0)' but it could not be found This does not make sense because the bundle org.eclipse.jetty.http does export that package at version 8.1.0. So far I don't think it is an issue with jetty 8.1 RC1 bundles. I'm running a test I build now with a totally clean repo with the hypothesis that a bundle a previous build is causing problems. We discard bundles with the same name, version and qualifier if they exist in a previous build to ensure that the bundles installed via update are the same as the ones installed via a zip. (In reply to comment #20) > NOTE: You must also update the version numbers in > /org.eclipse.platform.doc.isv/platformOptions.txt to avoid Javadoc generation > breakage. Looks like this did not happen: we have Javadoc issues in our latest M4 candidate build: http://download.eclipse.org/eclipse/downloads/drops/I20111208-1305/compilelogs/platform.doc.isv.javadoc.txt FYI, I did an upgrade from the 3.8 build I20111205-1800 (which included jetty SNAPSHOT bundles) to the I20111208-1305 build and confirmed the new jetty RC1 bundles are now used. So it did perform the downgrade properly since RC1 < SNAPSHOT. (In reply to comment #33) > (In reply to comment #20) > > NOTE: You must also update the version numbers in > > /org.eclipse.platform.doc.isv/platformOptions.txt to avoid Javadoc generation > > breakage. > > Looks like this did not happen: we have Javadoc issues in our latest M4 > candidate build: > http://download.eclipse.org/eclipse/downloads/drops/I20111208-1305/compilelogs/platform.doc.isv.javadoc.txt Sorry about that, I was not sure who should update that file or what actually needs updated, I will look into what is needed and get this done if we have a respin. I fixed this with commit: http://git.eclipse.org/c/platform/eclipse.platform.common.git/commit/?id=2106ccca51759d4716c09658245c5bd041f52b01 Although I think I may have caused an issue for the build since I released in the middle of the respin build which was going on when I pushed my change. I restarted the build to include this fix. Fixed. |