Community
Participate
Working Groups
Created attachment 231490 [details] screenshot of pr in MPC I am using Kepler Standard package RC1. Using MPC I tried to install the JBoss Tools (Juno) version to test out the new p2 remediation screen. The dialog box to Confirm Selected Features seems to indicate that I will uninstall Eclipse Standard and install JBoss Developer Studio. It seems confusing that I will actually uninstall Eclipse? After I select confirm, lots of software is install but now I can no longer run Eclipse. This just doesn't feel good.
This is because the product in which you are using MPC is missing some properties to help p2 identify that there is indeed a "product" installed (basically some IU needs to be flagged). For EPP, this has been uncovered before and is being tracked in https://bugs.eclipse.org/bugs/show_bug.cgi?id=406985. In the meantime you can try to pick up SDK RC1 or later, install MPC and notice that you will not be proposed to uninstall eclipse.
From reading the EPP bug I take it that this will be fixed with bug 408996? Or is there something wrong with the new Standard package that we need to file a bug for?
There is nothing left to do on the MPC front. Closing as a dupe of 406985. *** This bug has been marked as a duplicate of bug 406985 ***
(In reply to comment #3) > There is nothing left to do on the MPC front. > Closing as a dupe of 406985. > > *** This bug has been marked as a duplicate of bug 406985 *** I am reopening this bug since I want it tracked as part of MPC. I was using Standard RC1 so this problem has not been fixed in RC1.
I think we need to make a decision on how to proceed with the p2 remediation. I hope we all agree the current RC1 situation is not acceptable given the bug 406985. The current plan is that this bug gets fixed in RC3 so MPC would have less than a week to test but no option to get any additional fixes if we find a problem. My main concern is that we are not giving any time for the Marketplace community of solution listings time to test out this new feature. I really don't think it will be a good situation if solutions start to not be install-able due to the p2 remediation. Carsten, any comments on what are the options moving forward?
(In reply to comment #5) Hi Ian, When Pascal said "fixed in SDK RC1" you should install the original classic RC1 (or 4.3RC2 which was built last week). I mean the one from the Eclipse Platform team, and not the one which I build for EPP. The original SDK should have the required property, so I don't think MPC testing is blocked: http://download.eclipse.org/eclipse/downloads/ Independent of MPC, the question is do we have sufficient tooling to (1) build the Eclipse.org packages the way they need to look like - ie with the required property - and (2) to explain to product builders other than Eclipse.org how they can update to 4.3 with remediation and ensure their products have the required property. Pascal's original comment "just build with the new publisher and it will do the right thing" did apparently not work. The new approach is tracked in bug 408996, and we don't know yet whether it will be good enough . So bottom line - the problem is not solved yet, and it will be late, and we may have to think about a potential Plan B. But I think it's a problem independent of MPC which can proceed testing on top of the original eclipse SDK.
(In reply to comment #6) > (In reply to comment #5) > Hi Ian, > > When Pascal said "fixed in SDK RC1" you should install the original classic > RC1 (or 4.3RC2 which was built last week). I mean the one from the Eclipse > Platform team, and not the one which I build for EPP. The original SDK > should have the required property, so I don't think MPC testing is blocked: > http://download.eclipse.org/eclipse/downloads/ I understand we could test MPC with the SDK but that is not the common use case. The very large majority of people get MPC from the packages so I would recommend that needs to be the testing scenario. > Independent of MPC, the question is do we have sufficient tooling to (1) > build the Eclipse.org packages the way they need to look like - ie with the > required property - and (2) to explain to product builders other than > Eclipse.org how they can update to 4.3 with remediation and ensure their > products have the required property. This really worries me. We have zero ability to communicate with product builders to ensure they have this property set correctly. If we are going to break a bunch of products then I think we need delay adding the p2 remediation for now. > > Pascal's original comment "just build with the new publisher and it will do > the right thing" did apparently not work. The new approach is tracked in bug > 408996, and we don't know yet whether it will be good enough . > > So bottom line - the problem is not solved yet, and it will be late, and we > may have to think about a potential Plan B. But I think it's a problem > independent of MPC which can proceed testing on top of the original eclipse > SDK. Now sure if I agree. I don't see many people using MPC with just the SDK.
(In reply to comment #7) > > > Independent of MPC, the question is do we have sufficient tooling to (1) > > build the Eclipse.org packages the way they need to look like - ie with the > > required property - and (2) to explain to product builders other than > > Eclipse.org how they can update to 4.3 with remediation and ensure their > > products have the required property. > > This really worries me. We have zero ability to communicate with product > builders to ensure they have this property set correctly. If we are going to > break a bunch of products then I think we need delay adding the p2 > remediation for now. This is not a 'bug in MPC', but rather a misconfiguration of the EPP Packages. If you try to install JBoss tools using the standard p2 UI (not the MPC) you will get this same behaviour. We need to update how the EPP Packages are configured.
(In reply to comment #8) > This is not a 'bug in MPC', but rather a misconfiguration of the EPP > Packages. If you try to install JBoss tools using the standard p2 UI (not > the MPC) you will get this same behaviour. > > We need to update how the EPP Packages are configured. And just to be clear, if you install JBoss tools on top of EPP 'you will get the same behaviour'. If you install JBoss on top of the Eclipse SDK (which is now configured correctly) it will work fine.
(In reply to comment #8) > This is not a 'bug in MPC', but rather a misconfiguration of the EPP Hi Ian, the point that both Ian S and myself are worried about is: If it is hard for us at Eclipse to configure the EPP packages properly, how are we going to educate all those other product builders out there to configure their products properly ? Ideally, people's existing build scripts for building their products would work unchanged, can this be realistically achieved ?
(In reply to comment #9) > (In reply to comment #8) > > This is not a 'bug in MPC', but rather a misconfiguration of the EPP > > Packages. If you try to install JBoss tools using the standard p2 UI (not > > the MPC) you will get this same behaviour. > > > > We need to update how the EPP Packages are configured. > > And just to be clear, if you install JBoss tools on top of EPP 'you will get > the same behaviour'. If you install JBoss on top of the Eclipse SDK (which > is now configured correctly) it will work fine. I complete understand this is not an MPC bug. It is great to hear that it is fixed in the SDK. Unfortunately, no one will be downloading the SDK but only packages so if it doesn't work in packages then it is still a crticial bug. This is also why testing via the packages is the only configuration I am interested in testing.
As plan B, I would suggest keeping the remediation support in, but disabling it by default. Users/testers would still be able to to test the feature by enabling it with a system property, e.g. in their eclipse.ini. This way we can a) make extra sure that everything runs fine with it "just" disabled, b) give early adopters a "good" release to work with and c) still keep the option to try the new remediation feature and make sure that it works, too, modulo the product issue. I think this way we get a good and safe release for users, plus some tester exposure, and can react quickly to an upstream solution.
(In reply to comment #10) > (In reply to comment #8) > > This is not a 'bug in MPC', but rather a misconfiguration of the EPP > > Hi Ian, the point that both Ian S and myself are worried about is: If it is > hard for us at Eclipse to configure the EPP packages properly, how are we > going to educate all those other product builders out there to configure > their products properly ? > > Ideally, people's existing build scripts for building their products would > work unchanged, can this be realistically achieved ? Right, so we are confusing two issues here: 1. Remediation in the MPC and 2. Configuration of products. Ian S. has suggested removing remediation from MPC, but that will not fix the underlying problem here. As for how to we education people about changes in Eclipse -- I don't know. Eclipse continually gets pulled in two different directions, some want it to remain the same so we don't break any existing use-cases, while others want 'innovation' and improvements. The remediation support is an excellent example of innovation in Eclipse Kepler, but now we want to surpress it because existing users may be broken unless they update their build scripts. Will a note in a migration guide help?
I think ppl are getting a bit too worried and worked up here. Let's take an hour to step back and have a phone conversation in about an hour.
Martin, please open a bug against p2 so we add some migration doc in eclipse to cover for this.
(In reply to comment #13) > (In reply to comment #10) > > (In reply to comment #8) > > > This is not a 'bug in MPC', but rather a misconfiguration of the EPP > > > > Hi Ian, the point that both Ian S and myself are worried about is: If it is > > hard for us at Eclipse to configure the EPP packages properly, how are we > > going to educate all those other product builders out there to configure > > their products properly ? > > > > Ideally, people's existing build scripts for building their products would > > work unchanged, can this be realistically achieved ? > > Right, so we are confusing two issues here: 1. Remediation in the MPC and 2. > Configuration of products. Ian S. has suggested removing remediation from > MPC, but that will not fix the underlying problem here. I agree this is two issues. My concern on this bug is #1 Remediation in MPC. I don't want MPC to be the source of creating an unstable Eclipse installation. For #2, I agree this needs to get fixed. I also don't think you can assume the ecosystem of product builder will change their configurations in the short term. I would hope the p2 and Platform team take this into consideration. > > As for how to we education people about changes in Eclipse -- I don't know. > Eclipse continually gets pulled in two different directions, some want it to > remain the same so we don't break any existing use-cases, while others want > 'innovation' and improvements. > > The remediation support is an excellent example of innovation in Eclipse > Kepler, but now we want to surpress it because existing users may be broken > unless they update their build scripts. Will a note in a migration guide > help? No disagreement. However, if we break the large ecosystem of plug-in providers then this feature will get a bad reputation. Ideally, new innovation is introduced early in a release cycle so the community can test and respond to it.
(In reply to comment #12) > As plan B, I would suggest keeping the remediation support in, but disabling > it by default. Users/testers would still be able to to test the feature by > enabling it with a system property, e.g. in their eclipse.ini. This way we > can a) make extra sure that everything runs fine with it "just" disabled, b) > give early adopters a "good" release to work with and c) still keep the > option to try the new remediation feature and make sure that it works, too, > modulo the product issue. > > I think this way we get a good and safe release for users, plus some tester > exposure, and can react quickly to an upstream solution. Carsten, I agree disabling remediation support by default makes sense. It is not going to work in the EPP RC2 so turning it off for now sounds sensible for RC2 and RC3. If we get sufficient testing on RC3 we would turn it on for RC4. Sounds good?
(In reply to comment #17) > (In reply to comment #12) > > As plan B, I would suggest keeping the remediation support in, but disabling > > it by default. Users/testers would still be able to to test the feature by > > enabling it with a system property, e.g. in their eclipse.ini. This way we > > can a) make extra sure that everything runs fine with it "just" disabled, b) > > give early adopters a "good" release to work with and c) still keep the > > option to try the new remediation feature and make sure that it works, too, > > modulo the product issue. > > > > I think this way we get a good and safe release for users, plus some tester > > exposure, and can react quickly to an upstream solution. > > Carsten, I agree disabling remediation support by default makes sense. It is > not going to work in the EPP RC2 so turning it off for now sounds sensible > for RC2 and RC3. If we get sufficient testing on RC3 we would turn it on for > RC4. Sounds good? I would like to ask you to hold on this for now as we have a chance to fix the EPP metadata in time for RC2.
(In reply to comment #18) > (In reply to comment #17) > > (In reply to comment #12) > > > As plan B, I would suggest keeping the remediation support in, but disabling > > > it by default. Users/testers would still be able to to test the feature by > > > enabling it with a system property, e.g. in their eclipse.ini. This way we > > > can a) make extra sure that everything runs fine with it "just" disabled, b) > > > give early adopters a "good" release to work with and c) still keep the > > > option to try the new remediation feature and make sure that it works, too, > > > modulo the product issue. > > > > > > I think this way we get a good and safe release for users, plus some tester > > > exposure, and can react quickly to an upstream solution. > > > > Carsten, I agree disabling remediation support by default makes sense. It is > > not going to work in the EPP RC2 so turning it off for now sounds sensible > > for RC2 and RC3. If we get sufficient testing on RC3 we would turn it on for > > RC4. Sounds good? > I would like to ask you to hold on this for now as we have a chance to > fix the EPP metadata in time for RC2. The advantage of disabling remediation is that we can test MPC without remediation. If you are able to get it in for RC2 you can always enable it.
I have a related question to this confusing dialog: when you try installing all items from here: http://download.eclipse.org/tools/tcf/builds/1.1/milestones/rc2/ it won't break your installation but by default modifies the items installed; however I still find the dialog very confusing because it doesn't tell me the reason why it can't install what I selected. Only when I close the dialog, I see the reasons in the errorlog. I find this very confusing, and unfriendly because it doesn't allow me to repair the problem the right way. Am I missing something ?
No you are not missing anything. The initial error message is only visible when you select "build my own solution". The wording could definitely be changed to be clearer about that. For example what do you think about something like "Show error and build my own solution". For context, the reason why the error message is not shown when you get on the remediation page is because we don't want to scare users. I realized that after all these years a few of us have become experts at reading those messages but most users are still scared of those. Martin, if you think the wording change can help, then please open a bug against p2 as this will help convince others of the importance of changing this. Thx in adavnce.
(In reply to comment #21) > No you are not missing anything. The initial error message is only visible > when you select "build my own solution". The wording could definitely be > changed to be clearer about that. For example what do you think about > something like "Show error and build my own solution". Don't you need to know the error to decide on what option you want to select? > > For context, the reason why the error message is not shown when you get on > the remediation page is because we don't want to scare users. I realized > that after all these years a few of us have become experts at reading those > messages but most users are still scared of those. OK but maybe you should focus on making the error message easier to understand?
(In reply to comment #22) > (In reply to comment #21) > > No you are not missing anything. The initial error message is only visible > > when you select "build my own solution". The wording could definitely be > > changed to be clearer about that. For example what do you think about > > something like "Show error and build my own solution". > > Don't you need to know the error to decide on what option you want to select? The design goal of this page was such that it was not necessary. The idea is that when you are trying to install something and it can not proceed, you are proposed solutions that help you continue and you trust the tool to propose you meaningful solutions. > > > > For context, the reason why the error message is not shown when you get on > > the remediation page is because we don't want to scare users. I realized > > that after all these years a few of us have become experts at reading those > > messages but most users are still scared of those. > > OK but maybe you should focus on making the error message easier to > understand? This is what the good sense would imply. However a couple things make this trickier than needed - the resolver does not return all the errors. - returning all the errors could return "incorrect" errors and returning something precise would require significantly more computations. - this is not what my customer wanted - this is not something my previous employers wanted to fix
(In reply to comment #22) > Don't you need to know the error to decide on what option you want to select? For most end users I don't think it helps. Really the error is always the same and maybe this should be spelled out: "The software you are trying to install is incompatible with the software you already have installed". If we explain it is because org.eclipse.rcp and org.eclipse.papyrus.util require conflicting versions of org.eclipse.emf.ecore, only the most advanced users will have enough context to decide on a course of action based on that level of detail. What this new wizard does, is examine all possible resolutions to the problem based on the available inputs, and offers a few clear alternative options. > OK but maybe you should focus on making the error message easier to > understand? The explanation for why a constraint satisfaction problem with hundreds of inputs failed is inherently difficult to make easy to understand. There are always some simple cases that we already have special code to give a simple explanation for ("Could not find X", "Two features require conflicting versions of X", etc). But often there are one or more long chains of dependencies leading to a conflict which is hard to express succinctly. Even when we can simplify it, most users don't anything about the myriad features that make up the product.
(In reply to comment #24) > (In reply to comment #22) > > Don't you need to know the error to decide on what option you want to select? > > For most end users I don't think it helps. Really the error is always the same > and maybe this should be spelled out: "The software you are trying to install is > incompatible with the software you already have installed". I completely agree. In my experience, user expectation is along the lines of "I want this, it doesn't work, give me options so it works!" The decision is then made on whether the suggested actions seem acceptable to them. The cause of the problem is usually not all that relevant to them. > The explanation for why a constraint satisfaction problem with hundreds of > inputs failed is inherently difficult to make easy to understand. It might be easier to focus on the concrete issue that the suggested remediation solves. Something along the lines of "x requires y, which conflicts with installed feature z, so we'll update z". But my feeling is that that doesn't add much information over the remediation suggestion itself.
Just to put my comment on this, I believe remediation in MPC is essential and important for the eclipse ecosystem. It's basically been years too late and it is about time we get it fixed. With the bugfixes that makes p2 not uninstall products when the plugin being installed is not it self a product (what is happening in Ian's first screenshot) and that it gets adjusted to handle even old style product builds we should be all good here. Changing to "Show error and build my own solution" is a fair change IMO and trivial to do. Having a way to see the error more easily and get a textual representation of the remediation is some nice to haves but since the errors are available and the whole remediation did not even exist requiring it to be more sugar coated is something to work on in the SR releases and the next eclipse release train IMO. I suggest we: A) resolve this issue as fixed B) open separate issues for how the *new* feature called Remediation can be improved and presented. B shouldn't block/delay Kepler since the current remedy wizard is miles ahead of what was there before; we just all got used to p2 ui show us a weird error message and its hard to get used to actually being shown an option that allow you to install plugins that before would have been impossible.
(In reply to comment #24) > (In reply to comment #22) > > Don't you need to know the error to decide on what option you want to select? > > For most end users I don't think it helps. Really the error is always the > same and maybe this should be spelled out: "The software you are trying to > install is incompatible with the software you already have installed". Why don't we use this as the error message? I did mean to suggest a long detailed error message but what you wrote here is certainly more descriptive and useful than what we have now.
(In reply to comment #26) > > B shouldn't block/delay Kepler since the current remedy wizard is miles > ahead of what was there before; we just all got used to p2 ui show us a > weird error message and its hard to get used to actually being shown an > option that allow you to install plugins that before would have been > impossible. I disagree. We have spent a lot of time on the usability within MPC. The goal has always been to make it really easy to discover and install Eclipse plugins. I don't want to go back to 'good enough' usability and using p2 ui as the benchmark. Sorry.
(In reply to comment #28) > I disagree. We have spent a lot of time on the usability within MPC. The goal > has always been to make it really easy to discover and install Eclipse plugins. > I don't want to go back to 'good enough' usability and using p2 ui as the > benchmark. Sorry. I agree completely. However, that's exactly the reason why I'm a fan of the remediation feature, even as it stands today - modulo the package problem of course. When things failed to install before, we had an error message that most users can't parse at all. Now we have an actionable suggestion that allows them to reach their goal of installing a solution from the marketplace. I think in terms of usability that's a very big step forward.
(In reply to comment #29) > (In reply to comment #28) > > I disagree. We have spent a lot of time on the usability within MPC. The goal > > has always been to make it really easy to discover and install Eclipse plugins. > > I don't want to go back to 'good enough' usability and using p2 ui as the > > benchmark. Sorry. > > I agree completely. However, that's exactly the reason why I'm a fan of the > remediation feature, even as it stands today - modulo the package problem of > course. > > When things failed to install before, we had an error message that most > users can't parse at all. Now we have an actionable suggestion that allows > them to reach their goal of installing a solution from the marketplace. I > think in terms of usability that's a very big step forward. I agree remediation is a great idea and it would be great to have it in MPC. However, we are past RC1 and still aren't able to test it. It is also not clear to me how we will test it once it is available. I hope you are right that the end user gets an actionable suggestion on reaching their install goal. Unfortunately, I have not seen this and as mentioned by Martin he finds the current error message confusing too. Remediation is not a step forward if it doesn't work, creates confusion or worse corrupts your installation. A lot of people use and like MPC so I don't want to have a significant regression due to remediation.
(In reply to comment #30) > I agree remediation is a great idea and it would be great to have it in MPC. > However, we are past RC1 and still aren't able to test it. It is also not clear > to me how we will test it once it is available. > > I hope you are right that the end user gets an actionable suggestion on reaching > their install goal. Unfortunately, I have not seen this and as mentioned by > Martin he finds the current error message confusing too. > > Remediation is not a step forward if it doesn't work, creates confusion or worse > corrupts your installation. A lot of people use and like MPC so I don't want to > have a significant regression due to remediation. That I agree on, too. That's why I'd still make remediation an option, not the default, for RC2, to let us test it properly before exposing it to everybody. I know that Pascal has put a lot of effort into both the contribution and the subsequent bugfix to get it into RC2. But I'll be a lot more at ease once it has proven itself in RC2. Unless I hear something to the contrary, I'll toggle the default tomorrow morning in time for RC2. I've already tested locally, and that makes it run fine without remediation.
(In reply to comment #31) > (In reply to comment #30) > > I agree remediation is a great idea and it would be great to have it in MPC. > > However, we are past RC1 and still aren't able to test it. It is also not clear > > to me how we will test it once it is available. > > > > I hope you are right that the end user gets an actionable suggestion on reaching > > their install goal. Unfortunately, I have not seen this and as mentioned by > > Martin he finds the current error message confusing too. > > > > Remediation is not a step forward if it doesn't work, creates confusion or worse > > corrupts your installation. A lot of people use and like MPC so I don't want to > > have a significant regression due to remediation. > > That I agree on, too. That's why I'd still make remediation an option, not > the default, for RC2, to let us test it properly before exposing it to > everybody. +1 on making remediation an option for RC2. Can you document on the mailing list how to turn remediation on.
(In reply to comment #32) > +1 on making remediation an option for RC2. Can you document on the mailing list > how to turn remediation on. Yes, will do.
I have download the RC2 nightly build of the standard package. I tried to install the JBoss Developer Studio (Juno) and appear to get the error message that remediation should catch. 'Cannot complete the install because of conflicting dependency.' I then try to install JBoss Tools (Juno) and I get the remediation page but it is not clear what I should be doing. The option selected is 'Keep my installation the same and modify the items being installed to be compatible' but I am not sure how I am suppose to do that? Also not sure why 'Update my installation...' option is not enabled? Screen shots are attached.
Created attachment 231666 [details] Error installing Jboss Developer Studio
Created attachment 231667 [details] JBoss Tools Remediation Dialog
Guys, the RC2 issue is *exactly* the same as the old MPC client does! Please stop blaming remedy for this. This is the *expected* result when you are trying to install Juno overall feature as Developer Studio onto Kepler it *must* fail just as in old MPC - it fails with the crappy error message as before. With JBoss Tools (juno) you are installing multiple features and *parts* of these can be installed on Kepler. In old MPC this would fail completely - with remediation you can actually fix it. With remediation you actually get a UI that tells you how to get to get it installed! This is what the remedy feature is *supposed* to do - avoid fixable failures.
The tree shows exactly what will happen: "JBoss OpenShift" and "Egit integraiton" will *not* be installed - but the rest will.
Ian S., your curent MPC will shows errors instead of providing a solution. with remedy it will actually be able to install plugins that would like to use a bugfixed version. If you remove remedy from MPC and remedy only are available in p2 ui we'll have to start telling users to stop using eclipse marketplace and we'll have to start push p2 ui again or even more the various custom mylyn connector install options. Because if MPC leaves it out it will not be able to install uptodate plugins.
(In reply to comment #37) > Guys, the RC2 issue is *exactly* the same as the old MPC client does! Please > stop blaming remedy for this. This is the *expected* result when you are > trying to install Juno overall feature as Developer Studio onto Kepler it > *must* fail just as in old MPC - it fails with the crappy error message as > before. OK and thank you for letting me know. I am just trying to test as fast as possible to see what works and what doesn't. Is there a way to tell what listings should get the same old crappy message and which should get the new remediation? > > With JBoss Tools (juno) you are installing multiple features and *parts* of > these can be installed on Kepler. In old MPC this would fail completely - > with remediation you can actually fix it. > > With remediation you actually get a UI that tells you how to get to get it > installed! > > This is what the remedy feature is *supposed* to do - avoid fixable failures. Hmmm, ok then maybe someone should work on the text. I was looking at a list of 'Installed' items thinking that is in past tense so it was completed. How about the following: - In the top error message it says what solution is trying to be installed. - For each category they are titled "Will Not Be Installed" and "Will Be Installed"
(In reply to comment #39) > Ian S., your curent MPC will shows errors instead of providing a solution. > > with remedy it will actually be able to install plugins that would like to > use a bugfixed version. > > If you remove remedy from MPC and remedy only are available in p2 ui we'll > have to start telling users to stop using eclipse marketplace and we'll have > to start push p2 ui again or even more the various custom mylyn connector > install options. > > Because if MPC leaves it out it will not be able to install uptodate plugins. Max, I get all this believe me. However, I am not going to let something be added to MPC that is not tested or if it is confusing. Sorry.
> > With remediation you actually get a UI that tells you how to get to get it > > installed! > > > > This is what the remedy feature is *supposed* to do - avoid fixable failures. > > Hmmm, ok then maybe someone should work on the text. I was looking at a list > of 'Installed' items thinking that is in past tense so it was completed. How > about the following: > - In the top error message it says what solution is trying to be installed. > - For each category they are titled "Will Not Be Installed" and "Will Be > Installed" This is also suggested elsewhere and being fixed.
(In reply to comment #41) > (In reply to comment #39) > > Ian S., your curent MPC will shows errors instead of providing a solution. > > > > with remedy it will actually be able to install plugins that would like to > > use a bugfixed version. > > > > If you remove remedy from MPC and remedy only are available in p2 ui we'll > > have to start telling users to stop using eclipse marketplace and we'll have > > to start push p2 ui again or even more the various custom mylyn connector > > install options. > > > > Because if MPC leaves it out it will not be able to install uptodate plugins. > > Max, I get all this believe me. However, I am not going to let something be > added to MPC that is not tested or if it is confusing. Sorry. Ian, it was included in M6 for P2, it got tested and patch for MPC added to be in M7 but that was ignored and thus testing in MPC have been reduced to this and it is still not being let in even though this has been tested immensely now. If you keep leaving it out it is not going to get any of the testing you want.
"- In the top error message it says what solution is trying to be installed." You need to remind me what message you want here instead of what is there now. It can't say which solution is being installed - that is shown in the tree.
Will having: "The software you are trying to install is incompatible with the software you already have installed" instead of "The installation cannot be completed as requested" be acceptable ?
Maybe "The software you are trying to install cannot be installed becase of incompatibilities, see below for an alternative option" is to be more explicit ?
ah sorry got it now - too many overloaded words: "In the top error message it says what solution is trying to be installed." you want something like: "JBoss Developer Studio(Juno) could not be installed fully, see below for options" Correct? I agree that would be *nicer*, but is that truly a blocker compared to what else is to be gained ? We'll look at what is possible but lets keep minor issues from the big ones.
Created attachment 231675 [details] How MPC shows the error today okey, so lets just compare oranges with oranges. I've attached here what the *current* MPC *without* remedy will show. It will show an even worse error than what remedy does. No mention of solutions etc.
(In reply to comment #46) > Maybe "The software you are trying to install cannot be installed becase of > incompatibilities, see below for an alternative option" is to be more > explicit ? (In reply to comment #45) > Will having: "The software you are trying to install is incompatible with > the software you already have installed" instead of "The installation cannot > be completed as requested" be acceptable ? I think either is an improvement.
(In reply to comment #48) > Created attachment 231675 [details] > How MPC shows the error today > > okey, so lets just compare oranges with oranges. > > I've attached here what the *current* MPC *without* remedy will show. > > It will show an even worse error than what remedy does. No mention of > solutions etc. If you are going to ask me to pick between two confusing error messages I am going to select the one that has been working for the last 4 years. Sorry. Why don't we focus on testing the remediation within MPC. It would be really nice to find some test cases that included more than JBoss Tools. Is this an unreasonable request?
Ian, it seems to me that there are some confusions as to what use to be, what is now with remediation and what you would like, and I'm afraid that further commenting on this bugzilla is not going to help dissipate your concerns (which I think I can understand). So here is a concrete proposal. I'm currently sitting in a train, and should be arriving at my hotel between 10:30 pm and 11pm. At this point you and I (and others) can have a skype / screensharing to go over this issue and we can review: - the MPC workflows pre and post remdiation - go through samples of remediation (both in plain p2 and MPC) If tonight can't work for you then I have two other availabilities: tomorrow night 9pm or I can come to the Foundation office Thursday morning. What would work best for you?
Also I forgot to mention but the messages in the tree are being fixed in tonight I build (toward rc3). https://bugs.eclipse.org/bugs/show_bug.cgi?id=409342
Actually in terms of availability I can also do Thrusday afternoon (before 5pm) and Friday all day. Also if you want to have other ppl along, that's no problem.
(In reply to comment #50) > Why don't we focus on testing the remediation within MPC. It would be really > nice to find some test cases that included more than JBoss Tools. Is this an > unreasonable request? I agree that we should test this feature, and in order to get the most eyes on it I think we should ensure it remains enabled for the upcoming RC's. We still have 1 month, so disabling it is an option if things go south. However, Pascal has certainly shown that he is committed to this. The Eclipse process is often pegged as too heavy-weight. Here is a good example of resources willing to help, and a patch that was ready for testing 2 1/2 months before the release. Yes it would have been great if this was planned and integrated during M1, but let's not prove our critics right by showing we have no agility. Another reason I think it's important to try and integrate this with the MPC is for consistency between the MPC and p2 install experiences. If we have plug-ins that can only be installed using p2 and not the MPC (because they would fail, but the remediation wizard can help), this will certainly add to the confusion. Finally, I was taken aback by comment #28 > I don't want to go back to 'good enough' usability and using p2 > ui as the benchmark. Sorry. p2 was designed as a 'general purpose provisioning platform', and unfortunately this has lead to a less stream-lined user experience than a single-purpose plug-in install manager. The remediation wizard is a good example of renewed focus on the user experience. Let's not dismiss this as 'bad design' simply because it came from the p2 team. I think that's an unfair characterization. I'm sure we can improve it, but that will only happen if we get feedback. Of course Ian S, you get the final say here. Do you think it's reasonable to keep it enabled so it can be tested until you meet with Pascal later this week?
(In reply to comment #50) > (In reply to comment #48) > > Created attachment 231675 [details] > > How MPC shows the error today > > > > okey, so lets just compare oranges with oranges. > > > > I've attached here what the *current* MPC *without* remedy will show. > > > > It will show an even worse error than what remedy does. No mention of > > solutions etc. > > If you are going to ask me to pick between two confusing error messages I am > going to select the one that has been working for the last 4 years. Sorry. > > Why don't we focus on testing the remediation within MPC. It would be really > nice to find some test cases that included more than JBoss Tools. Is this an > unreasonable request? Ian, your argument was that remedy was showing a confusing error message and that MPC couldn't accept that. I showed you that MPC has the *exact* same information even the wording is the exact same in the error case before and after remedy. Thus you cannot uphold that anymore as your reasoning for not enable it. The bug you found in this issue (wrong uninstallation) has been fixed and MPC is now behaving functionally and UI similar as it did before without remediation. It will show the same error as before. In the case where parts of the tools can be installed then remediation makes MPC better, not worse and besides the past tense wording (which is being fixed) I don't see any objections to that in this thread. About testing, Pascal posted this earlier: "The last time I had tested it was with Eclipse SDK RC1 + a locally built MPC. At that point I had tested the top 5 most used items, and also JRebel and JBoss. For JBoss, I always tried to force the remediation to come up so I started by installing m2e 1.1 from the eclipse Juno repo. Today, I just retested with http://download.eclipse.org/eclipse/downloads/drops4/I20130526-2000/ + MPC from May 21st and I tried to install the following items from MPC: - Secure Marketplace Discovery - Mobile Tools for Java - Spring Tool Suite for Kepler - JLoop - Mylyn - Windows Azure Tools - JBoss for Kepler - DBeaver - Sapphire - MintJams - SVN - m2e - ADT - Eclipse color thene - Egit - FindBugs - Maven for WTP - PyDev - JRebel" None of these will in normal circumstances trigger remediation, because they are all currently being "nice" to MPC and not requiring updates to the eclipse provided bundles AND that Kepler haven't even had a release yet. If you want to test the remediation on Kepler you can go try install any of the solutions that contains Juno or Indigo in their name - those will in many cases cause remediation to trigger (old MPC would just tell users the cryptic error message about "no solutions found" + p2 error trace). You can also go through the tests we (Red Hat) and Pascal have done which are very staged and specific scenarios - but that requires you to be willing to mess with p2 updatesite metadata and write some plugins that has very custom dependencies. But what you will see is that they result in the same flow and it is triggered very rarely in the current Marketplace - I'm sure we will see more cases popup once remediation starts being used and it is realized you can now actually depend on bugfixed versions of eclipse. I believe we have already tested all the scenarios that can be tested before it is set loose. If MPC Kepler in the RC's sees some horrible cases then we fix those or we disable the functionality if actual bad differences are found and non-fixable. The longer MPC waits to enable this the worse the situation becomes.
(In reply to comment #51) > Ian, it seems to me that there are some confusions as to what use to be, > what is now with remediation and what you would like, and I'm afraid that > further commenting on this bugzilla is not going to help dissipate your > concerns (which I think I can understand). > > So here is a concrete proposal. > I'm currently sitting in a train, and should be arriving at my hotel between > 10:30 pm and 11pm. At this point you and I (and others) can have a skype / > screensharing to go over this issue and we can review: > - the MPC workflows pre and post remdiation > - go through samples of remediation (both in plain p2 and MPC) > > If tonight can't work for you then I have two other availabilities: tomorrow > night 9pm or I can come to the Foundation office Thursday morning. > > What would work best for you? Unfortunately I am on vacation for the rest of the week so I am out of the office. I will try to continue to test when I have a chance but phone calls will not be possible. I actually think I am being reasonable. I just want to have a couple of test cases that I can run from real listings on MPC. What confuses me is why this is such a difficult request.
(In reply to comment #54) > (In reply to comment #50) > > Why don't we focus on testing the remediation within MPC. It would be really > > nice to find some test cases that included more than JBoss Tools. Is this an > > unreasonable request? > > I agree that we should test this feature, and in order to get the most eyes > on it I think we should ensure it remains enabled for the upcoming RC's. We > still have 1 month, so disabling it is an option if things go south. > However, Pascal has certainly shown that he is committed to this. We are not disabling this feature. We are only making it not the default. To test it, you will need to turn it on. > > The Eclipse process is often pegged as too heavy-weight. Here is a good > example of resources willing to help, and a patch that was ready for testing > 2 1/2 months before the release. Yes it would have been great if this was > planned and integrated during M1, but let's not prove our critics right by > showing we have no agility. Hmmm, yes and I tested it and it corrupted my Eclipse installation. It took me less than 5 minutes to do this. The EPP team has also figured out how to get the fix into RC2, instead of Pascal's original plan for RC3. I am also testing nightly builds now. Do you want to explain how we can go faster? > Of course Ian S, you get the final say here. Do you think it's reasonable to > keep it enabled so it can be tested until you meet with Pascal later this > week? To be clear, remediation is in RC2 but it will not be on by default. Carsten will document how to turn it on for testing.
(In reply to comment #55) > (In reply to comment #50) > > (In reply to comment #48) > > > Created attachment 231675 [details] > > > How MPC shows the error today > > > > > > okey, so lets just compare oranges with oranges. > > > > > > I've attached here what the *current* MPC *without* remedy will show. > > > > > > It will show an even worse error than what remedy does. No mention of > > > solutions etc. > > > > If you are going to ask me to pick between two confusing error messages I am > > going to select the one that has been working for the last 4 years. Sorry. > > > > Why don't we focus on testing the remediation within MPC. It would be really > > nice to find some test cases that included more than JBoss Tools. Is this an > > unreasonable request? > > Ian, your argument was that remedy was showing a confusing error message and > that MPC couldn't accept that. FWIW, I am not the only person that has found these error message confusing. > > I showed you that MPC has the *exact* same information even the wording is > the exact same in the error case before and after remedy. Thus you cannot > uphold that anymore as your reasoning for not enable it. I am not sure if I follow you here and I am not sure if it is worth arguing about? > > The bug you found in this issue (wrong uninstallation) has been fixed and > MPC is now behaving functionally and UI similar as it did before without > remediation. It will show the same error as before. Great! > > In the case where parts of the tools can be installed then remediation makes > MPC better, not worse and besides the past tense wording (which is being > fixed) I don't see any objections to that in this thread. Any objections to what? I think the better wording is a good thing. > > About testing, Pascal posted this earlier: > "The last time I had tested it was with Eclipse SDK RC1 + a locally built > MPC. At that point I had tested the top 5 most used items, and also JRebel > and JBoss. For JBoss, I always tried to force the remediation to come up > so I started by installing m2e 1.1 from the eclipse Juno repo. > > Today, I just retested with > http://download.eclipse.org/eclipse/downloads/drops4/I20130526-2000/ + MPC > from May 21st and I tried to install the following items from MPC: > - Secure Marketplace Discovery > - Mobile Tools for Java > - Spring Tool Suite for Kepler > - JLoop > - Mylyn > - Windows Azure Tools > - JBoss for Kepler > - DBeaver > - Sapphire > - MintJams > - SVN > - m2e > - ADT > - Eclipse color thene > - Egit > - FindBugs > - Maven for WTP > - PyDev > - JRebel" > > None of these will in normal circumstances trigger remediation, because they > are all currently being "nice" to MPC and not requiring updates to the > eclipse provided bundles AND that Kepler haven't even had a release yet. > > If you want to test the remediation on Kepler you can go try install any of > the solutions that contains Juno or Indigo in their name - those will in > many cases cause remediation to trigger (old MPC would just tell users the > cryptic error message about "no solutions found" + p2 error trace). OK, can you please help find some. I have tried and I can't get any to fail. The only one was JBoss Developer Studio but I guess that is not a valid test? > > You can also go through the tests we (Red Hat) and Pascal have done which > are very staged and specific scenarios - but that requires you to be willing > to mess with p2 updatesite metadata and write some plugins that has very > custom dependencies. I am sure Pascal has test cases that he has setup. I am only interested in test cases that use the packages, MPC and listings from Marketplace. I want to make sure this works on real listings. > > I believe we have already tested all the scenarios that can be tested before > it is set loose. If MPC Kepler in the RC's sees some horrible cases then we > fix those or we disable the functionality if actual bad differences are > found and non-fixable. With all due respect, this is exactly what I was told when we were asked to include remediation in RC1. It turns out there were test scenarios (packages + MPC) that haven't been tested. I still don't believe we have tested all the scenerios. I also don't understand why finding two other listings that would require remediation is that unreasonable? Right now, we have 1 test case using JBoss Tools. Why is it unreasonable to have 2 more test cases?
It looks like the GitHub Mylyn Connector will cause remediation to run in the RC2 nightly build. However, the remediation dialog only shows that it will install the GitHub Mylyn Connector so I am not entirely sure what is happening. Could someone try it out and see if it is working correctly.
(In reply to comment #56) > (In reply to comment #51) > > Ian, it seems to me that there are some confusions as to what use to be, > > what is now with remediation and what you would like, and I'm afraid that > > further commenting on this bugzilla is not going to help dissipate your > > concerns (which I think I can understand). > > > > So here is a concrete proposal. > > I'm currently sitting in a train, and should be arriving at my hotel between > > 10:30 pm and 11pm. At this point you and I (and others) can have a skype / > > screensharing to go over this issue and we can review: > > - the MPC workflows pre and post remdiation > > - go through samples of remediation (both in plain p2 and MPC) > > > > If tonight can't work for you then I have two other availabilities: tomorrow > > night 9pm or I can come to the Foundation office Thursday morning. > > > > What would work best for you? > > Unfortunately I am on vacation for the rest of the week so I am out of the > office. I will try to continue to test when I have a chance but phone calls > will not be possible. > > I actually think I am being reasonable. I just want to have a couple of test > cases that I can run from real listings on MPC. What confuses me is why > this is such a difficult request. Given that you seem to be around, what about now?
Which packae did you start from?
(In reply to comment #58) > > I showed you that MPC has the *exact* same information even the wording is > > the exact same in the error case before and after remedy. Thus you cannot > > uphold that anymore as your reasoning for not enable it. > > I am not sure if I follow you here and I am not sure if it is worth arguing > about? I think he meant to say that in the case where remediation doesn't find a solution and shows an ugly error message instead, that message is exactly the same as it was before without remediation. Only that it occurs far less frequently - i.e. only when remediation doesn't find a solution. > OK, can you please help find some. I have tried and I can't get any to fail. The > only one was JBoss Developer Studio but I guess that is not a valid test? JBoss Tools seems to be a more valid example, since it's not hit by the product bug. I'll keep testing, too, and will try to collect more test cases for the three remediation scenarios (modify current installation, modify items to be installed, no solution) and for combinations of popular marketplace entries. But for now, I'll go ahead and make the default change in order to build a candidate for RC2.
(In reply to comment #61) > Which packae did you start from? I get that too, using the Eclipse Standard Package (20130528-1643_eclipse-standard-kepler-RC2-win32.win32.x86_64.zip). The details area shows "Eclipse EGit Mylyn GitHub Feature" as "Installed" with an upward arrow, nothing more. The error details triggering this are Cannot complete the install because one or more required items could not be found. Software being installed: Eclipse EGit Mylyn GitHub Feature 2.3.0.201302130906 (org.eclipse.mylyn.github.feature.feature.group 2.3.0.201302130906) Missing requirement: Mylyn GitHub Connector Core 2.3.0.201302130906 (org.eclipse.mylyn.github.core 2.3.0.201302130906) requires 'package org.eclipse.jgit.lib [2.3.0,2.4.0)' but it could not be found Cannot satisfy dependency: From: Eclipse EGit Mylyn GitHub Feature 2.3.0.201302130906 (org.eclipse.mylyn.github.feature.feature.group 2.3.0.201302130906) To: org.eclipse.mylyn.github.core [2.3.0.201302130906]
(In reply to comment #63) > (In reply to comment #61) > > Which packae did you start from? > > I get that too, using the Eclipse Standard Package > (20130528-1643_eclipse-standard-kepler-RC2-win32.win32.x86_64.zip). The > details area shows "Eclipse EGit Mylyn GitHub Feature" as "Installed" with > an upward arrow, nothing more. The error details triggering this are > > Cannot complete the install because one or more required items could not be > found. > Software being installed: Eclipse EGit Mylyn GitHub Feature > 2.3.0.201302130906 (org.eclipse.mylyn.github.feature.feature.group > 2.3.0.201302130906) > Missing requirement: Mylyn GitHub Connector Core 2.3.0.201302130906 > (org.eclipse.mylyn.github.core 2.3.0.201302130906) requires 'package > org.eclipse.jgit.lib [2.3.0,2.4.0)' but it could not be found > Cannot satisfy dependency: > From: Eclipse EGit Mylyn GitHub Feature 2.3.0.201302130906 > (org.eclipse.mylyn.github.feature.feature.group 2.3.0.201302130906) > To: org.eclipse.mylyn.github.core [2.3.0.201302130906] If you hover over the arrow item, do you see more info?
Carsten, you can also try jrebel but before you have to remove all repos from p2
(In reply to comment #64) > If you hover over the arrow item, do you see more info? Aha! Yes, I do. Requested version: 2.3.0.xxxx, Version being installed: 3.0.0.xxxx
> > > > It will show an even worse error than what remedy does. No mention of > > > > solutions etc. > > > > > > If you are going to ask me to pick between two confusing error messages I am > > > going to select the one that has been working for the last 4 years. Sorry. > > > > > > Why don't we focus on testing the remediation within MPC. It would be really > > > nice to find some test cases that included more than JBoss Tools. Is this an > > > unreasonable request? > > > > Ian, your argument was that remedy was showing a confusing error message and > > that MPC couldn't accept that. > > FWIW, I am not the only person that has found these error message confusing. Yes, and as you will notice in this thread and the last 2 months remediation UI have been under testing elsewhere these have been improved. M6 to M7 and RC1 have had great improvements. > > I showed you that MPC has the *exact* same information even the wording is > > the exact same in the error case before and after remedy. Thus you cannot > > uphold that anymore as your reasoning for not enable it. > > I am not sure if I follow you here and I am not sure if it is worth arguing > about? Carsten explained it but just in case you missed it: Screenshot you made of current RC builds with remediation enabled (after Pascal and others fixed the product install bug): https://bugs.eclipse.org/bugs/attachment.cgi?id=231666 How the same situation looks *without* remediation: https://bugs.eclipse.org/bugs/attachment.cgi?id=231675 Open those and compared side-by-side, notice how it is exactly the same in RC2 with and without remediation enabled ? Leaving the only issue the tense change from "Install" to "Will be installed" which are handled in https://bugs.eclipse.org/bugs/show_bug.cgi?id=409342 > > The bug you found in this issue (wrong uninstallation) has been fixed and > > MPC is now behaving functionally and UI similar as it did before without > > remediation. It will show the same error as before. > > Great! Yes, so i'm just asking we resolve this and dont leave remediation out of MPC for RC2 since the bad issue (that we all agree on is bad) has been fixed. The wording is being fixed in RC3. > > In the case where parts of the tools can be installed then remediation makes > > MPC better, not worse and besides the past tense wording (which is being > > fixed) I don't see any objections to that in this thread. > > Any objections to what? I think the better wording is a good thing. Yes, but since the wording is same/better than what was in the past I (and others) find it weird that is keeping it from being enabled. We would prefer users spot and see errors 4 weeks before Final release than just 3 weeks before. This does not mean we expect there to be errors, but we've tested all the real major marketplace entries and found no issues - including now testing with EPP which was missed because of a bad assumption that is now fixed. > > About testing, Pascal posted this earlier: > > "The last time I had tested it was with Eclipse SDK RC1 + a locally built > > > > None of these will in normal circumstances trigger remediation, because they > > are all currently being "nice" to MPC and not requiring updates to the > > eclipse provided bundles AND that Kepler haven't even had a release yet. > > > > If you want to test the remediation on Kepler you can go try install any of > > the solutions that contains Juno or Indigo in their name - those will in > > many cases cause remediation to trigger (old MPC would just tell users the > > cryptic error message about "no solutions found" + p2 error trace). > > OK, can you please help find some. I have tried and I can't get any to fail. > The only one was JBoss Developer Studio but I guess that is not a valid test? JBoss Developer Studio is a perfect valid test if you are looking to trigger the error situation - it will show the same error with and without remediation. If you want more, enter "indigo" into the search field of MPC and try those. I tried the various "Oracle Database Tools*" which caused failures too because there are no Indigo bits available to install from (expected to error both in past and now when installing it) I can try find a more exhaustive list. > > You can also go through the tests we (Red Hat) and Pascal have done which > > are very staged and specific scenarios - but that requires you to be willing > > to mess with p2 updatesite metadata and write some plugins that has very > > custom dependencies. > > I am sure Pascal has test cases that he has setup. I am only interested in > test cases that use the packages, MPC and listings from Marketplace. I want > to make sure this works on real listings. > > > > I believe we have already tested all the scenarios that can be tested before > > it is set loose. If MPC Kepler in the RC's sees some horrible cases then we > > fix those or we disable the functionality if actual bad differences are > > found and non-fixable. > > With all due respect, this is exactly what I was told when we were asked to > include remediation in RC1. It turns out there were test scenarios (packages > + MPC) that haven't been tested. Yes, and if you'll notice that bug was already identified early on and a fix in progress. You were not the first one to report it. But it was the kind of bug that would not have been found if we actually put it out in real testing. I fear if we keep it disabled in MPC for RC2 and there actually is a bug we will find it too late and you'll say it is too late now and drop it completely. > I still don't believe we have tested all > the scenerios. Which scenarios are it you feel that are missing ? The bug here is about the case of eclipse being uninstalled when it should not that was fixed in RC1+. > I also don't understand why finding two other listings that > would require remediation is that unreasonable? Right now, we have 1 test > case using JBoss Tools. Why is it unreasonable to have 2 more test cases? There are already other mentioned in here, jrebel, m2e-wtp if you have old version installed, mylyn github...but i'm downloading latest I-build to see if I can find others. Still I believe the serious issues left reported in here is already fixed. We should mark this issue as resolve and open separate specific issues for what is left and optimally have remediation enabled in MPC so we can actually get this tested outside gated walls of eclipse dev/bugzilla discussions.
Example that is not jboss tools (sites are jboss, but these are the old sonatype m2e plugins that got renamed when moving to eclipse.org). Install manually m2e-wtp into Eclipse: http://download.jboss.org/jbosstools/updates/m2eclipse-wtp/ Now try install m2e-wtp from Eclipse MPC. You should see remediation show up.
(In reply to comment #66) > (In reply to comment #64) > > If you hover over the arrow item, do you see more info? > > Aha! Yes, I do. Requested version: 2.3.0.xxxx, Version being installed: > 3.0.0.xxxx Ok good. This is the poster child example of why we need remediation. In this case, without remediation it would simply fail and the user would not be able to install at all.
Created attachment 231704 [details] Test Case 1 : Groovy/Grails Tool Suite (GGTS) for Eclipse Indigo (3.7) TEST CASE #1 (with remediation page) Set Up : 1. install http://build.eclipse.org/technology/epp/epp_build/kepler/download/20130528-1643/ 2. install m2e - Maven Integration for Eclipse 1.1.0.20120530-0009 Solution to install : Groovy/Grails Tool Suite (GGTS) for Eclipse Indigo (3.7)
(In reply to comment #15) > Martin, please open a bug against p2 so we add some migration doc in eclipse > to cover for this. Has this happened yet? I find it quite notable that including a Kepler p2 version into any product implies that an update of the build tool is required.
Created attachment 231707 [details] Test Case 2 : Subversive - SVN Team Provider (Remedy 1) TEST CASE #2 Set Up: 1. install standard package from //build.eclipse.org/technology/epp/epp_build/kepler/download/20130528-1643/ 2. install "Subversive SVN Team Provider (Incubation) 0.7.9.I20120520-1700" from http://download.eclipse.org/technology/subversive/0.7/update-site/ using p2 (restart Eclipse and continue the install) 3. install the solution "Subversive - SVN Team Provider" from MPC 2 remedies found (see screenshots)
Created attachment 231708 [details] Test Case 2 : Subversive - SVN Team Provider (Remedy 2)
(In reply to comment #71) > (In reply to comment #15) > > Martin, please open a bug against p2 so we add some migration doc in eclipse > > to cover for this. > > Has this happened yet? I find it quite notable that including a Kepler p2 > version into any product implies that an update of the build tool is > required. Tobias, good example of why we should close this bug because things have been fixed since it was opened:) The updates to build tool is just to insert the explicit property to mark products as product. With the latest fixes because it testing and feedback in the wild pascal updates remedy to also look for "lineUp" which are already included in past PDE-ant and tycho. That should cover all EPP packages and anything else built in recent 4+ years. Pascal has the details. Still should get added to migration docs but just wanted to make clear this backwards compatibility issue is fixed for all common known cases.
Hi guys, If you need more test cases, here are the steps I followed: 1. Go to http://marketplace.eclipse.org 2. Choose a solution 3. Go to the "Errors" tab 4. Search for an error "Cannot complete the install because of a conflicting dependency...." and click on it 5. Search for "Software currently installed:xxx.". (xxx is usually responsible for the conflict) 6. Install xxx using p2 UI 7. Install the solution using MPC. The install should not go through, alternate solutions should be proposed. Here is a concrete example: 1. Go to http://marketplace.eclipse.org 2. Search "JBoss Developer Studio (Juno)" 3. Go to the "Errors" tab 4. Search for an error "Cannot complete the install because of a conflicting dependency...." and click on it 5. Search for "Software currently installed" You may find : "Software currently installed: m2e-wtp - Maven Integration for WTP (Incubation) 0.17.0.20130212-1821 (org.eclipse.m2e.wtp.feature.feature.group 0.17.0.20130212-1821)" 6. Install "m2e-wtp - Maven Integration for WTP (Incubation) 0.17.0.20130212-1821" using p2 UI 7. Install JBoss Developer Studio (Juno) using MPC. The remediation page should show up. HTH Estelle
I no longer get the dialog that suggested I can uninstall the SDK. Closing this bug out.
The MPC RC3 contribution now available at http://download.eclipse.org/mpc/nightly has remediation enabled by default again. Thanks everybody for testing and enjoy your remedies :)
Cleanup: closing all released fixes.
