RE: [orbit-dev] Modifying source of a 3rd party library

["Oberhuber, Martin" <Martin.Oberhuber@xxxxxxxxxxxxx>]

Hi Simon,

 

I agree that it's good to work on a process for patches. Thanks for your suggestions!

 

6) Recompile with extreme caution paying special attention to the existing compiled codes class format.

I think that I actually left the original binary JAR as-is and only replaced the two .class files which carried my patch (that is, in the Orbit CVS repo I only committed the two modified .class files). When creating those two .class files, I used the minimum possible Java version for compiling, to ensure that I didn't break the ExecutionEnvironment promise (which was J2SE-1.2 at that time).

 

Cheers,

--

Martin Oberhuber, Senior Member of Technical Staff, Wind River

Target Management Project Lead, DSDP PMC Member

http://www.eclipse.org/dsdp/tm

 

Any thoughts?

"Oberhuber, Martin" ---02/10/2009 10:43:54 AM---Hi Simon,

From:	"Oberhuber, Martin" <Martin.Oberhuber@xxxxxxxxxxxxx>
To:	"Orbit Developer discussion" <orbit-dev@xxxxxxxxxxx>
Date:	02/10/2009 10:43 AM
Subject:	RE: [orbit-dev] Modifying source of a 3rd party library

---

Hi Simon,

I've had a similar situation with Apache Commons Net. What I did at that time, was file CQ's for the two bugs to be fixed (I.e. patches to the code), and apply them to the Orbit version of the lib. Since it was only bugs in the implementation with respect to reliability / deadlock avoidance, I did not change the version of the lib (it remained 1.4.1 -- only the qualifier changed). The CQ's for the patches were:

https://dev.eclipse.org/ipzilla/show_bug.cgi?id=1752
https://dev.eclipse.org/ipzilla/show_bug.cgi?id=1753

By referencing the Apache JIRA bug, there was some track of records that the patches would eventually be integrated into the next Commons Net release. On the CQ's, we also clarified provenience and legal status of the two patches, and thanks to the CQ's they were always documented on our IP log.

http://www.eclipse.org/projects/ip_log.php?projectid=dsdp.tm

I'm not saying that this was the ideal process to follow, but it worked well for us and I'm glad we had the fixes in our products based off Eclipse.

Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm

---

From: orbit-dev-bounces@xxxxxxxxxxx [mailto:orbit-dev-bounces@xxxxxxxxxxx] On Behalf Of Simon Kaegi
Sent: Montag, 09. Februar 2009 18:08
To: Orbit Developer discussion
Subject: [orbit-dev] Modifying source of a 3rd party library

I've run into a situation with -- https://bugs.eclipse.org/bugs/show_bug.cgi?id=262641

One of the 3rd party libraries we use (and is no longer the active stream) has a bug in it that is likely not to be fixed.
It is fixed in a future release however due to JRE requirements we're unlikely to adopt it until the whole platform requires Java 5.

The fix is easy enough to make and I'm wondering if we have or perhaps should have any process around this sort of thing.
Any thoughts?

-Simon_______________________________________________
orbit-dev mailing list
orbit-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orbit-dev