[
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