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 matthias.wien...@itemis.de 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 <ed.me...@gmail.com>: > > 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 > <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_ > > <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_ > > <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=551591> > https://bugs.eclipse.org/bugs/show_bug.cgi?id=551550 > <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 > <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 > > <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/ > <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, 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 > cross-project-issues-dev@eclipse.org > 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 cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev