What you need to realize is that whether the repo is validated or not, the remediation will still happen when the user try to install something (or install
a new version) that is incompatible with what is already installed. For example with this hypothetical scenario:
Imagine the user has the platform and GMF installed with a tight dependency on the platform. When the user decides to install the new version of the
platform, then the installed version of GMF is no longer suitable, so the remediation will kick in. This will happen whether the p2 repo the user is installing from is validated or not. This is simply rooted in the fact that the user only wants to install
one particular component without any desire to understand the dependencies.
The only case where the user would not see any remediation is the check for updates. This is because in Kepler we’ve improved the logic to look for the “highest
applicable version” of each IU rather than systematically proposing the highest version.
I would assume that if we were to really provide frequent updates, then users would use the check for updates.
Now on the details of remediation and p2 resolver.
I agree that the remediation can be slow, and this is dependent on the number of repos you have enabled. Then there is the uncompressible time it takes to resolve
dependencies and figure out the solutions and for this whether the repos are validated or not does not matter. The p2 resolver has been built to deal with inconsistent repository content , and it has been proven to scale by participating in dependency resolver
competitions. So to answer your question, you can give a mess of dependency and p2 will still figure out something.
[mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Ed Willink
Sent: July-03-13 5:40 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] 6 month release cycle
P2's remediation is very impressive but unfortunately it is dreadfully slooow.
If the repo is not validated, every user is going to have to have a tea break while P2 fixes things up.
And if the repo is unvalidated, there will be a lot of fixing up. I would be amazed if P2 could sort out the anarchy.
So the users will wait a long time, get given an irritating please confirm this magic solution that excludes your favourite product dialog.
Eclipse will become a laughing stock.
On 03/07/2013 10:31, Pascal Rapicault wrote:
I like the approach of everybody contributing their latest release to a new kind of repo.
However I’m wondering what happens when the dependencies are not aligned. For example GEF ships a new version but GMF ranges don’t allow for it. Does the repo
contain two versions of GEF or is GMF not included?
Now if we step back, the issue I’m describing is caused by the fact that the release repo is validated (validated means all the IUs in the repo can be installed
together, to the exception of a couple IUs) in order to reduce the number of install time dependency resolution errors. However I’m thinking that now that p2 has the remediation mechanism , the necessity to have a validated repo is lessened since at install
time p2 will figure out the right set of things to install (as well as things to uninstall and update), and in the case of a check for updates it will only propose the versions that can work together.
The advantage of shipping a non validated repo is that it reduces the burden of integration since the process of creating the repo is just a mirroring one.
All that said, I think that in addition to this new repo, there would still be value in creating a release repo where the content is validated and more stable.
Finally another thing to consider is which repo would users build against?
All projects contribute the latest finished release they have, dependencies are reconciled, some cross-testing happens and it’s
out. Every month, there is a repo with versions of all participating projects that are known to work together. Users are happy because they only need to check for updates from the aggregate repository that delivers new stuff to them frequently. Projects are
happy because they can set schedules that make sense for their needs and if they miss one deadline, the next opportunity is not that far away.
I think this is exactly what projects and users want.
Being up-to-date makes aggregation repositories (look at maven central) valuable.
Xtext Commiter / Build Engineer
Mobile: +49 (0) 151 / 17 39 67 07
Telefon: +49 (0) 431 / 990 268 70
Fax: +49 (0) 431 / 990 268 72
Am Germaniahafen 1
Amtsgericht Dortmund, HRB 20621
Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens Trompeter, Sebastian Neus
Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus
cross-project-issues-dev mailing list
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3345 / Virus Database: 3204/6458 - Release Date: 07/02/13