On Thu, Apr 7, 2022 at 3:30 PM Christian Dietrich < christian.dietr...@itemis.de> wrote:
> created https://github.com/eclipse/ebr/pull/53/files > Looks like build went past this issue but next one arise: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile (default-compile) on project org.apache.batik.bridge: Compilation failure: Compilation failure: [ERROR] Source option 6 is no longer supported. Use 7 or later. [ERROR] Target option 6 is no longer supported. Use 7 or later. [ERROR] -> [Help 1] > > Am 07.04.22 um 14:11 schrieb Aleksandar Kurtakov: > > > > On Thu, Apr 7, 2022 at 3:09 PM Christian Dietrich < > christian.dietr...@itemis.de> wrote: > >> i cannot even reproduce this using java18 >> >> mvn ebr:create-recipe -DgroupId=org.antlr -DartifactId=antlr-runtime >> -Dversion=3.5.2 -DbundleSymbolicName=org.antlr.runtime >> -Dmaven.repo.local=.m2 >> > > I see it building orbit-recipes clone. > Java version: openjdk version "18" 2022-03-22 > OpenJDK Runtime Environment 22.3 (build 18+37) > OpenJDK 64-Bit Server VM 22.3 (build 18+37, mixed mode, sharing) > Maven version: Apache Maven 3.8.5 > (3599d3414f046de2324203b78ddcf9b5e4388aa0) > > >> Am 07.04.22 um 14:02 schrieb Aleksandar Kurtakov: >> >> >> >> On Thu, Apr 7, 2022 at 2:12 PM Joakim Erdfelt <joakim.erdf...@gmail.com> >> wrote: >> >>> Regarding your JDK 17/18 support and your aQute issue. >>> >>> [INFO] --- ebr-maven-plugin:1.4.0-SNAPSHOT:bundle (default-bundle) @ >>> org.antlr.runtime --- >>> [INFO] Gathering dependencies >>> [INFO] Configured Artifact: org.antlr:antlr-runtime:3.5.2:jar >>> [INFO] Unpacking >>> /home/akurtakov/.m2/repository/org/antlr/antlr-runtime/3.5.2/antlr-runtime-3.5.2.jar >>> to >>> /home/akurtakov/git/orbit-recipes/antlr/org.antlr.runtime_3.5.2/target/dependency-bin >>> with includes "**/*" and excludes "META-INF/maven/**/*.*" >>> [INFO] Merging collected dependencies >>> [INFO] Using 'UTF-8' encoding to copy filtered resources. >>> [INFO] Copying 118 resources >>> [INFO] Generating OSGi MANIFEST.MF >>> [ERROR] An internal error occurred >>> java.util.ConcurrentModificationException >>> at java.util.TreeMap.callMappingFunctionWithCheck (TreeMap.java:750) >>> at java.util.TreeMap.computeIfAbsent (TreeMap.java:604) >>> at aQute.bnd.osgi.Jar.putResource (Jar.java:288) >>> at aQute.bnd.osgi.Jar$1.visitFile (Jar.java:202) >>> at aQute.bnd.osgi.Jar$1.visitFile (Jar.java:177) >>> at java.nio.file.Files.walkFileTree (Files.java:2811) >>> at aQute.bnd.osgi.Jar.buildFromDirectory (Jar.java:176) >>> at aQute.bnd.osgi.Jar.<init> (Jar.java:119) >>> at aQute.bnd.osgi.Jar.<init> (Jar.java:172) >>> at org.apache.felix.bundleplugin.BundlePlugin.getOSGiBuilder >>> (BundlePlugin.java:604) >>> at org.apache.felix.bundleplugin.ManifestPlugin.getAnalyzer >>> (ManifestPlugin.java:285) >>> at org.apache.felix.bundleplugin.ManifestPlugin.execute >>> (ManifestPlugin.java:111) >>> at org.eclipse.ebr.maven.BundleMojo.buildBundle (BundleMojo.java:358) >>> at org.eclipse.ebr.maven.BundleMojo.execute (BundleMojo.java:462) >>> >>> This is because of an old biz.aQute.bnd lib. >>> Eclipse Jetty hit this same issue early, during the Java-17 Early Access >>> builds. >>> We build all the way up to Java-19 EA now. >>> >>> Update your biz.aQute.bndlib to version 5.3.0 >>> >>> <dependency> >>> <groupId>biz.aQute.bnd</groupId> >>> <artifactId>biz.aQute.bndlib</artifactId> >>> <version>5.3.0</version> >>> </dependency> >>> >>> If you manage the ebr-maven-plugin, then update it there. >>> Otherwise, if you are a simple project using the ebr-maven-plugin, the >>> above dependency in a <dependencyManagement> should be sufficient. >>> >> >> I just don't have the energy to try saving things anymore, if it's >> important enough for many people - it will get saved! Thanks for your hints >> though! >> >> >>> >>> Btw, we LOVE the new Tycho maven P2 repo featureset. >>> It's eliminated a big headache on our releases. >>> We were spending on a good day about 6+ man hours to get an old school >>> P2 repo out per release. >>> On a problematic release it could easily top 40 man hours per release >>> (ugh!). >>> >>> Now it's brain dead simple and just works, with an occasional bump in >>> the Tycho version being used, which is automatically reported to us via the >>> github tooling. >>> >> >> Exactly my experience and I hear/see the same comments everywhere people >> did the change. The more people showing their success stories the better to >> show the real gains. >> >> >>> >>> - Joakim >>> >>> >>> On Thu, Apr 7, 2022 at 1:46 AM Aleksandar Kurtakov <akurt...@redhat.com> >>> wrote: >>> >>>> >>>> >>>> On Thu, Apr 7, 2022 at 9:30 AM Aleksandar Kurtakov <akurt...@redhat.com> >>>> wrote: >>>> >>>>> >>>>> >>>>> On Thu, Apr 7, 2022 at 8:34 AM Ed Merks <ed.me...@gmail.com> wrote: >>>>> >>>>>> Christian, >>>>>> >>>>>> I share your frustrations. Yes, much is being done to make life >>>>>> easier >>>>>> and/or better (direct Maven consumption and Github with github >>>>>> issues) >>>>>> but somehow every change is also disruptive and very often time >>>>>> consuming such that you much spend time on what feels like a gigantic >>>>>> no-op... >>>>>> >>>>>> More comments below. >>>>>> >>>>>> On 07.04.2022 04:54, Christian Dietrich wrote: >>>>>> > Hi all, my frustration of the current state has cost me another >>>>>> > sleepless night and thus i need to start this discussion again. >>>>>> > >>>>>> > All of the following statements are subjective and describe my >>>>>> > personal view and option and feelings. >>>>>> > >>>>>> > Trigger was >>>>>> > >>>>>> https://www.eclipse.org/lists/cross-project-issues-dev/msg19066.html >>>>>> > but is just another big drop to barrel to overflow. >>>>>> > >>>>>> > What is it about: >>>>>> > >>>>>> > - PlatformRel: Release of the basic eclipse platform and jdt on a >>>>>> > regular basis >>>>>> > - SimRel: All project release together with PlatformRel in versions >>>>>> > that work together. This requires the projects to "paying >>>>>> attention" >>>>>> > to ensure this holds true. >>>>>> > - Orbit: Central place to pull 3rd dependencies from. This avoid >>>>>> each >>>>>> > and every project packaging their own stuff and makes it possible >>>>>> for >>>>>> > projects with the same dependency to work together seemlessly. >>>>>> > >>>>>> > Projects: Eclipse has projects with >>>>>> > - some budget >>>>>> > - a limited budget (i would categeorize Xtext with 4-6 days a month >>>>>> here) >>>>>> > - basically no buget >>>>>> EMF, XSD, JustJ and Oomph have been budget free for close to 2 years. >>>>>> > >>>>>> > Projects and values: >>>>>> > - Some projects value support for older platform and java versions, >>>>>> > others dont >>>>>> > - Some projects "pay attention", others dont >>>>>> > >>>>>> EMF tests against Helios. I had been trying to keep Oomph running on >>>>>> Juno, but that was no longer possible with all the nice though >>>>>> disruptive p2 changes for PGP. JustJ keeps up with new Adoptium >>>>>> releases; I'm currently testing Java 18. >>>>>> >>>>>> > Xtext: what do i do for Xtext >>>>>> > - work with community >>>>>> > - fix bug >>>>>> > - develop some smaller features >>>>>> > - pay attention >>>>>> > - fix broken Jenkins files cause infrastructure changes >>>>>> > - test against upstream platform and jdt >>>>>> > - bump versions of 3rd party dependencies >>>>>> > - contribute to upstream project >>>>>> > - .... >>>>>> > >>>>>> Working with the community and as a community is key. So I'm not so >>>>>> happy to see comments like "That's more the problem of SimRel" as if >>>>>> we >>>>>> aren't all part of the same community. I know it's not fair to >>>>>> expect >>>>>> the Platform to solve world hunger, but treating world hunger as >>>>>> someone >>>>>> else's problem is questionable. >>>>>> >>>>>> I know Xtext in particular is used in a vast downstream ecosystem and >>>>>> I >>>>>> know that this consumption makes all the projects upstream from >>>>>> Xtext, >>>>>> including EMF and the Platform more relevant to a broader community. >>>>>> So >>>>>> we should all be concerned about Xtext's welfare. In addition to >>>>>> that, >>>>>> somehow Xtext's downstream ecosystem needs to be leveraged to sponsor >>>>>> these activities, and therein lies a major point of failure. >>>>>> >>>>>> > What makes me frustrated: >>>>>> > >>>>>> > I have the feeling that i spend 95% of my buget to accommodate for >>>>>> > upstream infrastructure changes so that there is basically no time >>>>>> > left for bugfixes or features. The 3 month simrel also adds time >>>>>> > pressure to that "paying attention" if you take it serious. >>>>>> Yes, welcome to my world. It's almost impossible to find time to >>>>>> work >>>>>> on new things in my own technologies. >>>>>> > >>>>>> > The trigger(s): >>>>>> > - https://bugs.eclipse.org/bugs/show_bug.cgi?id=568936 with a >>>>>> cleanup >>>>>> > process in orbit we have to deal with stuff disappearing from >>>>>> orbit. >>>>>> > it is clear that this is a debt in orbit and i am ok with spending >>>>>> a >>>>>> > 2/3 month worth of budget to accomodate for it. >>>>>> > - >>>>>> https://www.eclipse.org/lists/cross-project-issues-dev/msg19066.html >>>>>> > / https://bugs.eclipse.org/bugs/show_bug.cgi?id=579574 >>>>>> > >>>>>> > the 2nd one is the defacto abolishment of orbit. >>>>>> Yes, this doesn't feel like a community decision, does it? And in >>>>>> the >>>>>> end, Orbit can't be abolished because not all things are available as >>>>>> OSGi bundles in Orbit. >>>>>> > >>>>>> > So if Xtext uses ASM and Platform/JDT uses ASM and they should work >>>>>> > together we need to uses the same ASM. >>>>>> >>>>>> The topic here: >>>>>> >>>>>> https://github.com/eclipse-pde/eclipse.pde.ui/issues/11 >>>>>> >>>>>> And here the issue is perhaps also the renaming of the bundle to use >>>>>> the >>>>>> direct Maven name. Does PDE's decision also make the decision for >>>>>> JDT? >>>>>> I don't know... >>>>>> >>>>>> > What does this mean for Xtext >>>>>> > >>>>>> > - We need to be able to support older platforms and java versions >>>>>> with >>>>>> > newer tycho versions + the work for Jenkins file to make this >>>>>> possible >>>>>> > (8 different builds) >>>>>> > - We need to find out how to use the p2 maven feature from oomph >>>>>> (at a >>>>>> > first glance i could not find an option) or replace oomph with >>>>>> target >>>>>> > files. >>>>>> >>>>>> I hope someone will step forward to sponsor this feature; it looks >>>>>> some >>>>>> promising that this will be the case... >>>>>> >>>>>> I think the issue here is mostly that you need bundles in a p2 repo, >>>>>> right? >>>>>> >>>>>> > - Alternatively we can stop supporting more than 1 platform or Java >>>>>> > versions. >>>>>> > >>>>>> That would provide less value to your consumers and make new versions >>>>>> less consumable and less relevant. I very often see very old >>>>>> Platform >>>>>> versions being used because with all the great changes and evolutions >>>>>> in >>>>>> the Platform, also come regressions and breaking changes that hinder >>>>>> adoption and potentially lead to dropping adoption altogether... >>>>>> > I cannot tell how much work this will be because i am neither a >>>>>> tycho >>>>>> > nor a Jenkinsfile nor an Oomph expert. I also have no pointers >>>>>> where >>>>>> > to copy & paste from to make my life easier with that. >>>>>> Perhaps there are some things I can do to help? >>>>>> > >>>>>> > So i dont know if i can make this possible with the budget i have >>>>>> > (even less i can imagine projects with much less budget can do) >>>>>> > >>>>>> > So what can i do: >>>>>> > - support only latest greated and pass the ball downstream >>>>>> What specifically is leading to this inability to support older >>>>>> versions >>>>>> in this specific case? What can be done to mitigate that? >>>>>> > - pull Xtext out of simrel and with it all of its dependencies >>>>>> (that >>>>>> > would also include lsp4e for example) >>>>>> No please. >>>>>> > - stay in simrel but stop "paying attention" and if stuff works >>>>>> together >>>>>> > >>>>>> Would Xtext still work on the latest if you did nothing? >>>>>> > Alternatives: >>>>>> > - why no keep orbit as place for 3rd party dependencies. I dont >>>>>> know >>>>>> > what would need to be done to make use of the p2 maven feature >>>>>> there >>>>>> > instead in the projects on their own. >>>>>> >>>>>> Perhaps a middle ground would be to build/provide an Orbit-like repo >>>>>> that pulls things from Maven and publishes them in the p2 >>>>>> repository. >>>>>> Apparently this is so easy to do, each project should do it itself. >>>>>> But >>>>>> if it's so easy to do, "we" could also do that in a central place as >>>>>> a >>>>>> service to SimRel and to the broader community. If the Platform >>>>>> doesn't >>>>>> want to do that, help with that, nor consume from that, that doesn't >>>>>> prevent providing the same 3rd party Maven bundles being >>>>>> provided/consumed/used by the Platform... >>>>>> >>>>> >>>>> As someone who did a fair part of that work on Platform behalf, down >>>>> to maintaining Orbit bundles, even keeping Orbit and EBR releng working at >>>>> times and etc. - to me Orbit just proved to be extra step for no benefit >>>>> with very few people stepping up to share the burden so the choice had to >>>>> be made - do the work directly and skip the time consuming extra steps or >>>>> let Platform suffer (we are already far behind on many dependencies which >>>>> has the issue that we ship deps with CVEs(e.g. commons-fileupload), no >>>>> support from upstream and etc.). Now that I've seen the faster and easier >>>>> path I don't see much point in doing this extra work as once this happens >>>>> I >>>>> would be left to deal with it on my own again as history has shown to me. >>>>> >>>> >>>> Let me add to the reasons why Orbit/EBR is no longer a go from my side. >>>> Last week I tried working on adding Lucene 9 to it but local build failed >>>> with: >>>> [INFO] --- ebr-maven-plugin:1.4.0-SNAPSHOT:bundle (default-bundle) @ >>>> org.antlr.runtime --- >>>> [INFO] Gathering dependencies >>>> [INFO] Configured Artifact: org.antlr:antlr-runtime:3.5.2:jar >>>> [INFO] Unpacking >>>> /home/akurtakov/.m2/repository/org/antlr/antlr-runtime/3.5.2/antlr-runtime-3.5.2.jar >>>> to >>>> /home/akurtakov/git/orbit-recipes/antlr/org.antlr.runtime_3.5.2/target/dependency-bin >>>> with includes "**/*" and excludes "META-INF/maven/**/*.*" >>>> [INFO] Merging collected dependencies >>>> [INFO] Using 'UTF-8' encoding to copy filtered resources. >>>> [INFO] Copying 118 resources >>>> [INFO] Generating OSGi MANIFEST.MF >>>> [ERROR] An internal error occurred >>>> java.util.ConcurrentModificationException >>>> at java.util.TreeMap.callMappingFunctionWithCheck (TreeMap.java:750) >>>> at java.util.TreeMap.computeIfAbsent (TreeMap.java:604) >>>> at aQute.bnd.osgi.Jar.putResource (Jar.java:288) >>>> at aQute.bnd.osgi.Jar$1.visitFile (Jar.java:202) >>>> at aQute.bnd.osgi.Jar$1.visitFile (Jar.java:177) >>>> at java.nio.file.Files.walkFileTree (Files.java:2811) >>>> at aQute.bnd.osgi.Jar.buildFromDirectory (Jar.java:176) >>>> at aQute.bnd.osgi.Jar.<init> (Jar.java:119) >>>> at aQute.bnd.osgi.Jar.<init> (Jar.java:172) >>>> at org.apache.felix.bundleplugin.BundlePlugin.getOSGiBuilder >>>> (BundlePlugin.java:604) >>>> at org.apache.felix.bundleplugin.ManifestPlugin.getAnalyzer >>>> (ManifestPlugin.java:285) >>>> at org.apache.felix.bundleplugin.ManifestPlugin.execute >>>> (ManifestPlugin.java:111) >>>> at org.eclipse.ebr.maven.BundleMojo.buildBundle >>>> (BundleMojo.java:358) >>>> at org.eclipse.ebr.maven.BundleMojo.execute (BundleMojo.java:462) >>>> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo >>>> (DefaultBuildPluginManager.java:137) >>>> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute >>>> (MojoExecutor.java:301) >>>> at org.apache.maven.lifecycle.internal.MojoExecutor.execute >>>> (MojoExecutor.java:211) >>>> at org.apache.maven.lifecycle.internal.MojoExecutor.execute >>>> (MojoExecutor.java:165) >>>> at org.apache.maven.lifecycle.internal.MojoExecutor.execute >>>> (MojoExecutor.java:157) >>>> at >>>> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject >>>> (LifecycleModuleBuilder.java:121) >>>> at >>>> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject >>>> (LifecycleModuleBuilder.java:81) >>>> at >>>> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build >>>> (SingleThreadedBuilder.java:56) >>>> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute >>>> (LifecycleStarter.java:127) >>>> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:294) >>>> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192) >>>> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105) >>>> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:960) >>>> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:293) >>>> at org.apache.maven.cli.MavenCli.main (MavenCli.java:196) >>>> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native >>>> Method) >>>> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke >>>> (NativeMethodAccessorImpl.java:77) >>>> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke >>>> (DelegatingMethodAccessorImpl.java:43) >>>> at java.lang.reflect.Method.invoke (Method.java:568) >>>> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced >>>> (Launcher.java:282) >>>> at org.codehaus.plexus.classworlds.launcher.Launcher.launch >>>> (Launcher.java:225) >>>> at >>>> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode >>>> (Launcher.java:406) >>>> at org.codehaus.plexus.classworlds.launcher.Launcher.main >>>> (Launcher.java:347) >>>> >>>> So if I want to use Orbit am I on my own to make EBR work with Java >>>> 17/18? Or should I be the one flipping configs/paths/etc. for every >>>> different task I have to do? That way it's plain impossible to do any work. >>>> And yes, I do make sure that Eclipse works just fine on latest JVM so it's >>>> my top priority so can't afford to stick to old JVM as default. >>>> If one wants Orbit to still be considered seriously someone should >>>> step up and make it actually work for all of us (if possible at all with >>>> fast moving Java versions!) and I can assure you that I tried ( >>>> https://github.com/eclipse/ebr/commits?author=akurtakov) but there >>>> are just that many hours in the day and this happened to be lost cause from >>>> the interest I've seem from the community. >>>> >>>> >>>>> >>>>> >>>>>> >>>>>> Would that help at least partially address your current concerns? >>>>>> Or >>>>>> is there something that's broken even with that approach? >>>>>> >>>>>> > Thanks and regards >>>>>> > Christian >>>>>> > >>>>>> _______________________________________________ >>>>>> cross-project-issues-dev mailing list >>>>>> cross-project-issues-dev@eclipse.org >>>>>> To unsubscribe from this list, visit >>>>>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev >>>>>> >>>>> >>>>> >>>>> -- >>>>> Aleksandar Kurtakov >>>>> Red Hat Eclipse Team >>>>> >>>> >>>> >>>> -- >>>> Aleksandar Kurtakov >>>> Red Hat Eclipse Team >>>> _______________________________________________ >>>> cross-project-issues-dev mailing list >>>> cross-project-issues-dev@eclipse.org >>>> To 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 unsubscribe from this list, visit >>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev >>> >> >> >> -- >> Aleksandar Kurtakov >> Red Hat Eclipse Team >> >> _______________________________________________ >> cross-project-issues-dev mailing listcross-project-issues-...@eclipse.org >> To unsubscribe from this list, visit >> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev >> >> -- >> Christian Dietrich (Diplom-Informatiker (BA)) >> Softwareentwickler / -Architekt >> Committer and Co-Lead for Eclipse Xtext >> >> Tel.: +49 (0) 711 / 34 21 91-0 >> Fax.: +49 (0) 711 / 34 21 91-29 >> Mobil: +49 (0) 151 / 173969 17 >> Mail: christian.dietr...@itemis.de >> XING: https://www.xing.com/profile/Christian_Dietrich8 >> Web: http://www.itemis.de >> Skype: christiandietrich1982 >> >> itemis AG >> Niederlassung Süd >> Industriestraße 6 >> 70565 Stuttgart >> >> >> Vorstand/Board: Jens Wagener (Vors./chairman), Dr. Stephan Eberle, >> Abdelghani El-Kacimi, Wolfgang Neuhaus, Franz-Josef Schuermann >> Aufsichtsrat/Supervisory Board: Michael Neuhaus (Vors./chairman), Harald >> Goertz, Eric Swehla >> Sitz der Gesellschaft/Registered Office: Am Brambusch 15-24, 44536 Lünen >> (Germany) >> Registergericht/Registry Court: Amtsgericht Dortmund | HRB 20621 >> _______________________________________________ >> cross-project-issues-dev mailing list >> cross-project-issues-dev@eclipse.org >> To unsubscribe from this list, visit >> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev >> > > > -- > Aleksandar Kurtakov > Red Hat Eclipse Team > > _______________________________________________ > cross-project-issues-dev mailing listcross-project-issues-...@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev > > -- > Christian Dietrich (Diplom-Informatiker (BA)) > Softwareentwickler / -Architekt > Committer and Co-Lead for Eclipse Xtext > > Tel.: +49 (0) 711 / 34 21 91-0 > Fax.: +49 (0) 711 / 34 21 91-29 > Mobil: +49 (0) 151 / 173969 17 > Mail: christian.dietr...@itemis.de > XING: https://www.xing.com/profile/Christian_Dietrich8 > Web: http://www.itemis.de > Skype: christiandietrich1982 > > itemis AG > Niederlassung Süd > Industriestraße 6 > 70565 Stuttgart > > > Vorstand/Board: Jens Wagener (Vors./chairman), Dr. Stephan Eberle, > Abdelghani El-Kacimi, Wolfgang Neuhaus, Franz-Josef Schuermann > Aufsichtsrat/Supervisory Board: Michael Neuhaus (Vors./chairman), Harald > Goertz, Eric Swehla > Sitz der Gesellschaft/Registered Office: Am Brambusch 15-24, 44536 Lünen > (Germany) > Registergericht/Registry Court: Amtsgericht Dortmund | HRB 20621 > _______________________________________________ > cross-project-issues-dev mailing list > cross-project-issues-dev@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev > -- Aleksandar Kurtakov Red Hat Eclipse Team
_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
