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.
--
Mickael Istria
Eclipse developer for Red Hat Developers <http://developers.redhat.com>
My blog <http://mickaelistria.wordpress.com> - My Tweets
<http://twitter.com/mickaelistria>
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
