Thanks David and Gunnar.
From your responses I think that “hot patching” on our side is not really an option. Right now it looks like the issue is isolated enough and easy to work around
on our side; so I tend to simply say “it is what it is” , add the workaround to TM and recommend others to implement a same workaround where needed.
The CQ and the iplog entry seem to be good places for such a notice.
I don’t think the issue warrants any extended effort on our side (such as late builds, express IP reviews, extra stress etc). If Commons really releases within
a week (which I don’t believe after following the project for some years) there is a chance that the next version will introduce other issues.
So – I’ll first add the workaround to TM / RSE, do more testing, then add the notes on CQ and iplog (pointing to the actual TM / RSE code with the workaround)
, then send a quick E-Mail to cross project and reconsider in a week or two.
Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Architect – Development Tools,
Wind River
direct +43.662.457915.85 fax +43.662.457915.6
From: orbit-dev-bounces@xxxxxxxxxxx [mailto:orbit-dev-bounces@xxxxxxxxxxx]
On Behalf Of Gunnar Wagenknecht
Sent: Wednesday, May 15, 2013 2:45 PM
To: Orbit Developer discussion
Subject: Re: [orbit-dev] Added commons.net 3.2.0 to Orbit
Hi Martin,
Just FYI, since the issue has been fixed in upstream SVN (but not released), one option would be patching the one affected class file
in Orbit and calling it Commons Net 3.2.0.1 to indicate the patch.
I think that's not sufficient. If we modify a library the bundle has to get an "org.eclipse.orbit…" namespace plus some more meaningful qualifier than ".1".