|
Mickael,
I believe this kind of direction should be given by the planning
council. What you're stating is your opinion (or a suggestion for
a change in the long established direction), but we've already
heard David's opinion on this, and it was one of caution. Having
managed release trains for years, I put a heck of a lot of weight
in David's informed opinions. So at this point I don't feel we
(you) should not be prescribing a new solution to replace the old
solution, not until the planning council has determined and agreed
that this new solution does in fact solve enough old problems
without introducing more new problems compared to the old
solution. Of course I have no issue with discussing new
approaches, but best we consider carefully any new path we take,
and best we not prescribe a solution before its fully baked. In
other words, I'm cautioning you not to draw a final conclusion.
I've already pointed out some of the tricky questions that will
arise, but they were far down in a long note, so I'll repeat them
here:
Don't include Orbit bundles in your project's features. Sounds
like a great idea, but begs endless questions, and while solving
a problem might well introduce more new problems than it
solves. The first question (as Carsten points out) is how do
these things end up in a repository, and if they are in a
repository somehow, how are they categorized? It's hard to get
them in and once you do, they're categorized poorly. The next
question is, how do they end up in the release train, if the
projects that need them don't contribute them? Directly from
Orbit you say? But which ones should be pulled in from Orbit
and how is that discovered? Are those the ones the projects
have tested against? Then there is the question of whether an
installation is deterministic if the bundle version isn't
pinned? It's not; it will depend on what's in the repos that
are available at resolve time. But Gunnar argues that even
packages are not deterministic, which I think is false: if the
feature pins the bundle version and the package requires the
feature, then the pinned bundle is definitely in that package.
But regardless, Gunnar's important point is that the runtime
wiring seems kind of non-determinstic, and while uses
constraints might help, who the heck understands those well,
what tooling produces it correctly for us, is that nicely
integrated in PDE, and will it be properly maintained (in
contrast to lower bound constraints which you can pretty expect
will remain on whatever stale version they were initially set
to). This may well be the right direction in which to go, but
getting there isn't going to be even half the fun...
Regards,
Ed
On 31.03.2017 11:53, Mickael Istria
wrote:
On 03/31/2017 09:25 AM, Ed Willink
wrote:
Hi
It is currently necessary to rebundle Orbit bundles because
Orbit is not included in the xxx release repo.
One can (and should) include the Orbit bundles in the p2 repo,
but not include them in the feature. So the dependencies are
available at install-time, but not constraining the resolution.
The category.xml easily allows to add any bundle to a p2 repo,
those could be Orbit ones.
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
|
