The practice of reexporting dependencies is orthogonal to the discussion of package versioning IMO. It is true that we cannot prevent clients from using require-bundle. If a package needs to be split out into new bundles then there are steps that need to be taken to ensure the "complete" package gets merged back together and exported as a "complete" package from the original bundle the package was contained. This is an unfortunate requirement to ensure our bundle symbolic names preserve their API contract. And this situation is only exacerbated by the practice of re-exporting bundles.
On the re-export practice. I do not agree that bundle X should simply re-export a bundle Y if bundle Y contain API that visible from bundle X's API. This only leads to the propagation of large sets of API to your clients that they will not need but they are forced to consume them because you have re-exported your dependencies. If a client needs API from bundle Y then they should put their own dependency on bundle Y. They should not be lazy and depend on bundle X to reexport the world for them. Ed, you say all clients will be broken if you don't re-export such requirements. At runtime a client which requires Bundle X will only be broken if it actually uses API from bundle Y. If it actually uses API from bundle Y then it should declare that dependency itself. I think the problem is there is a disconnect between the compiler and the runtime behavior in some cases. There are cases where the compiler will fail to compile some code unless you do the re-export trick or explicitly require bundles which you don't actually use. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=122915. This has lead to the proliferation of the re-export practice. I think that is unfortunate. Tom From: Ed Merks <[email protected]> To: E4 Project developer mailing list <[email protected]> Date: 01/14/2009 08:55 AM Subject: Re: [e4-dev] Dependency Preference and Versioning This question drives at a key point: evolution. Even if we start with the best of intentions based on the best of designs---I do believe that package dependencies are finer grained and more flexible---as things evolve, they tend to get messed up again. E.g., even if we have package dependencies, there's no stopping clients from having bundle dependencies instead, so moving a package from one bundle to another bundle on which clients don't already have a direct dependency will be a breaking change. 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. So in both cases, the sins tend creep back in. Does all this represent a design flaw? How can we ensure that we stay on the golden path? Cheers, Ed Danail Nachev wrote: If we match the package version with the bundle version, what happens to the package version, when the package is moved to other bundle? I think that API tools gives us (or it will give us) enough power to evolve the package version separately from the bundle version. BR, -- Danail Nachev Senior Software Engineer/Development Tools ProSyst Labs EOOD ------------------------------------------------- stay in touch with your product. ------------------------------------------------- Paul Webster wrote: I would be happy with Import-Package instead of Require-Bundle. And as per discussions in some of the other lists, we would need to version our packages if this was to be our best practice But I'm also for keeping it simple, match the package version to the bundle version. PW _______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev _______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
<<inline: graycol.gif>>
<<inline: ecblank.gif>>
_______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
