Skip to main content

[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




Back to the top