Community
Participate
Working Groups
Created attachment 135492 [details] patch to prevent target ius from being installed into running system During the Equinox call today we talked about the problems of people trying to install bits intended for the target platform into their IDE. This may come up more often now that we are putting rutnime SDK bits in the galileo repo. One approach discussed was mark the SDK feature IUs with a required capabilty that would only ever exist in profiles managed by the target platform provisioning support from pde. That way the SDKs would simply fail to resolve when being installed in the IDE. I had some code around that dynamically creates and installs IUs into a profile so I adapted that to simply add a capability and called it from the TargetDefinition.getProfile where the target profile is created (see attached patch). This adds the capability pde.target.provisioning, pde.target.provisioning, 0.0.0 to the profile. We then create the following p2.inf file to the feature in question and export. requires.1.namespace=pde.target.provisioning requires.1.name=pde.target.provisioning requires.1.range=[0.0.0,0.0.0] When you then go to install such a customized feature into the IDE you get the following failure. Cannot complete the install because one or more required items could not be found. Software being installed: Test 1.0.0.200905122219 (test.feature.group 1.0.0.200905122219) Missing requirement: Test 1.0.0.200905122219 (test.feature.group 1.0.0.200905122219) requires 'pde.target.provisioning pde.target.provisioning [0.0.0]' but it could not be found The feature does however install fine into target platforms. Clearly we could do better on the namespace and name so as to make the default message better. Ideally there would be some sort of support for identifying these IUs in the UI with a different icon etc. but that is deluxe.
This is one way to make sure people can't install things into the IDE that are meant for the target. I also have a patch against p2 ui that changes the icon for IUs that represent IUs meant for your target, versus your running IDE.
Darin, what are your thoughts on this one? I think this is a reasonable workaround for the problem of people installing "runtimes" into their IDE. One downside could be people who want to use those runtime IUs... I know in PDE Build you can fetch IUs now in map files... Andrew, would this affect you?
(In reply to comment #0) > Created an attachment (id=135492) [details] > patch to prevent target ius from being installed into running system > > During the Equinox call today we talked about the problems of people trying to > install bits intended for the target platform into their IDE. This may come up > more often now that we are putting rutnime SDK bits in the galileo repo. One > approach discussed was mark the SDK feature IUs with a required capabilty that > would only ever exist in profiles managed by the target platform provisioning > support from pde. That way the SDKs would simply fail to resolve when being > installed in the IDE. > During the Equinox call I thought we had agreed to do nothing for the 3.5 release. Do I remember this incorrectly? This change feels a bit late and I would really like to avoid destabilizing the PDE target provisioner at this point.
(In reply to comment #3) > During the Equinox call I thought we had agreed to do nothing for the 3.5 > release. Do I remember this incorrectly? This change feels a bit late and I > would really like to avoid destabilizing the PDE target provisioner at this > point. I missed the call so someone else would have to verify. The patch wouldn't destabilize the target provisioner imho, it only adds a capability that we know about now. I do agree that this is a bit late in the game but do we risk leaving a bad taste in people's mouth when they install "runtimes" into their IDE?
I was not at the call either... my feeling is that we want to solve this problem, but not in RC2. It's really a feature, and it requires metadata authors to put proper dependencies in. When everything lines up it will work, but it only works when everyone does the right thing. There are likely alternate solutions to this problem, so I would prefer not to rush something in case we decide that another approach is better.
We agreed that there were other changes going on and that this is more work and so may not be on the table. Since I had the code around I wanted to see what this would look like. The patch is the result of that investigation. The only reason I'm proposing this is as a means of avoiding the people getting frustruated by accidentally installing the SDK stuff into their IDE and being surprised/disappointed and then turning negative on the overall solution. Its not really a feature so much as protection bug bucket and blog flames.
For reference, see bug 275753 comment 1. Without a safeguard like this the RAP team is reluctant to participate in the target provisioning experience. RAP is likely unique in that they provide competing implementations of platform infrastructure. While I agree that this may not be the best answer, the best answer is not known at this time and the potential for user issues does appear to be real.
Tom and I talked a little and there is another option that people like RAP could use. They are free to introduce a requirement like the one envisioned here in their SDK feature. This would prevent their feature from being installed via the planner at all. period. To add their feature to the target the user would have to use the slider mode (that is turn off "include required"). In the case of RAP, this likely makes sense anyway as the planner may well have some difficulty dealing with the conflicting requirements and creating a coherent target. At the very least that would take some testing that may well not happen in the galileo timeframe. Note that it is the introduction of the requirement that would be most likely to cause problems. The code to add the capability to the profile is very simple and the presence of another capability in the profile innocuous. Summary, this issue of people installing SDK bits into their IDE will come up. guaranteed. The question is how will they react and does the current "cure" introduce more issues than it resolves.
Another solution to this would be if the feature could express "I cannot coexist with this", i.e. implement bug 194665. If the profile of a running system had some characteristic that a target platform never has, then a negated requirement could be expressed for that. That would also resolve the issue with the Galileo builder discussed in bug 275753 comment 4.
that could also work. the challenge there is now we need all randomly created IDE profiles to have something special. the approach spec'd here is very localized to just the target provisioning infrastructure.
In light of things like the RAP SDK really wanting to be kept out of the IDE it seems that we should do something. Roughly speaking 4 options have been surfaced (in no particular order). 1) scary descriptions. This allows us to say "I told you so" but otherwise does not stop people from installing this stuff. 2) Required capability. The proposal here in comment 0. This would physically prevent SDK IUs from being installed into anything but target platform profiles by adding a special required capability to SDK IUs. It requires some code changes in PDE and the addition of a p2.inf file in the SDK features. 2b) A variation on #2 surfaced (see comment 8) where we would still add the "required capability" to select SDK IUs but not do anything to the Target profiles. This would prevent these SDK IUs from being installed using the planner (IDE or target). The only way to install them would be into the target using the slicer (uncheck "Include Required") 3) UI Filters. Various approaches to filtering the EclipseRT category or SDK IUs from the p2 UI. 4) Separate repositories. There are a couple variants here but fundamentally the EclipseRT stuff would go in a different repo and users interested in target provisioning would have to add that repo to the list. Tom (Watson) and I talked about these this morning and had the following thoughts. 1) too weak. Yes the user has the information but pragmatically we know that folks will screw up. we have seen it happen already. 2a) this requires some code changes in PDE's target platform and may not be the direction that we want to go in the longer term. The code is relatively modest but at this point in the release cycle, changes are changes. 2b) this avoids the code changes but still prevents the IUs from being installed (regardless of how the user found them) into an IDE. It does force the target users to use the slicer. However, in the case of things like the RAP SDK that is likely what they want to do anyway. *Note for 2a and 2b. Thomas H points out that the Galileo builder does a verification step to ensure that everything in the repo can be installed together. Marked up IUs would cause that verification to fail. In fact, this is a good thing since it really is NOT the case that the RAP SDK and the platform can cohabitate. The builder would need to be adapted to ignore IUs with this particular requirement. 3) UI filters would be hard to do at this point. PDE and p2 share a UI so there would have to be changes to allow the p2 uI to be put in a particular mode where it would filter some specific hard coded category. There are questions about what happens if category sorting is turned off, ... and it is just really late in the game to be changing this kind of thing 4) This has the nice effect that some large % of the Eclipse user base would never see the IUs in question. However there is a major discoverability problem if the Target Platform repo is not included in the primed list. a) people will not know that such a thing exists and b) even if they do know, there are challenges finding the repo URL. For those people who do happen to find the URL it is seamlessly merged into the general list of repos available. That is, currently the target provisioning work uses the same repository list as the IDE itself. This means that a) it is not possible to prime separate lists and b) once the target platform repo is added to the list, we have the original problem again albeit with a potentially less hapless set of users (not guaranteed :-) Summary: Overall 1 + 2b) looks to be the most efficient in that - #1 gives the users the information they need, #2b helps those who did not see #1 - it requires relatively little code change ("just" the builder, sorry Thomas), - it is easy to implement for the contributing teams - it can be targetted (i.e., only teams that care can add the markup) - it addresses the problem regardless of the UI workflows followed by the user. Concretely 2b) requires the following actions. - Teams wanting to prevent their SDK from being installed in the IDE (eg., the RAP folks) would add a p2.inf file to their feature as follows: requires.1.namespace=A.PDE.Target.Platform. requires.1.name=Do.not.install.in.IDE requires.1.range=[0.0.0,0.0.0] Attempts to install such IUs would then result in an error with a message roughly as follows: Missing requirement: RAP SDK 1.2 requires 'A.PDE.Target.Platform. Do.not.install.in.IDE' - Adapt the Galileo builder to ignore all IUs that have the above mentioned requirement. By having everyone use the same p2.inf file we leave open the option of tooling this in the future (using 2a or other means). This is not the ideal
Just to echo Jeff's comments. I am in favor of the 2b) option also. It puts the power in the hands of the producers of the EclipseRT content and it does not require any code changes to p2/PDE at a time when we need to stabilize. Unfortunately it does require Galileo builder changes (again sorry Thomas H.)
I agree something should be done for 3.5. My observation is that 2a (adding (2a.1) a provided capability to each target profile, and (2a.2) a required capability in SDK IU's) only works when both 2a.1 and 2a.2 are done. Simply have 2a.1, won't prevent the problem, but having both allows use of the planner, where as only having 2a.2 means users have to use the slicer to create targets. So, I think 2a.2 (required capability in the SDK IU's) is definitely required. Having 2a.1 (provided capabilities) is a feature that is icing on the cake. Where should the "(1) Doc" go? This is doc for SDK authors?
(In reply to comment #13) > So, I think 2a.2 (required capability in the SDK IU's) is definitely required. > Having 2a.1 (provided capabilities) is a feature that is icing on the cake. Yes. 2a.2 is actually 2b :-) > Where should the "(1) Doc" go? This is doc for SDK authors? Yes, this is a task for SDK authors though I have to say that the p2 UI does not show the description very prominently so users could be quite reasonable in not reading it. In any event, 1) is just so we can say "I told you so" :-)
(In reply to comment #11) > - it requires relatively little code change ("just" the builder, sorry Thomas), > No problem. We need to resolve this one way or another. I agree this is the easiest way. And it doesn't rule out filtering in the UI later on. > - Adapt the Galileo builder to ignore all IUs that have the above mentioned > requirement. > I don't think ignoring them would be the right approach. They still need to be mirrored together with all dependencies. The easy fix would be to add the 'Do.not.install.in.IDE' IU during the verification process and then remove it again. That, of course, implies that the IU is installable in all other respects. Is that acceptable? If not, the change is more complex since I need to implement some kind of 'best effort resolution' of the dependencies of such IU's and run that in addition to the current planner phase.
In reply to comment #15) > No problem. We need to resolve this one way or another. I agree this is the > easiest way. And it doesn't rule out filtering in the UI later on. Thanks Thomas for your continuing flexibility here. > > - Adapt the Galileo builder to ignore all IUs that have the above mentioned > > requirement. > > > I don't think ignoring them would be the right approach. They still need to be > mirrored together with all dependencies. The easy fix would be to add the > 'Do.not.install.in.IDE' IU during the verification process and then remove it > again. That, of course, implies that the IU is installable in all other > respects. Is that acceptable? I don't think that will work. There is no sense in which the RAP and Platform stuff can cohabitate AFAICT. It *may* happen to work at some point but there is no design imperative that it actually work. I agree that they should be mirrored but perhaps we filter them out for verification and then add them back after verification? Think of it as a white list of things that are known to be good :-) > If not, the change is more complex since I need to implement some kind of 'best > effort resolution' of the dependencies of such IU's and run that in addition to > the current planner phase. Yikes!
(In reply to comment #16) > I agree that they should be mirrored but perhaps we filter them out for > verification and then add them back after verification? Think of it as a white > list of things that are known to be good :-) > My problem is that the verification phase determines the transitive closure of what needs to be mirrored and chances are that the IU has dependencies that will not otherwise be included. But OK, how about this: The builder will check if a contributed IU has a direct dependency to 'Do.not.install.in.IDE'. If it has, it will be excluded from the verification and added a list. This list will later be fed to a PermissiveSlicer and the collection returned by querying that slicer is added to the set of IU's that will be mirrored.
yes, that should get the things that are needed.
The builder is now modified so that any feature that has a direct requirement to something in the "A.PDE.Target.Platform" namespace will be treated differently (the name of the requirement doesn't matter). Sucn an IU does not take part in the verification and its transitive closure for inclusion when mirroring is determined using a PermissiveSlicer. The slicer is configured to ignore all filters (evaluate them to true) and to include optional dependencies. The builder is uploaded and installed so everything is set to start testing this.
Just for the record and I know that doesnot count, I would prefer option 3) one way or another. Either filter Eclipse RT category from the IDE Software Update or put them on a different repository and add the Eclipse RT repository only to the target provision install and not the Software Install that you get by default. I understand we are late in the game but what we are doing now is that we avoid to change anything in the PDE/UI but we change the builder and we require another 10 SDKs to change their setup. How frightening is that ? And I am sure that is a good chance something goes wrong their and beyond I know for sure that people will insist and bug us and post questions about why they cannt install Riena SDK, RAP SDK and Sopera SDK into their IDE. ("Riena SDK does not work with Eclipse IDE 3.5." would be the prefered header for such a post :-) ). We are just offering something that will never work and refuse to install in such a context. Like I said I post that here just for the record and I am feeling better already :-) christian p.s. As posted on 275753, Rüdiger from the RAP team is backing me on this one.
(In reply to comment #20) > Just for the record and I know that doesnot count, I would prefer option 3) one > way or another. > > Either filter Eclipse RT category from the IDE Software Update or put them on a > different repository and add the Eclipse RT repository only to the target > provision install and not the Software Install that you get by default. No one is disagreeing that guiding the user ahead is better. The real way to do that is to have separate lists of repos for target provisioning and IDE provisioning. That, it turns out, is quite complicated and the Eclipse project is basically 2 weeks from shipping. > I understand we are late in the game but what we are doing now is that we avoid > to change anything in the PDE/UI but we change the builder and we require > another 10 SDKs to change their setup. It would actually be p2 UI as those components are reused all over the place. As or changing 10 SDKs, this is a choice that the SDK producers have. If the Riena SDK works fine when installed in the IDE and that makes sense to that user community, no changes are necessary. In the RAP case, apparently it would not be fine. > Like I said I post that here just for the record and I am feeling better > already :-) Glad that was of help.
Removing target milestone since there is no 3.5 work planned in PDE for this. Consensus is to add a required capability to SDK (2b) for 3.5.
Could someone provide help with creating such a requirement? I tried to include a file named p2.inf in the root directory of the RAP runtime feature with this content: ---- requires.1.namespace=A.PDE.Target.provisioning requires.1.name=RAP requires.1.range=[0.0.0,0.0.0] ---- Installing the RAP runtime into the target platform worked and installing into the IDE worked as well. Obviously, the p2.inf file has not been respected during the metadata generation. I tried different combinations of generator args with no luck yet. Is there any special argument to pass to the generator? Any known pitfalls, any guide to follow?
(In reply to comment #23) For the records, our problems with the p2.inf files is solved. The problem was that we used the outdated p2 metadata generator. With the new p2 publisher, the proposed hack works. Nevertheless, installing into a target platform now requires to uncheck the "Include Required Software" check box. Without knowing this, users of the target provisioning are also confronted with this "missing A.PDE.Target dependency" error - so it's a solution but it's still not perfect.
FYI, the first one walked into the trap: bug 281854. The estimated number of unknown cases is much higher I guess.
For 3.5 there is the ability to add the special "target platform only" requirement. Do we need to keep this bug open? Is there something more that PDE should do?
(In reply to comment #26) > For 3.5 there is the ability to add the special "target platform only" > requirement. Do we need to keep this bug open? Is there something more that > PDE should do? From my point of view, the current solution was just a hack to workaround the problem for the Galileo release. It results in a really disturbing user experience. Users select "Rich Ajax Platform" from the Galileo repository and get strange errors. I think we need a solution that hides target-platform-only bundles from the Available Software wizard page, as already suggested earlier in this discussion. Moreover, I doubt that a fake dependency is the perfect approach. Aren't there more suitable concepts in p2?
And it happend again :( See bug 283914 We really should come up with something that doesn't confuse our users that much. I think this is even something for the 3.5.1 service release.
Pascal, any thoughts on how to improve this story in 3.6? Susan, thoughts on how to improve the UI for this?
anything likely to happen in this space? The EclipseRT community is looking to setup for Helios and need to know what to do with their SDKs
(In reply to comment #30) > anything likely to happen in this space? The EclipseRT community is looking to > setup for Helios and need to know what to do with their SDKs There is nothing new planned here for 3.6 currently. Using a p2 agent and managed profile per target would help here, but that work is not planned to be in 3.6, as it did not stabalize in time.
Wonder if there is a very modest tweak we can do to improve the workflow for end users. Right now the "recommended" hack is ot use p2.inf to add a dependency that cannot be met by the IDE. This results in a p2 failure when the end user goes to add something that they should not. This in turn results in bug reports to various teams saying that their stuff is broken when really it is the user not paying attention. So, one possibility would be for PDE/p2 target provisioner to notice the particular shape of the constraint that is being violated and report a more helpful error message to the user e.g., "XXX is not designed to be installed in an IDE. " (whatever) I agree that this is less than optimal but the current flow is problematic for real users and is driving teams to not want to put their SDKs in the repo. This in turn makes it harder for end users to get their stuff and decreases the usage of the cool PDE target provisioning technology.
It seems that the current A.PDE.Target.Platform workaround does not prevent p2 from installing SDK features in all cases. See bug 306279.
(In reply to comment #33) > It seems that the current A.PDE.Target.Platform workaround does not prevent p2 > from installing SDK features in all cases. See bug 306279. this is a great blocker as I reported in my blog http://ekkescorner.wordpress.com/2010/03/20/urgent-helios-m6-updatesite-problem-with-rap-in-ide/ we need some bundles of Riena to use Riena Ridgets in our redView Designer Editor. Another usecase I know from Christian Campo is the use of the Riena toolbox inside IDE Even if I create an own updatesite collecting all needed Riena Bundles -P2 still adds rap bundles into the IDE
It seems that there are also problems when using the p2 agent. See bug 306709
While I do think this is a critical problem that needs to be addressed for 3.6, I do not think that bug 306709 and bug 306279 are related. The only thing we can really do is mark up features as being intended for the target platform. If they are intended for the TP then they are not intended to be used in other cases (bug 306709). Producers should take care and mark only their SDK features as TP features. Similarly, marking a feature as "for targets" does not prevent the included features and bundles from being installed without the target feature (bug 306279). If it did then, for example, no part of RAP would ever be installable if the RAP SDK feature existed anywhere in the current metadata. Seems harsh.
(In reply to comment #36) > While I do think this is a critical problem that needs to be addressed for 3.6, > I do not think that bug 306709 and bug 306279 are related. The only thing we > can really do is mark up features as being intended for the target platform. If > they are intended for the TP then they are not intended to be used in other > cases (bug 306709). Producers should take care and mark only their SDK features > as TP features. We discussed this issue again and doubt that we currently have that clean distinction between TP and not-TP bundles/features. As an example, the Riena tooling obviously has a dependency on parts of the Riena runtime. Another approach would be to add a "conflicts-with" directive to the TP-bundles as suggested in comment #9. This way, the RAP SDK could express that it can not coexist with RCP and would therefore be prevented to be installed into the IDE. This approach has the advantage of keeping concepts like "for target-platform" and "for IDE" out of p2.
The suggestion in comment 9 sounds good. Can you try it out? That should likely be expressed where the conflicts actually are. For example RWT cannot be installed if SWT is there. While that should ultimately prevent the RAP stuff from being installed into the IDE, there should still be a higher level notion of "this thing in the repo is intended for Targets (or not for IDEs)". Otherwise users will just get a random confusing error when they "mistakenly" try to install RAP in their SDK. Note that we should ensure that if "include dependencies" is UNchecked in the TP editor then RWT and SWT *can* still be put in the same target however.
(In reply to comment #38) > The suggestion in comment 9 sounds good. Can you try it out? I'd love to, if I had a clue how to implement it. Is there a way to express such a "conflicts-with" directive in a p2.inf file already? > That should likely be expressed where the conflicts actually are. For example > RWT cannot be installed if SWT is there. While that should ultimately prevent > the RAP stuff from being installed into the IDE, there should still be a higher > level notion of "this thing in the repo is intended for Targets (or not for > IDEs)". Otherwise users will just get a random confusing error when they > "mistakenly" try to install RAP in their SDK. Yes, we could either keep this "scary" warning or better filter out those features in the UI when installing into the IDE. Would it be possible to let the UI filter out features that are conflicting with installed bundles (of course, only when installing into the IDE)? I think IDE users need more guidance than target platform hackers... > Note that we should ensure that if "include dependencies" is UNchecked in the TP > editor then RWT and SWT *can* still be put in the same target however. Would you say it is a requirement that conflicting bundles can be put together into one target?
(In reply to comment #39) > I'd love to, if I had a clue how to implement it. Is there a way to express > such a "conflicts-with" directive in a p2.inf file already? comment 9 identifies bug 194665 as the thing that implements this function but the last comment is asking about documentation for this. I don't know if it is possible to add in a p2.inf file. Perhaps Pascal knows? > Yes, we could either keep this "scary" warning or better filter out those > features in the UI when installing into the IDE. > > Would it be possible to let the UI filter out features that are conflicting > with installed bundles (of course, only when installing into the IDE)? I think > IDE users need more guidance than target platform hackers... Yea, thats what I was shooting for in comment 32. There is not much time so even something hackish that looks for the specific missing requirement and gives the user a better error message would be very welcomed. > > Note that we should ensure that if "include dependencies" is UNchecked in the TP > > editor then RWT and SWT *can* still be put in the same target however. > > Would you say it is a requirement that conflicting bundles can be put together > into one target? Absolutely. I do it all the time. Remember the target is just a collection of stuff that is available to be configured together. they are not themselves configured together just by being in a target together. This is a key difference between a target and say a normal profile. In the future we may have per-project targets or some such but for now, this capability is IMHO important for various workflows.
see also bug 307789 for a proposed hack to the p2 UI for a better workflow.
(In reply to comment #32) > So, one possibility would be for PDE/p2 target provisioner to notice the > particular shape of the constraint that is being violated and report a more > helpful error message to the user e.g., "XXX is not designed to be installed in > an IDE. " (whatever) I agree this would be helpful - for now this would be up to p2, since it is the component that manages installation of bundles into the IDE.
(In reply to comment #42) > (In reply to comment #32) > > So, one possibility would be for PDE/p2 target provisioner to notice the > > particular shape of the constraint that is being violated and report a more > > helpful error message to the user e.g., "XXX is not designed to be installed in > > an IDE. " (whatever) > > I agree this would be helpful - for now this would be up to p2, since it is the > component that manages installation of bundles into the IDE. We are doing that in bug307789. But we are still missing the ability to avoid this message when provisioning a target. See bug307789 comment 5. How hard would it be for PDE to provision an IU to the managed targets to satisfy the requirement: requires.1.namespace=A.PDE.Target.Platform. requires.1.name=Do.not.install.in.IDE requires.1.range=[0.0.0,0.0.0]
For the RAP project, we've found a solution using p2 match expressions, see bug 385512. I don't know who else is still using the A.PDE.Target.Platform hack, hopefully others could also switch to this approach and the support for the fake IU "A.PDE.Target.Platform" could be cleaned up in PDE...
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
This bug was marked as stalebug a while ago. Marking as wontfix. If this report is still relevant for the current release, please reopen and remove the stalebug whiteboard tag.
