Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[cdt-dev] Updating orbit version?


as we noticed last week, CDT's target file ( is pointing to an old Orbit version, labelled Luna SR1.  I haven't dealt with Orbit before.  Should we use the Mars version?  That seems to be the right thing to do based on David Williams recent mail (see below).

What is the process to handle orbit?  Should I make 'check Orbit version' a part of our RC1 build process from now on? (see

If we upgrade that version now for 8.7/Mars, I'll re-spin RC3 to provide more soak time.

Any recommendations?


From: cross-project-issues-dev-bounces@xxxxxxxxxxx [cross-project-issues-dev-bounces@xxxxxxxxxxx] on behalf of David M Williams [david_williams@xxxxxxxxxx]
Sent: June 1, 2015 5:07 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Status of Mars "repo report" results

Also, I should remind everyone to use the latest repository from Orbit (R20150519210750). We've had one bug report that the latest from Orbit is not being used (Bug 468505) and it's is unclear if there is a reason for it ... or if things will break for anyone trying to use the latest from Orbit, along with things from Mars (that happen to use the same logging fragment/framework where this was noticed).


From:        David M Williams/Raleigh/IBM@IBMUS
To:        cross-project-issues-dev@xxxxxxxxxxx,
Date:        06/01/2015 03:13 AM
Subject:        [cross-project-issues-dev] Status of Mars "repo report" results
Sent by:        cross-project-issues-dev-bounces@xxxxxxxxxxx

I've fixed (most of) the URLs of the "repo report". You can get to the most recent one from the most recent successful clean build, at
Repo Reports from last successful CLEAN BUILD
That link is always at the top of the "Sim Release" Hudson instance ( )

One surprise, something we don't see often (don't think I ever have for this repository) is that someone is contributing an "invalid jar" to the repo ... normally this comes in the form of an invalid  *jar.pack.gz, but this time, the rare event, is it only the *.jar file. (No pack.gz file is provided, or else the b3 aggregator would fail).
And it is for a new bundle from Orbit,


(And, yes, I checked Orbit, and it is correct in that repository).
Jars that fail to verify (if any)
(which does not have much information, actually, but I documented in the bug how to see more.
I have opened
Bug 467449  to track this issue.

= = = == =

Other reports that deserve special attention (AFAIK, there are bugs opened for these already).

- Missing legal files:
Bundles missing required files
- Unsigned jars (just a few left):
Unsigned bundles and features

- BEPL and GMT have features and plugins, still, that *decrease* in version number from Luna SR2a

Feature versions compared to reference repository
Bundle versions compared to reference repository
- As far as "multiple versions of same plugin", I think that report is looking fair (i.e. most cases are legitimate) but there is one case that really stands out: Use of
org.apache.batik.dom at the 1.6.0 level. We went to a lot of effort to replace that one with 1.6.1 (for security fix), so, please, get it out of your builds and your own repositories, and
make sure Sim. Release repo does not have it. See

List of non-unique versions









Thanks to everyone who have been working hard to clean up previous issues.
My hope is that by RC3 we will be completely "clean". At least for the reports mentioned here, which I take to be the most important,
but, by all means, please work on the others too!

Thanks again,

cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top