Community
Participate
Working Groups
Via bug 297742, ECF filetransfer has been enhanced to reuse httpclient 3.1 sessions, to reduce memory usage and connection setup time when downloading many files. The patch attached to that bug (202206) has been applied, examined, tested (via ECF's filetransfer tests) and pushed to master http://git.eclipse.org/c/ecf/org.eclipse.ecf.git/commit/?id=3bfdbc0f7d63cbb1af17c87e503783395c25fcfe It would be best to integrate this fix into p2/Eclipse 3.8 milestone 3...and benefit from testing in the wider community, where many more/other network environments and use cases can be tested with this change. This bug can be used to coordinate between the ECF team and the p2 team, so that a) a new p2 repo of ECF filetransfer can be created (by ECF team), and made available for b) incorporation into Equinox/Eclipse build. ECF can do a build fairly easily/quickly...whenever it would be needed...but we need a couple of days prior notice to make sure we have the people available to support it. One initial question for p2 team...does this initial integration/milestone build have to be signed...or can they be unsigned? For reference, ECF's builder is here: https://build.ecf-project.org/jenkins/
Could we shoot for next week? I would prefer to going with signed content to avoid some ppl to choke. If this can't be done under reasonable time, we could go without it with the promise that it will be done by the time the milestone comes. Does that work for you?
May I ask which Equinox milestone and which ECF branch we are talking here? Ideally Equinox would consume a regular ECF release.
(In reply to comment #2) > May I ask which Equinox milestone and which ECF branch we are talking here? > Ideally Equinox would consume a regular ECF release. Hey Markus. WRT Equinox milestone...my assumption has been m3 (about 5 weeks from now, right?). wrt ECF...master now has these changes...but they were released after ECF 3.5.2 (late Aug). I agree that Equinox 3.8 will eventually consume a regular ECF release (probably ECF 3.5.3...or perhaps 3.6 in the spring), but I think in the short term (next few weeks), it would be a very good idea to get this change into Equinox m3...so that it can be released in m3 and tested in a variety of network environments (which is the main thing that cannot be tested very well...even by the Equinox team). But I anticipate that once we/ECF do a release...e.g. 3.5.3...that from that point forward p2/Equinox will consume *that*.
(In reply to comment #1) > Could we shoot for next week? > I would prefer to going with signed content to avoid some ppl to choke. If this > can't be done under reasonable time, we could go without it with the promise > that it will be done by the time the milestone comes. > Does that work for you? Let me find out. If done next week, when (day/approx time) would the signed ECF repo be needed?
The submission for I build is done on Monday evenings for a build on tuesday mornings 8am EST.
(In reply to comment #5) > The submission for I build is done on Monday evenings for a build on tuesday > mornings 8am EST. A new ECF build/repo has been created that includes the fix for bug 297742. That repo is available here: http://download.eclipse.org/rt/ecf/3.5Test/site.p2 This can/should be used for the Equinox/p2 weekly integration build (for week of Oct 3). The version qualifier for the ECF bundles is: v20111003-2243 The git tag for this build is R-Release_HEAD-sdk_feature-38_2011-10-03_22-39-45
Are there any p2 code changes here or are we just consuming the new bundles?
(In reply to comment #7) > Are there any p2 code changes here or are we just consuming the new bundles? I don't expect that there are any p2 code changes...as the ECF API has not changed...only the implementation (and that was in Sept 2011)...but I suppose it would be better to confirm with whomever is maintaining the p2 code to be sure.
Ok, I've created bug 367794 with patches for the p2.map file and the build.properties for the source generation for the Platform feature. We'll get Kim to release them both at the same time so we don't break anything.
Kim has released the patches in the referenced bug so the next integration build will contain this change.
