Re: [e4-dev] Dependency Preference and Versioning

[Robert Wloch <robert.wloch@xxxxxxxxx>]

I've been following this interesting discussion from the beginning. Over
the days a couple of thoughts crossed my mind.

Comments below.

Ed wrote:
> This question drives at a key point: evolution.
> [...]
> Similarly, if I have a package that depends on org.eclipse.swt and then
> later I add a visible dependency on org.eclipse.swt.custom, clients will
> be broken unless it's re-exported.
> [...]
> How can we ensure that we stay on the golden path?

If I understand your swt example right then I just coded something similar
for one of our customers. One of our chief software engineers told us to
use R-B with re-export and it looks like we're using it to create something
like depedency inheritance (DI) on bundle level.

Imagine a bundle A "foo.technology" containing some basic control code.
Additionally, there's a "foo.technology.model" bundle B) which is required
by A). In the model of bundle B) a couple of enums are defined, that will
be returned by some methods in bundle A). Apart from that no API of B)
will be used in any other bundle other than A) resulting in A) using the
model of B). Having some other bundle using the API of A) it actually
depends only on A). But since the enums of B) are required one needs to
carry over the dependency of A) on B) by reexporting it in A). This way,
R-B A) in some other bundle inherits the dependency on B).

As Nice as DI would be, currently it breaks the JAR export of a bundle.
With direct R-B of B) in any other bundle exporting to a JAR does work.
But for the future DI might be a good thing to have. Thoughts?

> [...]
> Ed



Tom wrote:
> The practice of reexporting dependencies is orthogonal [...]
>
> If a client needs API from bundle Y then they should put their own
> dependency on bundle Y.

That's what I just realized when I tried to export our bundles to JARs. It
won't work well for some bundles when using R-B with re-export. ;-)

> [...]
> Tom



Boris wrote:
> [...]
> In this context, I think it is useful to remind everyone that the normal
> backwards compatibility promise for Eclipse is that we will ensure binary
> compatibility, i.e. if you don't recompile your bundle will continue to
> work in newer versions.
> [...]
Maybe this promise could be restricted to be valid for a certain major
version of eclipse. Please, excuse me for wandering from the subject a
little bit with the following:
Promising any kind of compatibility has made it difficult for at least two
huge companies to keep up with new technologies. Can you think of them?
Right: Microsoft and Intel. Sure, they are still market leaders, but others
do have better products, because with new releases competitors can start
anew, if they want.

Take the K Desktop Environment, for instance. AFAIK, they neither have a
software nor binary compatibility promise, yet the KDE desktop is more
powerful and configurable than WinXP and MAC OS together, IMHO. Although
it's not perfect yet, with KDE 4 fundamental changes in the framework have
taken place making previous KDE software incompatible with the new version.
And as far as I remember the same was the case when KDE 3 was to supersede
KDE 2. But no user really cares if the result of such changes is more
perfect compared to what you had before.

So if there's a misconception it should be replace with something better IMO.
What do you think?

> [...]
> Boris



Boris wrote:
> Interesting...
>
> Neil wrote: "there are NO circumstances where you need to use
> Require-Bundle, and you should not use it in any new plug-in. It exists
> only for legacy compatibility."
>
> Which makes me wonder... how are you supposed to express dependencies
> between code when some of it is not written in Java, but in JavaScript,
> Ruby, or Haskell?

AFAIK, in the runtime tab of the Plug-in editor one can export non-Java
packages. Ain't that the function you're wondering about, or am I mistaken?

>
> Boris



Jeff wrote:
> People who use Require-Bundle are doing so at risk of having to change
> their manifests later if packages move.

What I've learned from this discussion is that the R-B feature is some
left-over from the Eclipse mid-ages. Ok. Well, it's still in the IDE for
compatibility reasons. Alright. However, being a left-to-right reader with
R-B being placed left of I-P the Plug-in editor subconsciously suggests me
to prefer R-B over I-P. Additionally, there's no warning telling me to
keep my fingers away from that box and it's buttons. So how should one
know when not knowing Eclipse since version X.mid-ages?

> [...]
> Jeff



Alex wrote:
> Agreed, you can bet my team won't be updating our 150+ plug-ins anytime
> soon, if it ain't broke we don't fix.
>
> If you really want to see people migrate you need to provide a
> braindead-simple migration path.
>
> Ideally a PDE warning marker on the manifest and a quick-fix as well as
> new UI in the manifest editor. (A "Do The Right Thing" button...)
>

Being more or less on the client side as Alex, I aggree with him. Maybe
it's time for me to take a deep look into Eclipse sourcecode to code such a
warning at the right place. ;-)



Cheers,
Rob