Community
Participate
Working Groups
In playing around with bug 364928, it appears that specifying <required namespace='A.PDE.Target.Platform' ... suffices to get he aggregator to not insist that the bundle be installable in IDE. It would be nice if this "magic namespace" could be passed in as a -D java property so that when someone needs to use something else to prevent installation into IDE, they can use what they want, and the aggregator still be accommodating. It'd be best to allow a list, in case we needed several, such as -Dnonide="A.PDE.Target.Platform,com.google.gwt.user".
In general, I think the "A.PDE.Target.Platform" is a kludge, and at best a workaround for a problem that has a much more elegant solution. 1. The IDE (or whatever "thing" that some IU should be installed into), must expose some IU or property that identifies it. 2. The IU's that should be prevented from installing into an IDE should then have a negative requirement for that IU or property. IIRC, this was suggested early on when the "A.PDE.Target.Platform" first entered the scene but the solution was then rejected because it was too late in the cycle. Seems to me that inventing more new IU's that doesn't really exists (and hence build more functions around a kludge that shouldn't be there in the first place), instead of adding negative requirements to things that really does exist is a bad way of moving forward.
Let's explore this idea ... and educate me some more :) First, if I understand it right, currently "runtime only" bundles or features specify a p2.inf file that has something like # this bundle should not be installed into IDE requires.0.namespace = A.PDE.Target.Platform requires.0.name = Cannot be installed into the IDE requires.0.range = 0.0.0 So ... what does a negative requirement look like? Still a few lines in a p2.inf file? Second, we'd have to have a quick conversation with Platform team to see where best to put such a property. I don't think the literal "eclipse sdk product" bundle would be appropriate, since I think some EPP packages (and commercial products) create an IDE without that ... but, granted, there could be one, or two, or three that could be considered "guaranteed" to be in any IDE but never in any "runtime"? A "sub question" of above is where to draw the line? Is there reason to think there is a need to have "RCP apps" treated differently than "IDEs"? Is there a conceivable case of "do not install into an RCP only app? Seems unlikely ... I'm just asking if there is a more general case than the one case IDE case. Third, I'm guessing this would complicate version-to-version upgrades? While that's not "well supported" anyway .... we'd want to be sure to understand that well and know that to say to users and adopters. If we want to do this ... we should get the Platform to add this property in M4 ... then others could "move" to it in M5? The aggregator itself should probably keep the kludge in there at some level, for compatibility or transition ... but, allow it to be turned off (or on) via java property. Thanks for your help.
Adding John Arthorne from Platform for comment. John, do you think there is one or two or three bundles that could be identified as "always in an IDE, but never in a runtime"? I'd assume "workbench" would be one? If you agree, do you think it's feasible to add a special "This is an IDE only property" property to its p2 metadata? I'm suggesting a property, rather than a literal IU, with the assumption that there might not be exactly one that could be guaranteed to always be there, the IU's name itself might change over time or releases, etc., The purpose is to get rid of the current "kludge" where "runtime only" bundles have to specify a funny hard coded "secret string" to know not to install into IDE?
(In reply to comment #2) > So ... what does a negative requirement look like? Still a few lines in a > p2.inf file? > A negative requirement is a p2 requirement with both min and max set to zero. Not sure how that is entered in a p2.inf file. > ... but, granted, there could be one, or > two, or three that could be considered "guaranteed" to be in any IDE but never > in any "runtime"? > Perhaps the synthesized org.eclipse.platform_root could be used?
Thomas, in bug 364928 comment 15, you say <quote> Use a proper solution which could be to use a negative requirement to something that will only be found in the IDE, such as the IDE product itself. When the proper solution is used, then the aggregator must use two validation sets for Juno. One where the IDE product is present and one that contains all features not intended for the IDE. It might be convenient to have a third, abstract validation set, that would the two would extend from. </quote> A follow up question, more relevant on this bug ... if we have two validation sets ... each of them are validated (separately) that they can be "installed together"? (one for ide, one for runtime). ... I am wondering, is that more than what we currently do? I was under the impression that those special "A.PDE.Target.Platform" items were just sort of skipped. Just wanted to clarify explicitly. Thanks.
Today the aggregator starts the validation phase by actually inserting a dummy IU to fulfill the "A.PDE.Target.Platform" requirement into the set of IU's that is validated (perused by the planner). With that in place, everything can be "installed together". It's a dirty workaround with poor separation of concern. What I suggest is that instead of using this workaround (or as things stands right now, instead of extending it further), we should use a solution (negative requirements) that will truly prevent some IUs from being installed in environments where they don't belong. This solution will be perfectly invisible to the aggregator (and all other tools that might deal with the meta-data). Now, if A cannot coexist with B, then we cannot create a validation set that contains both A and B. Hence the need for at least two validation sets. So, yes. That would demand that we do more. On the other hand, we get a much cleaner solution.
After reading though this I have to say that I like this approach with a 'negative requirement' for a certain property. It would solve many of the problems that we have in an elegant way. Has there been any progress in the meantime? @John: What do you think about this approach? Does it sound feasible?
I don't know who else uses the A.PDE.Target.Platform hack, but at least the RAP project would love to replace it with a negative requirement. Not only is it a kludge, it also makes it impossible to install the RAP runtime into a target unless you disable the checkbox "Include required software" because the p2 resolver mechanism otherwise detects the missing requirement to "A.PDE.Target.Platform". In our case we can clearly define the bundle(s) that we're in conflict with. As the RAP runtime provides alternative implementations of platform API, its bundles expose the same packages and extension points as the respective platform bundles. So declaring that e.g. org.eclipse.rap.ui must not be installed together with org.eclipse.ui would be the exact representation of the problem. We've explored this approach almost two years ago (bug 306709) but we could not bring it into the aggregator because the negative requirement broke the build (bug 313873). And no, negative dependencies are not yet supported in the p2.inf file (bug 312937).
Negation sounds like a promising direction. You wouldn't need platform bundles to define some special new property. Every bundle and feature defines both "IU" and either "osgi.bundle" or "org.eclipse.update.feature" properties that could be used for this purpose. For example RAP could expression negation on the particular bundles it is in conflict with, and other more general projects could just express negation on the platform feature: namespace='org.eclipse.update.feature' name='org.eclipse.platform' The only downside is the metadata would not be readable by platform versions prior to 3.6. We can probably get away with that kind of restriction this year but in past years it would have been a blocker (preventing upgrade from Helios to Indigo, for example) The lack of any mechanism to publish such metadata does appear to be a blocker though (bug 312937).
(In reply to comment #9) > > The lack of any mechanism to publish such metadata does appear to be a blocker > though (bug 312937). (In reply to comment #8) > > And no, negative dependencies are not yet supported in the p2.inf file (bug > 312937). I think this would be a requirement to make this idea feasible. How else would people "tweak" their content metadata? Custom java programs? from comment number 4, if a "negative requirement is a p2 requirement with both min and max set to zero" then I've been assuming something like the following would work ... judging from http://wiki.eclipse.org/Equinox/p2/Customizing_Metadata # this bundle should not be installed into IDE requires.0.namespace = org.eclipse.platform_root requires.0.name = Cannot be installed into the IDE requires.0.range = [0,0] But ... trying this from my workspace, and using "export deployable feature" with content metadata generated, the metadata ends up looking like <required namespace='org.eclipse.platform_root' name='Cannot be installed into the IDE' range='raw:[-M,-M]'/> I am not familiar with what "raw:[-M,-M]" means. Is that good? (a negative requirement?) Or essentially an error message?
Two steps forward, three steps back? First, range='raw:[-M,-M]' didn't do much ... even having it there, the feature would still be installed into my IDE ... odd. Next, by pure trial and error, I found that specify all 4 segments as zero would allow the "publisher" to work, so a p2.inf file such as # this bundle should not be installed into IDE requires.0.namespace = org.eclipse.update.feature requires.0.name = org.eclipse.platform requires.0.range = [0.0.0.0,0.0.0.0] would produce metadata like <required namespace='org.eclipse.update.feature' name='org.eclipse.platform' range='[0.0.0.0,0.0.0.0]'/> Indeed this could not be installed in an IDE ... but, could not be installed in a target runtime either (for same reason) from note being able to find the 0.0.0.0 feature: Cannot complete the install because one or more required items could not be found. Software being installed: Testrfeat 1.0.0.201201111621 (testrfeat.feature.group 1.0.0.201201111621) Missing requirement: Testr 1.0.0.201201111621 (testr 1.0.0.201201111621) requires 'org.eclipse.update.feature org.eclipse.platform [0.0.0.0]' but it could not be found Cannot satisfy dependency: From: Testrfeat 1.0.0.201201111621 (testrfeat.feature.group 1.0.0.201201111621) To: testr [1.0.0.201201111621] So .... "a negative requirement is a p2 requirement with both min and max set to zero" must mean something else.
(In reply to comment #11) > First, range='raw:[-M,-M]' didn't do much ... even having it there, the feature > would still be installed into my IDE ... odd. > -M means the smallest possible version in any versioning scheme. So raw:[-M,-M] means exactly this version. Not sure if this has special meaning/use though. http://wiki.eclipse.org/Equinox/p2/Omni_Version
I'm inclined to close this bug since I think that there's very little the aggregator can do about how p2 requirements are published or what the PDE platform will do with them. David, do you have any direct suggestions on how the b3 aggregator could be improved with respect to this, or do you agree that this bug should be moved?
(In reply to comment #13) > I'm inclined to close this bug since I think that there's very little the > aggregator can do about how p2 requirements are published or what the PDE > platform will do with them. > > David, do you have any direct suggestions on how the b3 aggregator could be > improved with respect to this, or do you agree that this bug should be moved? Yes, I agree. It sounds like we just need to figure out how to 'publish' negative requirements, but if you could lend your p2 expertise to giving an example of that, I think it'd be helpful ... but, nothing more for aggregator to do. It seems like the current solution just names an impossible "namespace" (not an IU) as a requirement: <required namespace='A.PDE.Target.Platform' name='Cannot be installed into the IDE' range='0.0.0'/> But, I think you are saying a "negative requirement" is something else: a "negative requirement is a p2 requirement with both min and max set to zero" But that appears to mean something like the following (which didn't work, for me): <required namespace='org.eclipse.update.feature' name='org.eclipse.platform' range='[0.0.0.0,0.0.0.0]'/> But, again, this is a just a p2 question I was hoping you'd clarify with your expertise, nothing for the aggregator to change ... unless you think aggregator, rather then "p2 publisher" should publish negative requirements, from a few choice key words, rather than from a p2.inf file, which doesn't make much intuitive sense to me.
Just yesterday I tried to re-start the discussion about the A.PDE.Target.Platform with the RT-PMC and on the p2-dev mailing list: http://dev.eclipse.org/mhonarc/lists/p2-dev/msg04697.html If we could solve the source of this problem, maybe with the solutions mentioned in comment 6, there would be no need to have the workaround with A.PDE.Target.Platform. But this is independent from this bug report.
(In reply to comment #14) > It seems like the current solution just names an impossible "namespace" (not > an IU) as a requirement: > > <required namespace='A.PDE.Target.Platform' name='Cannot be installed into the > IDE' range='0.0.0'/> > A requirement is not for an IU per se. It needs to be fulfilled by a provided capability. An IU that provides a capability with the name 'Cannot be installed into the IDE' in the 'A.PDE.Target.Platform' will fulfill the requirement. > But, I think you are saying a "negative requirement" is something else: a > "negative requirement is a p2 requirement with both > min and max set to zero" > > But that appears to mean something like the following (which didn't work, for > me): > > <required namespace='org.eclipse.update.feature' name='org.eclipse.platform' > range='[0.0.0.0,0.0.0.0]'/> > min and max has nothing to do with the version range. They are attributes adjacent to the range in the <required> element. They refer to how many times the requirement must be matched in order to be fulfilled. P2 uses this to describe several different things. For instance: If min is zero and max > 0, then the requirement is optional. It makes sense since this means that at least zero matches must be found and that it is OK to find more than zero. If min is one, then the requirement must be matched at least once. Hence, it's not optional. If max is one, then the requirement must be matched no more than once. This can be used for OSGi singletons for instance. The p2 planner will then complain if no plan can be computed without matching more than once. If max is zero, then the requirement is only met when no matches are found. This is why we call it a negative requirement. It's negative because it means "do NOT match this" With that clarification, I'll close this bug (as invalid in lack of better status).
(In reply to comment #15) > Just yesterday I tried to re-start the discussion about the > A.PDE.Target.Platform with the RT-PMC and on the p2-dev mailing list: > > http://dev.eclipse.org/mhonarc/lists/p2-dev/msg04697.html > > If we could solve the source of this problem, maybe with the solutions > mentioned in comment 6, there would be no need to have the workaround with > A.PDE.Target.Platform. But this is independent from this bug report. Yes, I opened this bug to have a more flexible approach than only, literally, "A.PDE.Target.Platform" (someone from Orbit had come up with similar thing, but different name) ... which they have subsequently changed to "A.PDE.Target.Platform". So, I don't think we need the aggregator to be more flexible, and should focus on the "right" solution. [As an aside: even without the easy to publish negative constraints, I _might_ look at dividing up the "runtime" and "ide" contributions just to "get ready" for the day. In my free time ... which means, pretty unlikely as nice as it'd be to do.] Thomas, thanks for the eduction in comment 16 ... as they say, its a good thing open source is free or else I would not be able to afford the price of your expertise. :)
(In reply to comment #17) > ... I would not be able to afford the price of your expertise. :) I guess that part is mutual :)
[Bookkeeping change only. Moving bugs to the new "home" of aggregator, CBI. No change to assignee for resolved and verified bugs.]
