Community
Participate
Working Groups
In an effort to safeguard against issues with RAP being installed into the IDE (such as bug 312547), we created a copy of the RAP Runtime repository with metadata that specify conflicts between certain RAP and RCP bundles which must not be installed together (bug 306709, comments #20+). Unfortunately, these metadata cause the Helios build to fail: Cannot complete the install because some dependencies are not satisfiable ... Cannot satisfy dependency: org.eclipse.rap.ui.forms 1.3.0.20100518-1222 depends on: org.eclipse.ui.forms [1.0.0,4.0.0) In this case "depends on" must be read as "conflicts with" since the conflicts are represented as a "negated" dependency. The full log is available at https://build.eclipse.org/hudson/view/Repository%20Aggregation/job/helios.runAggregator/40/console. Is it possible to let the Helios build exclude RT Target Platforms from the dependency check? The repository URL is http://archive.eclipse.org/rt/rap/1.3/runtime-helios/ .
CC'ing Thomas for his assistance since he knows a lot about the aggregation process.
The mechanism in place to prevent install into the IDE is a fake requirement (namespace "A.PDE.Target.Platform"). The aggregator adds a IU that fulfills that requirement temporarily during the planning phase and then removes it again. Is this mechanism not working for you?
We use the A.PDE.Target.Platform mechanism as well, but it doesn't seem to prevent cases where the RAP runtime is pulled in by optional bundle dependencies, for example bug bug 312547. Moreover, I think that specifying "conflicts" between RAP bundles and related RCP bundles is a preferable way as it reflects the root of the problem: that e.g. org.eclipse.rap.ui must never be installed together with org.eclipse.ui.
(In reply to comment #3) > Moreover, I think that specifying "conflicts" between RAP bundles and related > RCP bundles is a preferable way as it reflects the root of the problem: that > e.g. org.eclipse.rap.ui must never be installed together with org.eclipse.ui. I agree with that. This wasn't a problem in Galileo because you couldn't really describe a conflict like that using p2 requirements. But now you can and that calls for some changes in the way we aggregate. The statement "Everything in the release train must be installable together" just isn't true anymore. The reason we use the planner is that we want to make sure that everything in the release train is coherent and we do indeed discover a lot of discrepancies this way which proves that this validation is really useful. So question is, how do we move forward if we also want to allow conflicts? Ideas are very welcome.
> The reason we use the planner is that we want to make sure that everything in > the release train is coherent and we do indeed discover a lot of discrepancies > this way which proves that this validation is really useful. So question is, > how do we move forward if we also want to allow conflicts? I think in this case having an exclusion list would probably suffice. Then for each of these elements on the exclusion list, a separate resolution can be performed.
Don't know what happened with the dropped dependency to issue 314016 - sorry. I checked history, and there was no other change, I suspect I accidentally committed the previous state of the issue - how it happened without getting a conflict warning, I don't know. Dependency reinstated.
This issue is now being discussed again in bug 373727. So I'll close this one as dup. *** This bug has been marked as a duplicate of bug 373727 ***
