Thanks David and Gunnar for the explanations, suggestions and comments!
We will use the safe option – submitting the modified versions in the Virgo local repository. They will not reach the common repository – for now we are not
going to contribute them there as the code using them is not in the release train.
Regards,
Lazar
From: orbit-dev-bounces@xxxxxxxxxxx [mailto:orbit-dev-bounces@xxxxxxxxxxx]
On Behalf Of David M Williams
Sent: Wednesday, November 21, 2012 9:22 PM
To: Orbit Developer discussion
Subject: Re: [orbit-dev] Modifying third-party projects
I'll start off stating I don't like the idea of us putting modified OS code into Orbit, or the common, Simultaneous Release repo. As well intentioned as it is, There is always
some risk that one person's fix may break someone else so it is far better to get a "real fix" and maintenance update from the third party if at all possible. And, I mean this in the sense that even a perfectly correct, valid fix, can still break someone else
who may have worked-around the bug, or may simply have not yet accounted for the "correct behavior". And, if there are two OSGi bundles "in the wild", with same ID and version its always a little unpredictable which a client/customer might end up with, so
is hard to do long term support for those clients/customers (not knowing what they have) and once "in the wild" is basically impossible to fix dueling bundles or installs. Gunnar's case of IP restrictions is one necessary exception, but in general, our mission
in Orbit is not to fix other project's code.
All that said, here's a blast of other misc., thoughts on the topic.
I don't think our Orbit build currently handles the case of exact same name, exact same version, differing only in qualifier .... just going by some old memories.
So, to rename the bundle id seems like a good idea for several reasons. (our builds, clarity to consumers, etc.).
But additional steps should also be taken. You can specify relatively arbitrary name=value pairs on package exports, and consumers can also specify they require a package with that property. I
think there is a way to say it is "mandatory", but would have to look up the specs. Then, even if you put yours in Virgo and the publically available version in Orbit, the Orbit packages should likely have a similar property added (not mandatory) in case anyone
specifically does not want the "fixed" version .... its always hard to know the effect of fixes, for all possible consumers.
We started to do something similar with 'javax.activation', because we had one implementation (same version) from Sun and another from Apache Geronimo. There we used
javax.activation; version=1.1.0; vendor=sun
and
javax.activation; version=1.1.0; vendor=geronimo
to distinguish the two so those using "import package" could specify which they wanted, if they cared. It ended up we could not build both at once, without radically changing our build (to be done
in several passes, or in several pieces) so we ended up only building/providing one of them after all. (the key word doesn't have to be "vendor", it could be "implementer" or similar, and the value could be "virgo" and "apache" for example.)
If you think these are such critical and correct fixes that everyone in the world (or, at least on the release train) should use them, then I'd suggest you post a note on cross-project and find
out if anyone else uses them, and what their thoughts are. You should have bugs open that show your fixes are considered valid by the third party and a commitment they would be in future maintenance release. (Though, in this case, I'd wonder then why we would
still need both).
If you think its pretty specific effect to Virgo or an official maintenance release fix will be out soon, then I'd suggest you just put them in your Virgo repo/build ... though, you are on release
train, they will all in up in the common repo, so you'd still want to use the package properties, and a different bundle ID if feasible.
There is also a section on "pre-release" qualifiers in our wiki;
http://wiki.eclipse.org/Orbit/Adding_Bundles_to_Orbit#Special_Detailed_Notes_on_the_RC_case.
I do not want to dictate the right answer here ... we are a "committer ran" project! ... so am happy to hear others thoughts and ideas on the topic. Maybe there is no one right good answer and
its just picking the least worse answer? I'm just very cautious when it comes to having multiple version "in the wild" and risking breaking others (even with a valid, correct fix). You'd want to get some larger group by-in before that.
Thanks for raising this important issue.
From: Gunnar Wagenknecht <gunnar@xxxxxxxxxxxxxxx>
To: orbit-dev@xxxxxxxxxxx,
Date: 11/21/2012 10:36 AM
Subject: Re: [orbit-dev] Modifying third-party projects
Sent by: orbit-dev-bounces@xxxxxxxxxxx
Hi Lazar,
Am 21.11.2012 15:42, schrieb Kirchev, Lazar:
> What is the correct approach here? Add the fixed in another version? Or
> in a new project? Or not adding at all to Orbit until a version
> containing all the fixes gets released officially from the third party –
> in this case the modified bundles could safely reside in a Virgo project
> repository?
We have a similar issue for MongoDB. In this case we *have to* publish a
modified version of the library for IP reasons. According to the naming
policy I named the bundle org.eclipse.orbit.mongodb to indicate that
this is a custom bundle and not the official project library. I kept the
bundle version the same as the original version well as the version of
the exported packages.
The modified source is checked in to Orbit as well together with the
modified binaries and published as part of the source bundle.
-Gunnar
--
Gunnar Wagenknecht
gunnar@xxxxxxxxxxxxxxx
http://wagenknecht.org/
_______________________________________________
orbit-dev mailing list
orbit-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orbit-dev
