Bugzilla – Full Text Bug Listing
| Summary: | adopt to ECF 3.5.5 | ||
|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Meng Xin Zhu <kane.zhu> |
| Component: | p2 | Assignee: | P2 Inbox <equinox.p2-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | irbull, kane.mx, kim.moir, slewis |
| Version: | unspecified | ||
| Target Milestone: | Juno M7 | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 358842 | ||
|
Description
Meng Xin Zhu
March 19 is after M6, so this would go into M7. Is that what you expect Meng? (In reply to comment #1) > March 19 is after M6, so this would go into M7. Is that what you expect Meng? It would be what we prefer...but I didn't realize that M6 was before the 19th. When would a build have to occur for us to get it into M6? We could potentially do a release build before the 19th...but it would be an inconvenience, as there is at least one outstanding bug that we are waiting for clarification on that we would like to get into ecf 3.5.5 (Scheduled for 19th). BTW...the *only* change for bug 370801 is not currently even used by p2 (pausing transfers)...and the likelihood of regression for other parts of things is very small. Next week is milestone week with warmup builds starting this Friday. After Friday I wouldn't want to update our dependencies on ECF (until after M6). I'm not worried as much about regressions, as I am about messing up the contributions and getting broken builds. I'm happy to wait until March 19th. (In reply to comment #3) > Next week is milestone week with warmup builds starting this Friday. After > Friday I wouldn't want to update our dependencies on ECF (until after M6). I'm > not worried as much about regressions, as I am about messing up the > contributions and getting broken builds. > > I'm happy to wait until March 19th. Ok great thanks. Let's go with the 19th as planned then. I'm fine to follow the release schedule of ECF. Mark it target to M7. ECF 3.5.5 has been completed and is available for use in Eclipse. The 3.5.5 p2 repository is here: http://download.eclipse.org/rt/ecf/3.5.5/site.p2 Note that this repo has some feature changes (to the ECF filetransfer feature and httpclient feature), but afaik this should *not* affect the p2/Equinox/Eclipse build...as it's my understanding that it does not use ECF features, but rather accesses the relevant plugins/IUs directly. If this is incorrect (i.e. the platform does use ECF features to consume the ECF bundles, please feel free to contact me/Scott about the releng needs to incorporate this version). Ian, do you have privilege to update p2.map or should we re-assign it to releng? (In reply to comment #7) > Ian, do you have privilege to update p2.map or should we re-assign it to > releng? It's more than just the p2.map. I'm working with the releng to get this done now. However, it looks like there is a respin of yesterday's IBuild, so we're going to wait until that build has been kicked off. (In reply to comment #6) > http://download.eclipse.org/rt/ecf/3.5.5/site.p2 In the past we've used a repo with the string 'external' in it. http://www.eclipse.org/external/rt/ecf/3.5.4/site.p2 I just wanted to check that this change (no external) is intentional. > > Note that this repo has some feature changes (to the ECF filetransfer feature > and httpclient feature), but afaik this should *not* affect the > p2/Equinox/Eclipse build...as it's my understanding that it does not use ECF > features, but rather accesses the relevant plugins/IUs directly. If this is > incorrect (i.e. the platform does use ECF features to consume the ECF bundles, > please feel free to contact me/Scott about the releng needs to incorporate this > version). Yes, according to our map files we only use plugins/fragments. I'm updating the map file now. (In reply to comment #9) > (In reply to comment #6) > > http://download.eclipse.org/rt/ecf/3.5.5/site.p2 > In the past we've used a repo with the string 'external' in it. > > http://www.eclipse.org/external/rt/ecf/3.5.4/site.p2 > > I just wanted to check that this change (no external) is intentional. We've always presented our repo URL in the 'download.eclipse.org' form. I believe that Kim uses the 'external' version because of some security constraint on the build machines...but I'm not certain of that. To find out for sure, you would probably have to ask Kim...or perhaps DJ. (In reply to comment #10) > We've always presented our repo URL in the 'download.eclipse.org' form. I > believe that Kim uses the 'external' version because of some security > constraint on the build machines...but I'm not certain of that. To find out > for sure, you would probably have to ask Kim...or perhaps DJ. Thanks Scott. I'll check with Kim and DJ. Other than that, I've updated the map file to use the new versions. The only difference (one exception*) is the qualifiers. Ideally, if there are no others changes, the qualifiers should remain constant, but I'm not sure if this is possible yet with Maven/Tycho. * The one exception is org.eclipse.ecf.provider.filetransfer.httpclient where the 3rd digit was updated from 1 to 200. I just want to make sure these changes sound correct. Thanks for allt he help Scott. (In reply to comment #11) > (In reply to comment #10) > > We've always presented our repo URL in the 'download.eclipse.org' form. I > > believe that Kim uses the 'external' version because of some security > > constraint on the build machines...but I'm not certain of that. To find out > > for sure, you would probably have to ask Kim...or perhaps DJ. > > Thanks Scott. I'll check with Kim and DJ. > I believe we used the external URLs because of inconsistencies with the mirror contents. We'd be running a build and it would fail to download the latest ECF because it wasn't on a mirror and the build would fail. Kim can confirm or deny. (In reply to comment #11) > (In reply to comment #10) > > We've always presented our repo URL in the 'download.eclipse.org' form. I > > believe that Kim uses the 'external' version because of some security > > constraint on the build machines...but I'm not certain of that. To find out > > for sure, you would probably have to ask Kim...or perhaps DJ. > > Thanks Scott. I'll check with Kim and DJ. > > Other than that, I've updated the map file to use the new versions. The only > difference (one exception*) is the qualifiers. Ideally, if there are no others > changes, the qualifiers should remain constant, but I'm not sure if this is > possible yet with Maven/Tycho. We're using buckminster currently...and although it may be possible (i'm not sure)...we're not doing it yet. I updated the platform feature in the 3.8 stream so the ecf source would be included correctly in our build. http://git.eclipse.org/c/platform/eclipse.platform.releng.git/commit/?id=62471504c7759e71b5f4da41fa69011de02aded2 I've updated the map file and the platformOptions.txt in the doc bundle. Updating these was a little tedious as I had to copy and past the version string from the content.jar to both the map file and the platformOptions. That's fine, if that's the way it's done (although it seems a little error prone). I'm just wondering if I did that correctly? (Maybe DJ will tell me no, no, no, you just run the special Eclipse CMD that updates map files :-). I'll leave this bug open so I can check that tonights build picks up the changes. I don't have a special script to do it, but I think Kim does. :) I see that this changeover didn't seem to make 3.8 M6...I assume it's working ok for the subsequent integration builds. Is it ready to resolve? Thanks. (In reply to comment #17) > I see that this changeover didn't seem to make 3.8 M6...I assume it's working > ok for the subsequent integration builds. Yes, March 19 was after M6 (M6 was on the 16th), so it wasn't in that milestone. Unfortunately, I'm not sure we've had a successful IBuild since March 20th (the day I did the integration). Right now the platform / equinox / p2 builds are in flux due to Kim's departure from IBM and the platform team's decision to move the builds to the foundation. > > Is it ready to resolve? > > Thanks. Let's leave this open until we are sure the integration worked. (In reply to comment #11) > * The one exception is org.eclipse.ecf.provider.filetransfer.httpclient where > the 3rd digit was updated from 1 to 200. I checked the integration build 'I20120411-2034', it contains 'org.eclipse.ecf.provider.filetransfer.httpclient' with 3rd digit '200'. With this bundle pausing the downloading based on ecf and httpclient works well. (In reply to comment #19) > (In reply to comment #11) > > * The one exception is org.eclipse.ecf.provider.filetransfer.httpclient where > > the 3rd digit was updated from 1 to 200. > I checked the integration build 'I20120411-2034', it contains > 'org.eclipse.ecf.provider.filetransfer.httpclient' with 3rd digit '200'. With > this bundle pausing the downloading based on ecf and httpclient works well. Thanks Meng! and Thanks Scott and the ECF team for the build. |