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

Reply via email to