Matthias,
Thanks so much for reading all the details!
Sorry, yes the report would be better if it flagged "bad certificates".
It's only become clear recently why some certificates are bad, i.e.,
it's bad when the root certificate in the certificate's chain is expired
and/or is generally no longer included in the certificate store of a
recent/modern Java runtimes. But the APIs for getting this information
out of a certificate are kind of horrible and of course we don't
generally know which certificates are shipped by all the Java runtimes...
I also think there are some report shortcomings in terms of resolving
java-package dependencies when producing the SimRel report (which hows
only a subset of IUs of the repos involved); that in combination with
"no bad certificate diagnostics" also doesn't help you notice such issues.
Of course GEF is doing a great job providing quality contributions and
GEF is broadly consumed by downstream projects, so we all are very
thankful for your hard work!!
Cheers,
Ed
On 18.11.2019 11:36, Matthias Wienand wrote:
Hi,
thanks for spelling it out for us. The problem was not clear to me
just looking at the reports (I still cannot see what is wrong looking
at it now).
I am following conversation on the lists, but not all discussions in
detail.
I will try to update the GEF dependencies for our M3 contribution.
Best regards,
Matthias
--
Matthias Wienand
B.Sc. Softwaretechnik
Software Engineer
Telefon: +49 231 9860 202
Telefax: +49 231 9860 211
Mobil: +49 176 248 950 82
[email protected] <mailto:[email protected]>
http://www.xing.com/profile/Matthias_Wienand2
http://www.itemis.de
itemis AG
Niederlassung Lünen
Am Brambusch 15-24
44536 Lünen
Rechtlicher Hinweis:
Amtsgericht Dortmund, HRB 20621
Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Abdelghani El-Kacimi
Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus,
Jennifer Fiorentino
Am 18.11.2019 um 10:57 schrieb Ed Merks <[email protected]
<mailto:[email protected]>>:
SimRel Participants,
While we're making progress on improving the state of the SimRel repo
for 2019-12, without the active involvement of the ~80 teams
contributing content, we're still going to fall far short of an
acceptable quality benchmark.
Many projects simply need to do a new build to use the proper and
correct version of SUA 2.0 from CBI *and *to use the latest Orbit
dependencies.
Roland Grunberg has been kind enough to publish a new Orbit I-build
to ensure that there are no bundles signed with expired root
certificates:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=552251
The Orbit dependencies that you contribute to the train should come
from there, and not some antiquated older version. You should also
look closely at whether your contributed or Orbit dependencies align
those contributed by other projects. Currently 55 bundles are
contributed as duplicates which is something we ought to avoid. But
at this point, duplicates is the least of my concern. Just don't
contribute old versions of
com.google.inject.assistedinject_3.0.0.v201402270930 and
org.antlr.runtime_3.0.0.v200803061811.
That mean the ATL teams needs to pay attention
https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/staging/2019-12/index/org.eclipse.m2m.atl.dsls_4.1.0.v201909021645.html#osgi.bundle;_org.antlr.runtime_[3.0.0,3.1.0)
Also the GEF team:
https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/staging/2019-12/index/org.eclipse.gef.mvc.fx.ui_5.1.1.201910161621.html#java.package;_com.google.inject.assistedinject_[1.3.0,1.4.0)
These dependency ranges will force the old problematic version.
What concerns me most is that some teams are completely unresponsive:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=551591
https://bugs.eclipse.org/bugs/show_bug.cgi?id=551550
So it heartens me to see others who have taken active steps:
https://github.com/eclipse/eclipse-collections/issues/763
Out of respect for all those many active participants who work
tirelessly to contribute high quality results, please consider that
your inaction reflects poorly on all of us. In the end, the user
doesn't care or know where things come from, they are faced with
dialogs displaying many "duplicate" licenses, they see dialogs asking
them to accept expired (root) certificates, and dialogs to accept the
installation of unsigned content. It just doesn't give the user a
warm fuzzy feeling that they're about to install something really
great and that undermines the effort of hundreds of us who are
working hard to give a great first impression and well as a lasting
good impression.
This is is the future state for M3 if no further action is taken:
https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/staging/2019-12/index.html
That state is a result of your contributions:
https://download.eclipse.org/oomph/archive/simrel/
I believe there are a significant number of contributions that have
simply died long ago but their input lingers on in a limbo zombie
state. Those will need to be removed... And when one sees
contributions coming from archive.eclipse.org
<http://archive.eclipse.org>, or with neon, oxygen, and photon in the
name, or ending with "snapshots", you know that's likely questionable
and is likely old crap or totally unstable in terms of content.
Regards,
Ed
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
<mailto:[email protected]>
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
