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
_______________________________________________