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 _______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
