[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [p2-dev] ECF filetransfer contribuiton for m3
- From: Scott Lewis <slewis@xxxxxxxxxxxxx>
- Date: Thu, 29 Dec 2011 18:18:16 -0800
- Delivered-to: email@example.com
- User-agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
I've just examined the Eclipse 3.8 M4 release, and apparently the ECF
filetransfer contribution still hasn't been incorporated into M4 (it's
using the Helios version still).
I would appreciate use of the latest ECF filetransfer in p2/equinox...so
that consumers can get the performance benefits done for the bug listed
We've now got a new maintenance release...ECF 3.5.4...no changes for
filetransfer, but better to use the most recent released version. The
p2 repo for this version is located here .
Please let me know if more info is needed.
On 10/3/2011 5:56 PM, Scott Lewis wrote:
As requested, ECF has produced a new release build and updated the
bug. Please see here
for incorporation into p2 integration build...for testing as discussed
On 9/26/2011 11:24 AM, Scott Lewis wrote:
As Pascal requested, here is a bug for coordinating the build and
incorporation of the connection-reuse enhancement into p2/Equinox:
Further, here is the ECF enhancement for creating a provider based
upon httpclient 4.1 that Pascal referred to:
WRT to the actual integration and use of new providers (i.e.
httpclient 4.1, if that's what is desired):
ECF contributor Thomas Joiner has already implemented an ECF provider
based upon httpclient 4.1...see
upon my understanding, httpclient 4.1 should/could solve a number of
outstanding issues with httpclient 3.1 (which the ECF filetransfer is
currently based upon)...including better/non-workaround support for
NTLM v2 proxing...better support for proxies in general...among other
Realistically...I expect, however, that the new provider could have
regressions of it's own...that may take some amount of testing and
debugging...perhaps only to be detected when testing/using milestone
releases prior to 3.8. Before ECF/I start the integration, I will
need commitment from the p2/Equinox team that there will be some
support for helping to test and debug the new provider, as otherwise
ECF does not currently have resources to commit to this. The good
news, of course, is that we can always continue to use the existing
providers (httpclient 3.1 or the JRE-provider)...or fall back to them
at any time if needed...via a simple switch.
So...before beginning the integration and testing of the work on bug
251740...if this is important enough to the p2 team...that it be
added as an explicit plan item...and that resources be identified to
assist in the testing.
One other question: I believe that httpclient 4.1 and the provider
are both dependent upon JRE 1.5 (I haven't looked yet at exactly
Another possibility is to create a provider based upon Jetty Client
(some/appropriate recent version). But if this were preferred there
would have to be some resource identified to create the ECF provider
(not a difficult chore technically, but obviously takes familiarity
with Jetty client api).
On 9/23/2011 8:38 AM, Scott Lewis wrote:
In order to reduce time and space costs for filetransfer, ECF has
recently added support for httpclient connection reuse
This change is in great need of regression testing 'in the wild'
(i.e. with a variety of proxy environments, other network environs,
etc). We have done all the testing that we have available to us,
and I think now would be a good time to get it into m3. Note that
there is a new system prop to disable the connection reuse...in case
some major regression arises.
Now that p2 is consuming from ECF's repos, how should this
contribution/integration proceed? (as we don't yet have it in an
ECF release...since it's been released since our 3.5.2 release in
p2-dev mailing list
p2-dev mailing list
p2-dev mailing list