Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[cross-project-issues-dev] Singleton source bundles? (answer: no)

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,
Eclipse-SourceBundle: org.eclipse.platform;version="4.4.0.v20140504-2000";roots:="platformsrc"
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,  
 Eclipse-SourceBundle: org.eclipse.jgit;version="3.3.0";roots="."

Whereas the actual code bundle it goes with is

(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 3.3.0.*?)

So, I suggest to everyone, no "singleton source bundles" and use exact 4 part versions in Eclipse-SourceBundle directive.

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


From:        Matthias Sohn <matthias.sohn@xxxxxxxxx>
To:        recommenders-dev@xxxxxxxxxxx,
Cc:        Shawn Pearce <sop@xxxxxxxxxx>, Chris Aniszczyk <caniszczyk@xxxxxxxxx>, David M Williams/Raleigh/IBM@IBMUS
Date:        05/06/2014 02:56 AM
Subject:        Re: [lunaAggregation] 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 
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> wrote:
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, org.eclipse.jgit.source]

Cannot satisfy dependency: mappedRepo_home_data_httpd_download.eclipse.org_egit_staging_v3.4.0.201405051725-m7 1.0.0 depends on: []

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: 0.0.0

Cannot satisfy dependency: depends on: org.eclipse.jgit.source []

Cannot satisfy dependency: 2.1.0.v20140505-0724 depends on: [2.1.0.v20140505-0720]

Cannot satisfy dependency: 2.1.0.v20140505-0720 depends on: org.eclipse.jgit.source []

Cannot satisfy dependency: validationSet_main 1.0.0 depends on: mappedRepo_home_data_httpd_download.eclipse.org_egit_staging_v3.4.0.201405051725-m7 [1.0.0]

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 [1.0.0]

Check the log file for more information:

Back to the top