The discussion seem to have gotten side-tracked around the
already-fixed problem:
Should I review and submit this Gerrit patch myself or will
someone else do that? I'm never quite sure of the appropriate
process here...
Folks,
I've been working on a tool that generates a quality report for
p2 repositories. The initial prototype is now complete. I've
documented it here:
https://wiki.eclipse.org/Oomph_Repository_Analyzer
Things are in pretty rough shape overall.
Given that the Platform team is among the most skilled at
managing their builds properly, I though it would be best to
begin cleaning shop ourselves before approaching the broader
release train participants (which unfortunately I'm quite sure
will be like trying to herd cats).
I now generate the following page for the Platform's current
IBuilds:
https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/eclipse/updates/4.13-I-builds/index.html
My biggest concern is the licenses, because quite frankly,
that's a disaster area. As Vikas has already observed, this
results in what appear to be duplicate license prompts:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=549523
https://bugs.eclipse.org/bugs/attachment.cgi?id=279381
This is embarrassing to Eclipse and annoying to the users.
Only collectively as a group can we can fix this.
There are two major causes for this problem with regard to the
Platform.
The first cause is that all the Platform's products have in
some way messed up the trademark symbol. I've opened this
Bugzilla and included a Gerrit commit with the fixes:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=550572
(Too bad Tycho doesn't like ™ but good that it's okay
with ™
because I think using the actual
unicode symbol is just begging for someone to corrupt it again.)
The second cause stems from the fact that CBI produced two bad
variants of SUA 2.0. So you'll see that the CBI license
composite does not contain a valid SUA 2.0.
https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/cbi/updates/license/index.html
The valid one is located in this repo:
http://download.eclipse.org/cbi/updates/license/2.0.2-SNAPSHOT
But it's been almost a year ago that it was fixed and then it
stalled:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=537927
So let's just compose that into the composite to solve the
problem, right?
That unfortunately is also a problem, because the license is
copied into the feature's artifact and all the platform's
features look like this:
<feature
id="org.eclipse.jdt"
label="%featureName"
version="3.18.100.qualifier"
provider-name="%providerName"
license-feature="org.eclipse.license"
license-feature-version="0.0.0">
I.e., they in no way restrict the version, so if the version
resolves to a different version (from using an updated
composite), the IU metadata will be different and the actual
artifacts will be different too. You can look at this artifact
to confirm that this is the case:
https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/eclipse/updates/4.13-I-builds/http___download.eclipse.org_eclipse_updates_4.13-I-builds_I20190828-1800/org.eclipse.jdt.feature.jar_3.18.100.v20190828-1800.html
I.e., the feature.properties in this artifact has the license
but that information is not present in the Git version of
feature.properties. Also the license.html itself is copied into
the artifact during the build.
So the question is how are we going to fix this in a way
that ensures we produce new IU versions for all features?
That sounds like a lot of work!
Also of concern is unsigned content, but only
org.eclipse.jdt.core.compiler.batch falls in that category, so
that seems easy to address. Hopefully someone will.
Finally there are many missing pack200 artifacts. Although this
isn't a huge problem---it doesn't break anything---it does
result in increased network traffic. The pack200 versions are
generally from 50% to 30% the size of the original *.jar, so
jdt.core at 6.6M just by itself could save quite some traffic.
Why are are so so many pack200 artifacts missing? Is
this easy for us to fix?
Regards,
Ed