Ed, thanks for cross-posting. I seem to have missed Mickael answer below. Mickael, my point to the zero predictability about packages was not related to the technical possibilities but to how the process is implemented today. If it was predictable there wouldn't be three different versions of http client/commons in the Oxygen Java/Committers package. With so many projects contributing to the repository it's just not predictable. Quite a bit communication/synchronization effort is necessary to harmonize versions across feature.xml of all participating projects.
-Gunnar -- Gunnar Wagenknecht [email protected], http://guw.io/ > On 31. Mar 2017, at 12:28, Ed Merks <[email protected]> wrote: > > 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] >> <mailto:[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 >> <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
_______________________________________________ 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
