Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 313873

Summary:	Include RAP repository with conflict-dependencies against RCP into Helios build
Product:	Community	Reporter:	Ralf Sternberg <rsternberg>
Component:	Cross-Project	Assignee:	Cross-Project issues <cross-project.inbox>
Status:	RESOLVED DUPLICATE	QA Contact:
Severity:	normal
Priority:	P3	CC:	b.muskalla, ekke, henrik.lindberg, pascal, thomas
Version:	unspecified
Target Milestone:	---
Hardware:	All
OS:	All
Whiteboard:
Bug Depends on:	314016
Bug Blocks:	306709

Description Ralf Sternberg

2010-05-21 03:50:34 EDT

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/ .

Comment 1 Pascal Rapicault

2010-05-21 09:22:50 EDT

CC'ing Thomas for his assistance since he knows a lot about the aggregation process.

Comment 2 Thomas Hallgren

2010-05-21 09:33:35 EDT

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?

Comment 3 Ralf Sternberg

2010-05-21 09:59:18 EDT

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.

Comment 4 Thomas Hallgren

2010-05-21 10:09:40 EDT

(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.

Comment 5 Pascal Rapicault

2010-05-21 11:30:26 EDT

 > 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.

Comment 6 Henrik Lindberg

2010-05-24 08:37:35 EDT

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.

Comment 7 Ralf Sternberg

2012-03-09 05:54:45 EST

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 ***