I don't know if this is the only problem
with aggregation failure in email below, but I do notice JGit has source
bundles marked as "singleton's". I've seen cases before
where this interferes with "installs" (well, at at least with
b3 aggregation, which checks if two singleton's are "trying"
to be installed together ... which doesn't really hurt at runtime ... one
of them wins, the other doesn't ... but the b3 aggregator is trying to
be "extra sure" that things can be installed together and play
nicely with each other ... if someone else "includes" your source
bundles as part of an SDK feature, then it could interfere, if they were
singleton's ... one way or the other).
Especially, the reason source bundles
never have to be singletons (as far as I know) is that the "Eclipse-SourceBundle"
directive typically specifies a very precise version of code it goes with.
As one example,
goes with exactly the code bundle that
is versioned 4.4.0.v20140504-2000.
That is all computed and "filled
in" at build time, of course, or at most, someone may have to specify
4.4.0.qualifier and the qualifier is determined (for code and source bundle)
at build time.
But I notice in one of the JGit source
bundles, in addition to it being marked a singleton, it says, only,
Whereas the actual code bundle it goes
with is 184.108.40.206403021825-r
(Honestly, I'm not sure how Eclipse,
such as debugger, resolves inexact matches in source bundles ... if 3.3.0
"goes with" anything greater than 3.3.0? Or exactly 3.3.0? or
So, I suggest to everyone, no "singleton
source bundles" and use exact 4 part versions in Eclipse-SourceBundle
I'm posting this to cross-project list
(instead of just replying to your email) because I've seen this elsewhere,
recently (Bug 429797
) so thought maybe others could profit
from the knowledge?
Thanks for letting me know about it
(and, again, not sure if that's the only issue in this particular "failed
build" case ... but appears to be one of them).
Matthias Sohn <matthias.sohn@xxxxxxxxx>
Shawn Pearce <sop@xxxxxxxxxx>,
Chris Aniszczyk <caniszczyk@xxxxxxxxx>, David M Williams/Raleigh/IBM@IBMUS
05/06/2014 02:56 AM
Failed for build 2014-05-06_02-46-13
Hi code recommenders,
I updated the JGit and EGit contribution for Luna M7 to
and you seem to have a hard requirement on the older version 220.127.116.11403021825-r
so please fix your dependencies accordingly.
I am not sure why this breaks the aggregation build.
On Tue, May 6, 2014 at 8:46 AM, David Williams <david_williams@xxxxxxxxxx>
The following errors occured when building Luna:
Software being installed: validationSet_main 1.0.0
Only one of the following can be installed at once: [org.eclipse.jgit.source
18.104.22.168403021825-r, org.eclipse.jgit.source 22.214.171.124405051725-m7]
Cannot satisfy dependency: mappedRepo_home_data_httpd_download.eclipse.org_egit_staging_v126.96.36.199405051725-m7
1.0.0 depends on: org.eclipse.jgit.source.feature.group [188.8.131.52405051725-m7]
Cannot satisfy dependency: mappedRepo_home_data_httpd_download.eclipse.org_recommenders_updates_simrel_luna_2014-05-05_03-59-56
1.0.0 depends on: org.eclipse.recommenders.simrel.feature.source.feature.group
Cannot satisfy dependency: org.eclipse.jgit.source.feature.group 184.108.40.206405051725-m7
depends on: org.eclipse.jgit.source [220.127.116.11405051725-m7]
Cannot satisfy dependency: org.eclipse.recommenders.simrel.feature.source.feature.group
2.1.0.v20140505-0724 depends on: org.eclipse.recommenders.snipmatch.rcp.feature.source.feature.group
Cannot satisfy dependency: org.eclipse.recommenders.snipmatch.rcp.feature.source.feature.group
2.1.0.v20140505-0720 depends on: org.eclipse.jgit.source [18.104.22.168403021825-r]
Cannot satisfy dependency: validationSet_main 1.0.0 depends on: mappedRepo_home_data_httpd_download.eclipse.org_egit_staging_v22.214.171.124405051725-m7
Cannot satisfy dependency: validationSet_main 1.0.0 depends on: mappedRepo_home_data_httpd_download.eclipse.org_recommenders_updates_simrel_luna_2014-05-05_03-59-56