Tom,
Comments below.
Thomas Watson wrote:
The practice of reexporting dependencies is orthogonal to the
discussion of package versioning IMO.
I think it's not just your opinion. It's a fact. :-)
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.
That mean the solution involves importing packages and then
re-exporting packages.
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.
Yes, once one goes down the dark path, things get worse.
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.
Yes, that was an unfortunate choice we made in EMF way back in the
early days. Much has changed since then...
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.
Well, that's not entirely true. If API X depends on API Y and the
clients needs API X, then they are forced to consume API Y as well.
The issue comes down to whether they need to list their X and Y bundle
dependencies. Now that we have version ranges (not something that we
had in 2002), it seems clear that forcing them to have separate
dependencies on X and Y with separate ranges is better. Isn't 20/20
hindsight a great thing?!
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.
Some might argue that it's convenient, but it's now clear, with ranges,
that there is a cost...
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'm not sure if there is a new getter in a class or interface that
depends on a new package, if the client aren't always affected...
I think the problem is there is a disconnect between the compiler and
the runtime behavior in some cases.
Yes, I've had cases where there really seems to be no good reason why I
should have a dependency but I'm told by the compiler it's indirectly
needed. I suppose a new overload might cause something like this too.
I wonder if the cases I've described are ever actually runtime problems.
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.
Yes, that exactly my point. And once we go down the dark path, it
seems to lead to yet more darkness. So the question of whether the
type of change I've described represents a real problem at runtime
verses "only" a compile time problem seems important. After all,
messing up the frameworks so that clients don't have to add a
dependency at their end is probably a necessary evil for binary
compatibility, but is source compatibility an absolute requirement...
I hope it's clear though that I agree with what Chris has proposed.
I'm just highlighting that the fine granularity is likely to make the
type of situation I've outlined arise more often, perhaps resulting in
yet more re-exporting of packages than we have right now of
re-exporting bundles...
Tom
 Ed Merks
---01/14/2009 08:55:39 AM---This question drives at a key point:
evolution. Even if we start with the best of intentions based on the
best of designs---I
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
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev
|
