[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
| Re: [cross-project-issues-dev] Is there a reason to	have	org.apache.commons.logging 1.0.4 in the platform? | 
Hi Scott,
I tried to vote on this bug and leave a comment about the logging 
version. Did you disable voting for ECF bugs? I can not find that link ;-(
Cheers
/Eike
----
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Am 20.05.2010 16:44, schrieb Scott Lewis:
Hi Stephane,
Yes.  I've seen the 'strongly encouraged' notice.  Perhaps to move 
this along you would like to contribute the implementation and testing 
of the HttpClient 4.0-based provider?  You can do so via this enhancement
https://bugs.eclipse.org/bugs/show_bug.cgi?id=251740
If you or others wish to contribute to this, please notify the ECF 
team as we already have some partial work done and can provide other 
support.
Scott
Stéphane Bouchet wrote:
FYI,
Looking in the httpclient page :
"Commons HttpClient 3.x codeline is nearing the end of life. All 
users of Commons HttpClient 3.x are strongly encouraged to upgrade to 
HttpClient 4.0."
looking at the dependencies, the last 4.0.1 comes with 
commons-logging 1.1.1 :)
Scott Lewis a écrit :
FWIW,
Yes...as Pascal and John A indicated, ECF is using the apache 
httpclient (3.1) and this dictates a dependency on commons logging 
1.0.4.
We (ECF, etc) would be completely willing to move some other 
mutually agreed upon version of commons logging, but there are some 
important subtleties:  Since it's httpclient that depends upon 
1.0.4, once a replacement version of commons logging was selected, 
someone would have to look for/test for regression in httpclient 3.1 
in order to do so...since there's unfortunately no guarantee that 
httpclient 3.1 doesn't have a hard dependency on 1.0.4 (I'm not 
saying there is or anything...just that we don't know, and 
discovering something like that could be dramatically bad if the 
change was done cavalierly...especially this late in the game).
All this by way of saying...I think aligning on a version would be 
fine (I mean...other than the version upon which we're aligned 
now)...but it's unfortunately not trivial for us to safely change 
this dependency...particularly without some available resource to 
check/test for possible regression.
Scott
Martin Taal wrote:
This topic (commons.logging 1.0.4 being supplied and other projects 
needing 1.1) has also cost me several hours and many builds. I 
would not be surprised if it also cost others a few hours (so we 
talk about mandays of work).
So from my point of view it would be great if Eclipse projects can 
align on the version used for such a base jar file as 
commons.logging....
.
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Cell: +31 (0)6 288 48 943
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@xxxxxxxxxxxxxx - mtaal@xxxxxxxxx
Web: www.springsite.com - www.elver.org
Pascal Rapicault wrote:
This is being brought in by org.apache.commons.httpclient which is 
used by p2 (through ECF)
Do you know if they are compatible with each others? Did you try 
running with just the 1.1 version? Remember that at Apache, 
version numbers don't necessarily have the same semantics than 
eclipse. Actually worse, ppl just bump versions without really 
thinking.
At this point p2 ships 1.0.4 because we don't know any better. 
However given all the problems we have had around transports in p2 
and the time it took us to stabilize I'm really not inclined to 
change that just for source issues of a third party bundle.
On 2010-05-20, at 6:42 AM, Eike Stepper wrote:
Hi,
I noticed that many projects depend on o.a.c.logging 1.1.x+ while 
the platform still includes 1.0.4. That causes duplicate bundles 
and some build problems regarding the respective source bundles. 
Would it be possible to agree on a common version?
Cheers
/Eike
----
http://thegordian.blogspot.com
http://twitter.com/eikestepper
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev