Re: [orbit-dev] Modifying third-party projects

[David M Williams <david_williams@xxxxxxxxxx>]

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