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
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev
|