Adding the dependency only to repository would be fine. But current way to create repositories highly rely on content being available in a feature. That's something that will probably change in the future   , when we'll be able to add any IU to a repository
definition (category.xml). Until then, it's necessary to add it in your feature. But since all Orbit bundles are no-singleton, there is no risk of installation conflict.
For simultaneous release, what about aggregating all orbit content to the site? It would for sure prevent from a lot of installation issues when projects (from Eclipse.org or any other source) don't publish there Orbit dependencies.
On 08/15/2012 10:34 PM, David M Williams wrote:
Forgot to CC cross-project list as I had intended.
As some of you may be discovering, if your orbit requirements do not seem to be available during aggregation, then I think that means you have been "getting them for free" before but are not now,
if not all repositories are enabled.
I think the solution is to include them in your own features (and repositories).
Feel free to ask to this list if questions.
----- Forwarded by David M Williams/Raleigh/IBM on 08/15/2012 04:30 PM -----
From: David M Williams/Raleigh/IBM
To: "Wenz, Michael"
Date: 08/15/2012 11:01 AM
Subject: Where are Orbit pre-reqs?
> currently the aggregation fails because of a missing Graphiti
> dependency which comes from Orbit. The exact same setup worked for
> me in Juno, so I wonder where the Orbit bundles came from up till now.
> Are there any changes in respect to how to consume Orbit bundles or
> has anything accidentally been dropped? I have seen missing Orbit
> references also in other contributions, e.g. EGit.
There's been no changes, except I suspect you have been getting them "for free" before, because someone else had them there and who ever that was is not yet in the kepler train.
The way it is supposed to work, is if someone needs something from Orbit, that they "include" it in one of their own features, and ship it themselves, so that way it is always available independent
of what others do.
Make sense? That is, is that enough info for you to fix? Sounds like you'll have to change your build and feature definitions a little? If you need more "how to" help, it will depend on how you
do your build in the first place, but feel free to ask.
I'm sending to cross-project list too ... since this is always a favorite topic :/ .
From: "Wenz, Michael"
To: David M Williams/Raleigh/IBM@IBMUS,
Date: 08/15/2012 10:38 AM
Subject: RE: [keplerAggregation] Failed for build 2012-08-15_08-45-53
currently the aggregation fails because of a missing Graphiti dependency which comes from Orbit. The exact same setup worked for me in Juno, so I wonder where the Orbit bundles came from up till now.
Are there any changes in respect to how to consume Orbit bundles or has anything accidentally been dropped? I have seen missing Orbit references also in other contributions, e.g. EGit.
From: David Williams [mailto:david_williams@xxxxxxxxxx]
Sent: Mittwoch, 15. August 2012 14:46
To: Wenz, Michael
Cc: David Williams
Subject: [keplerAggregation] Failed for build 2012-08-15_08-45-53
The following errors occured when building Kepler:
Software being installed: validationSet_main 1.0.0
Missing requirement: org.eclipse.graphiti.export.batik 0.10.0.v20120810-1110 requires 'bundle org.apache.batik.svggen [1.6.0,1.7.0)' but it could not be found
Cannot satisfy dependency: mappedRepo_home_data_httpd_download.eclipse.org_graphiti_updates_milestones 1.0.0 depends on: org.eclipse.graphiti.export.feature.feature.group 0.10.0
Cannot satisfy dependency: org.eclipse.graphiti.export.feature.feature.group 0.10.0.v20120810-1110 depends on: org.eclipse.graphiti.export.batik [0.10.0.v20120810-1110]
Cannot satisfy dependency: validationSet_main 1.0.0 depends on: mappedRepo_home_data_httpd_download.eclipse.org_graphiti_updates_milestones[1.0.0]
Check the log file for more information: https://hudson.eclipse.org/hudson/view/Repository%20Aggregation/job/simrel.kepler.runaggregator/31/console
cross-project-issues-dev mailing list