Re: [cross-project-issues-dev] Eclipse IDE 2024-06 Project Participation Page
Hello, There were missing records for Acceleo and EMF Compare. Acceleo will release version 3.7.16 EMF Compare will release 3.3.24 Thanks, Laurent Le 22/05/2024 à 23:56, Wayne Beaton via cross-project-issues-dev a écrit : Greetings folks! I've assembled the release information for participating projects here <https://projects.eclipse.org/releases/2024-06>. Note that the list of projects reflects our long time practice of only including projects whose teams are actively participating in the simultaneous release. If you look hard enough, you'll notice that projects that have been "sponsored in" by participating projects are absent from the list. This is per the requirements. I expect that these requirements will change in some future release. A lot of the releases are quite old, and based on the activity in the simrel.build <https://github.com/eclipse-simrel/simrel.build> repository, at least a few projects need to create some release records, and some may need to engage in a progress review (I've done my usual thing of making by best guess based on the release records in the system). If your project is contributing a different release than what you see here, please ensure that you've created a release record <https://www.eclipse.org/projects/handbook/#pmi-commands-release>, and let me know. If your project has not engaged in a progress (or release) review <https://www.eclipse.org/projects/handbook/#progress-review> in more than one year, please engage with the EMO ASAP to schedule a review. Be sure to set the New and Noteworthy URL in your release record: it is through this relationship that we build the aggregate N Please make sure that you've made your best effort to engage in the IP Due Diligence Process for all third party content before you engage with the EMO for review. Bear in mind that you should be engaging in the IP Due Diligence Process <https://www.eclipse.org/projects/handbook/#ip-third-party> on an ongoing basis and that all releases (regardless of whether or not they correspond with a progress or release review) must only contain content that has been vetted through the due diligence process. With the Eclipse Dash License Tool <https://github.com/eclipse/dash-licenses> and the ability to use it to automatically create review requests, it should be /easier than ever/ before to engage (the README has extensive information on how to engage, and does include some pointers for using it with Eclipse Tycho <https://github.com/eclipse/dash-licenses#eclipse-tycho>-based builds). Connect with the EMO if you need assistance. Here are some things that I've observed: Eclipse Client Platform has been removed. The aggrcon files for the following projects are disabled; if any of these projects are dropping from the release, please let me know: * Eclipse Xpand * Eclipse BPMN2 Modeler Project * Eclipse RCPTT Let me know what I've missed. Thanks, Wayne -- Wayne Beaton Director of Open Source Projects | Eclipse Foundation My working day may not be your working day! Please don’t feel obliged to read or reply to this e-mail outside of your normal working hours. ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To unsubscribe from this list, visithttps://www.eclipse.org/mailman/listinfo/cross-project-issues-dev -- *Laurent Goubet* Consultant +33 2 51 13 51 42 <https://www.obeo.fr/> 7 Boulevard Ampère - Carquefou - France *obeo.fr* <https://www.obeo.fr/> | *twitter* <https://twitter.com/obeo_corp> | *linkedin* <https://www.linkedin.com/company/obeo> ___ 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
Re: [cross-project-issues-dev] ACTION REQUIRED: Acceleo, Sirius, EMF Compare, CDO, GEF 5, RCPTT
Hello Ed, You've raised issues for the Guava versions, but I expect you're trying to get rid of all duplicates. From what I'm seeing, you've removed the 4.7 version of antlr from the latest orbit build - https://download.eclipse.org/tools/orbit/simrel/orbit-aggregation/2023-12/ which only contains antlr 4.13. This version is not used by anyone according to https://download.eclipse.org/staging/2023-12/buildInfo/archive/download.eclipse.org/staging/2023-12/ . Moving from one version of antlr to the next is not a trivial task, so I (and probably the other users of antlr 4.7), would like to avoid that. You mention that "The 4.x versions are available as OSGi bundles" (https://github.com/eclipse-orbit/orbit-simrel/commit/85f7256abe6b90f023de4bfabb09f1416f100a67). What does that mean? Now, what I'm planning to do for Acceleo is to retrieve antlr from the older orbit (2023-09), so there will remain older versions of that dependency in 2023-12 RC1. With how orbit looks now, what is the expectation for dependencies such as antlr which are not easily updateable? How do we re-add older versions if we need them? Regards, Laurent Le 17/11/2023 à 11:46, Ed Merks via cross-project-issues-dev a écrit : I now have a first hit list. Old guava versions will be eliminated: https://github.com/eclipse-simrel/simrel.build/issues/80 If you do not eliminate all dependencies on older versions of guava via an updated contribution, then I reserve the option, and am likely to excise the option, to disable your contribution, without further notification. ___ 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 -- *Laurent Goubet* Consultant +33 2 51 13 51 42 <https://www.obeo.fr/> 7 Boulevard Ampère - Carquefou - France *obeo.fr* <https://www.obeo.fr/> | *twitter* <https://twitter.com/obeo_corp> | *linkedin* <https://www.linkedin.com/company/obeo> begin:vcard fn:Laurent Goubet n:Goubet;Laurent org:http://www.obeo.fr;>Obeo email;internet:laurent.gou...@obeo.fr url:http://www.obeo.fr version:2.1 end:vcard ___ 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
Re: [cross-project-issues-dev] ACTION REQUIRED: Houston We Have a Problem
A mistake from my end... Thanks for catching that so quickly. I've updated my simrel contribution to https://download.eclipse.org/acceleo/updates/milestones/3.7/S202211151354 . Le 15/11/2022 à 14:30, Ed Merks a écrit : Laurent, It looks like this build was literally done with no signing. One should find files META-INF folder but there's on the MANIFEST.MF https://download.eclipse.org/acceleo/updates/milestones/3.7/S202211151309/features/org.eclipse.acceleo.doc_3.7.12.202211151309.jar On 15.11.2022 14:24, Laurent Goubet wrote: Hi Ed, Acceleo 3.7.12 built using the latest Orbit I build (https://download.eclipse.org/tools/orbit/downloads/drops/I20221112145035) and contributed to the simrel through https://git.eclipse.org/r/c/simrel/org.eclipse.simrel.build/+/196955 . Please let me know if this doesn't solve the issue for Acceleo. Regards, Laurent Le 14/11/2022 à 13:43, Ed Merks a écrit : Recent versions of Java, including the most recent Java 17 release, now consider some jar-signed bundles to be unsigned. This affects all bundles and features signed between January 1, 2019 and April 14, 2022 with the Eclipse certificate available at that time. This is a *very *long list with many affected projects: https://download.eclipse.org/oomph/archive/reports-extra/staging-2022-12/download.eclipse.org/staging/2022-12/index.html The Platform has resigned their problematic bundles already: https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/issues/661 Orbit too has resigned the problematic bundles: https://bugs.eclipse.org/bugs/show_bug.cgi?id=581039 But the Orbit repo with the resigned bundles is *NOT *the one used by the Platform for their M3 contribution and is not the one you/we should be using for M3 which is this one: https://download.eclipse.org/tools/orbit/downloads/drops/S20221109014815/repository *These projects need to do new builds*: * *org.eclipse.acceleo* * *org.eclipse.bpmn2* * *org.eclipse.dltk* * *org.eclipse.ecf* * *org.eclipse.eef* * *org.eclipse.emf.edapt* * *org.eclipse.emf.parsley* * *org.eclipse.fx* * *org.eclipse.gmf* * *org.eclipse.mylyn* * *org.eclipse.uml2* You should *ensure that the qualifiers of your bundles and features are newer than 2021-04*, so that you don't have two the "same artifacts" but with different signatures, which is especially important if you are doing baseline replacement in your build. I can help test your repository if you need help. Please reach out to me. *Everyone **needs to ensure that they consume from the next RC1 version of Orbit*, otherwise we are likely to end up with massive duplicate Orbit bundles and that is likely to cause problems. I hope someone from Mylyn is paying attention! https://bugs.eclipse.org/bugs/show_bug.cgi?id=581029 Meanwhile, I'm trying to enable PGP signing of the bundles and features with this poor certificates to "repair" them. But, Tycho does appear to detect that a signature will be ignored, provides no way to specify how to treat artifacts that already have a PGP signature (it actually produces duplicate properties in the artifacts.xml), and it appears the PGP signatures for features are invalid, so I'm not sure I'll be 100% successful in finding a workaround. The following might be the best I can do on your behalf unless the PGP feature signing issue is fixed: https://download.eclipse.org/oomph/archive/reports-extra/2022-12-gpg/download.eclipse.org/staging/2022-12-gpg/index.html Note that in this scenario, I am *adding *the sim-bot PGP key/signature in addition to the key/signature already present from the project. So all PGP-signed bundles will generally have two PGP signatures, and in this exceptional case, the bundle is jar-signed and has two PGP signatures: https://download.eclipse.org/oomph/archive/reports-extra/2022-12-gpg/download.eclipse.org/staging/2022-12-gpg/index/bcpg_1.72.0.html With PGP-signed features, p2 fails to validate them making them impossible to download/install, so in this case the cure is worse than the disease: https://download.eclipse.org/oomph/archive/reports-extra/2022-12-gpg-bad/download.eclipse.org/staging/2022-12-gpg-bad/index/org.eclipse.acceleo.equinox.launcher.feature.jar_3.7.11.202102190929.html Perhaps this issue can be fixed in the coming days... Regards, Ed ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To unsubscribe from this list, visithttps://www.eclipse.org/mailman/listinfo/cross-project-issues-dev -- *Laurent Goubet* Consultant +33 2 51 13 51 42 <https://www.obeo.fr/> 7 Boulevard Ampère - Carquefou - France *obeo.fr* <https://www.obeo.fr/> | *twitter* <https://twitter.com/obeo_corp> | *linkedin* <https://www.linkedin.com/company/obeo> ___
Re: [cross-project-issues-dev] ACTION REQUIRED: Houston We Have a Problem
Hi Ed, Acceleo 3.7.12 built using the latest Orbit I build (https://download.eclipse.org/tools/orbit/downloads/drops/I20221112145035) and contributed to the simrel through https://git.eclipse.org/r/c/simrel/org.eclipse.simrel.build/+/196955 . Please let me know if this doesn't solve the issue for Acceleo. Regards, Laurent Le 14/11/2022 à 13:43, Ed Merks a écrit : Recent versions of Java, including the most recent Java 17 release, now consider some jar-signed bundles to be unsigned. This affects all bundles and features signed between January 1, 2019 and April 14, 2022 with the Eclipse certificate available at that time. This is a *very *long list with many affected projects: https://download.eclipse.org/oomph/archive/reports-extra/staging-2022-12/download.eclipse.org/staging/2022-12/index.html The Platform has resigned their problematic bundles already: https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/issues/661 Orbit too has resigned the problematic bundles: https://bugs.eclipse.org/bugs/show_bug.cgi?id=581039 But the Orbit repo with the resigned bundles is *NOT *the one used by the Platform for their M3 contribution and is not the one you/we should be using for M3 which is this one: https://download.eclipse.org/tools/orbit/downloads/drops/S20221109014815/repository *These projects need to do new builds*: * *org.eclipse.acceleo* * *org.eclipse.bpmn2* * *org.eclipse.dltk* * *org.eclipse.ecf* * *org.eclipse.eef* * *org.eclipse.emf.edapt* * *org.eclipse.emf.parsley* * *org.eclipse.fx* * *org.eclipse.gmf* * *org.eclipse.mylyn* * *org.eclipse.uml2* You should *ensure that the qualifiers of your bundles and features are newer than 2021-04*, so that you don't have two the "same artifacts" but with different signatures, which is especially important if you are doing baseline replacement in your build. I can help test your repository if you need help. Please reach out to me. *Everyone **needs to ensure that they consume from the next RC1 version of Orbit*, otherwise we are likely to end up with massive duplicate Orbit bundles and that is likely to cause problems. I hope someone from Mylyn is paying attention! https://bugs.eclipse.org/bugs/show_bug.cgi?id=581029 Meanwhile, I'm trying to enable PGP signing of the bundles and features with this poor certificates to "repair" them. But, Tycho does appear to detect that a signature will be ignored, provides no way to specify how to treat artifacts that already have a PGP signature (it actually produces duplicate properties in the artifacts.xml), and it appears the PGP signatures for features are invalid, so I'm not sure I'll be 100% successful in finding a workaround. The following might be the best I can do on your behalf unless the PGP feature signing issue is fixed: https://download.eclipse.org/oomph/archive/reports-extra/2022-12-gpg/download.eclipse.org/staging/2022-12-gpg/index.html Note that in this scenario, I am *adding *the sim-bot PGP key/signature in addition to the key/signature already present from the project. So all PGP-signed bundles will generally have two PGP signatures, and in this exceptional case, the bundle is jar-signed and has two PGP signatures: https://download.eclipse.org/oomph/archive/reports-extra/2022-12-gpg/download.eclipse.org/staging/2022-12-gpg/index/bcpg_1.72.0.html With PGP-signed features, p2 fails to validate them making them impossible to download/install, so in this case the cure is worse than the disease: https://download.eclipse.org/oomph/archive/reports-extra/2022-12-gpg-bad/download.eclipse.org/staging/2022-12-gpg-bad/index/org.eclipse.acceleo.equinox.launcher.feature.jar_3.7.11.202102190929.html Perhaps this issue can be fixed in the coming days... Regards, Ed ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To unsubscribe from this list, visithttps://www.eclipse.org/mailman/listinfo/cross-project-issues-dev -- *Laurent Goubet* Consultant +33 2 51 13 51 42 <https://www.obeo.fr/> 7 Boulevard Ampère - Carquefou - France *obeo.fr* <https://www.obeo.fr/> | *twitter* <https://twitter.com/obeo_corp> | *linkedin* <https://www.linkedin.com/company/obeo> begin:vcard fn:Laurent Goubet n:Goubet;Laurent org:http://www.obeo.fr;>Obeo email;internet:laurent.gou...@obeo.fr url:http://www.obeo.fr version:2.1 end:vcard ___ 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
Re: [cross-project-issues-dev] JGit/EGit contribution to M1 will be late
I pushed our contribution [1] though the simrel validation build fails [2] with the error 22:27:06 [0]Missing requirement: EMF Compare EGit Support 1.2.4.202107200824 (org.eclipse.emf.compare.egit 1.2.4.202107200824) requires 'osgi.bundle; org.eclipse.jgit [4.9.0,6.0.0)' but it could not be found 22:27:06 22:27:06 Bundle(org.eclipse.jgit [4.9.0,6.0.0)) is required by: 22:27:06 ValidationSet(main) 22:27:06 Contribution(EMF Compare) 22:27:06 MappedRepository(https://download.eclipse.org/modeling/emf/compare/updates/milestones/3.3/S202107200824) 22:27:06 Feature(org.eclipse.emf.compare.egit.feature.group) 22:27:06 InstallableUnit(org.eclipse.emf.compare.egit 1.2.4.202107200824) because org.eclipse.emf.compare.egit requires org.eclipse.jgit [4.9.0,6.0.0). This can't work since JGit/EGit bumped their version to 6.0 (our M1 contribution is 6.0.0.202110060947-m1) as announced earlier on this list [3]. org.eclipse.emf.compare.egit needs to bump the upper boundary of the jgit/egit version they require to allow 6.0.x. How can I get our contribution in ? Disable the emf.compare contribution until they fixed this version range ? [1] https://git.eclipse.org/r/c/simrel/org.eclipse.simrel.build/+/186244 [2] https://ci.eclipse.org/simrel/job/simrel.runaggregator.VALIDATE.gerrit/2436/console [3] https://www.eclipse.org/lists/cross-project-issues-dev/msg18654.html -Matthias On Wed, Oct 6, 2021 at 9:50 PM Matthias Sohn wrote: The JGit/EGit contribution to M1 will be late, I need a bit more time to finish the build. -Matthias ___ 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 ___ 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, visithttps://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 -- *Laurent Goubet* Consultant +33 2 51 13 51 42 <https://www.obeo.fr/> 7 Boulevard Ampère - Carquefou - France *obeo.fr* <https://www.obeo.fr/> | *twitter* <https://twitter.com/obeo_corp> | *linkedin* <https://www.linkedin.com/company/obeo> <>___ 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
Re: [cross-project-issues-dev] JGit/EGit contribution to M1 will be late
Hello, I am currently looking into how we can relax the dependency from the EMF Compare side and will be fixing this asap. Laurent Goubet Obeo On 07/10/2021 08:57, Ed Merks wrote: Hi, To prevent such problems in the future, I strongly suggest that EGit/JGit should be at +2 or better yet at +1 but definitely not +3. This will also help with the scenario of making contributions so late on the final day. Note that EGit/JGit has very few things on which it depends but quite a few things depend on it: In retrospect, it also seems kind of pointless to put upper bounds on the EGit/JGit dependencies. E.g., CDT isn't broken because it only has no upper limit... EMF compare has mostly removed the upper limits as well, at least from the bundles... I've made the necessary changes in Oomph, including changing Oomph's build to use https://download.eclipse.org/egit/updates-stable-nightly such that the builds will fail earlier the next time APIs actually break: https://bugs.eclipse.org/bugs/show_bug.cgi?id=576491 I've re-enabled Oomph's SimRel contribution. Please respin the SimRel repo to include the contribution and please revert the removal changes from EPP packages and respin those as well. Sorry for the inconvenience. Regards, Ed On 06.10.2021 23:57, Jonah Graham wrote: Thanks Mathias. (cc epp-dev) Note that if these projects don't contribute new versions in the next couple of hours I'll disable those features in EPP. I'm not too concerned about emf being disabled for M1, not sure effect of oomph though. Does that mean no installer for M1? Hopefully someone will weigh in on that. Thanks, Jonah On Wed., Oct. 6, 2021, 17:14 Matthias Sohn, wrote: I had to disable the following features to contribute jgit/egit 6.0.0.202110060947-m1. The build is running now. - org.eclipse.emf.compare.egit requires org.eclipse.jgit [4.9.0,6.0.0) which is not available anymore since we bumped jgitand egit to 6.0.0 for 2021-12. - org.eclipse.oomph.setup.sdk requires jgit/egit [5.12.0,5.13.0) On Wed, Oct 6, 2021 at 10:56 PM Matthias Sohn wrote: I disabled the feature org.eclipse.emf.compare.egit.feature.group to workaround this issue and hit the next problem in oomph requiring jgit/egit [5.12.0,5.13.0) which again isn't compatible with 6.0.0.202110060947-m1 which I am trying to contribute. 22:51:10 [0]Missing requirement: Git integration for Eclipse - Core 5.12.0.202106070339-r (org.eclipse.egit.core 5.12.0.202106070339-r) requires 'java.package; org.eclipse.jgit.annotations [5.12.0,5.13.0)' but it could not be found 22:51:10 22:51:10 JavaPackage(org.eclipse.jgit.annotations [5.12.0,5.13.0)) is required by: 22:51:10 ValidationSet(main) 22:51:10 Contribution(Oomph) 22:51:10 MappedRepository(https://download.eclipse.org/oomph/drops/milestone/S20211006-051210-1.23.0-M1) 22:51:10 Feature(org.eclipse.oomph.setup.sdk.feature.group) 22:51:10 InstallableUnit(org.eclipse.oomph.setup.git.feature.group 1.20.0.v20210924-1427) 22:51:10 InstallableUnit(org.eclipse.oomph.setup.git 1.20.0.v20210924-1427) 22:51:10 InstallableUnit(org.eclipse.egit.core 5.12.0.202106070339-r) On Wed, Oct 6, 2021 at 10:47 PM Jonah Graham wrote: Hi Matthias, IMHO you should disable emf compare with an announcement to this list that you did so. Hopefully that isn't a can of worms - the worms being if EMF Compare has dependencies. Jonah ~~~ Jonah Graham Kichwa Coders www.kichwacoders.com <http://www.kichwacoders.com> On Wed, 6 Oct 2021 at 16:37, Matthias Sohn wrote: I pushed our contribution [1] though the simrel validation build fails [2] with the error 22:27:06 [0]Missing requirement: EMF Compare EGit Support 1.2.4.202107200824 (org.eclipse.emf.compare.egit 1.2.4.202107200824) requires 'osgi.bundle; org.eclipse.jgit [4.9.0,6.0.0)' but it could not be found 22:27:06 22:27:06 Bundle(org.eclipse.jgit [4.9.0,6.0.0)) is required by: 22:27:06 ValidationSet(main) 22:27:06 Contribution(EMF Compare) 22:27:06 MappedRepository(https://download.eclipse.org/modeling/emf/compare/updates/milestones/3.3/S202107200824) 22:27:06 Feature(org.eclipse.emf.compare.egit.feature.group) 22:27:06 InstallableUnit(org.eclipse.emf.compare.egit 1.2.4.202107200824) because org.eclipse.emf.compare.egit re
[cross-project-issues-dev] download.eclipse.org unavailable
Hello, All builds we started this morning (5 hours ago CEST) have failed with issues trying to reach download.eclipse.org in one way or another, two examples of which are: - |Caused by: java.io.FileNotFoundException: https://download.eclipse.org/releases/2019-09/compositeContent.jar| -|||java.io.FileNotFoundException: Neither https://download.eclipse.org/tools/orbit/downloads/drops/R20190602212107/repository/compositeContent.jar nor https://download.eclipse.org/tools/orbit/downloads/drops/R20190602212107/repository/compositeContent.xml| When we tried to access these repositories through a browser, we initially got a 403 error. |https://download.eclipse.org/releases/2019-09| now seems to partially load (all icons are broken) but |https://download.eclipse.org/tools/orbit/downloads/drops/R20190602212107/repository |still gives us a 403. Could we get any status update on the issue and upcoming fix? Regards, -- *Laurent Goubet* Consultant +33 2 51 13 51 42 <https://www.obeo.fr/> 7 Boulevard Ampère - Carquefou - France *obeo.fr* <https://www.obeo.fr/> | *twitter* <https://twitter.com/obeo_corp> | *linkedin* <https://www.linkedin.com/company/obeo> <>___ 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
Re: [cross-project-issues-dev] Bugzilla down
Just to let you know, all services are working from my side now. https://www.eclipse.org/ https://eclipsecon.org bugzilla, gerrit, git as well... Laurent On 22/07/2019 15:29, Ivan Furnadjiev wrote: Just load it and you will see :) "Unable to connect to the database server at this time (eclipse)." Best regards, Ivan On 7/22/2019 16:25, Denis Roy wrote: Not according to https://downforeveryoneorjustme.com/eclipse.org On 2019-07-22 9:24 a.m., Ivan Furnadjiev wrote: https://www.eclipse.org/ is also down. Ivan On 7/22/2019 16:23, Denis Roy wrote: I wasn't aware. I just checked, and it's working now. Denis On 2019-07-22 9:13 a.m., Torkild U. Resheim wrote: https://eclipsecon.org is still down though Torkild 22. jul. 2019 kl. 12:51 skrev Denis Roy: Our primary database server encountered a kernel bug and crashed. We've failed over to a secondary db and will look into the bug before resyncing and restoring the primary. Apologies for the service interruption. Everything should be working as expected at this time. Denis On 2019-07-22 5:41 a.m., Laurent Goubet wrote: Hi, We cannot connect to the bugzilla athttps://bugs.eclipse.org/bugs/ (long waiting time ultimately leading to 404), trying to accesshttps://www.eclipse.org/ ends up in error 502, and we're getting errors from builds looking like some of the connections to download.eclipse.org get dropped as well. Anyone else encountering this issue? Regards, -- Laurent Goubet CONSULTANT +33 2 51 13 51 42 7 Boulevard Ampère - Carquefou - France obeo.fr | twitter | linkedin ___ 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 -- Denis Roy Director, IT Services | Eclipse Foundation, Inc. Eclipse Foundation: The Platform for Open Innovation and Collaboration Twitter: @droy_eclipse ___ 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 ___ 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 ___ 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 -- *Laurent Goubet* Consultant +33 2 51 13 51 42 <https://www.obeo.fr/> 7 Boulevard Ampère - Carquefou - France *obeo.fr* <https://www.obeo.fr/> | *twitter* <https://twitter.com/obeo_corp> | *linkedin* <https://www.linkedin.com/company/obeo> <>___ 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] Bugzilla down
Hi, We cannot connect to the bugzilla at https://bugs.eclipse.org/bugs/ (long waiting time ultimately leading to 404), trying to access https://www.eclipse.org/ ends up in error 502, and we're getting errors from builds looking like some of the connections to download.eclipse.org get dropped as well. Anyone else encountering this issue? Regards, -- *Laurent Goubet* Consultant +33 2 51 13 51 42 <https://www.obeo.fr/> 7 Boulevard Ampère - Carquefou - France *obeo.fr* <https://www.obeo.fr/> | *twitter* <https://twitter.com/obeo_corp> | *linkedin* <https://www.linkedin.com/company/obeo> <>___ 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
Re: [cross-project-issues-dev] Contributing JGit/EGit 5.1 M3 fails due to constraint by EMF compare
This version constraint had already been relaxed but the EMF Compare build hadn't been pushed to the simrel. This should now be fixed. On 29/08/2018 11:11, Matthias Sohn wrote: I pushed an update for JGit/EGit to 5.1.0.201808281540-m3for 2018-09 M3 [1]. Validation of this change [2] fails since EMF Compare has a constraint for jgit [4.9.0,5.1.0): *04:59:47* Bundle(org.eclipse.jgit [4.9.0,5.1.0)) is required by: *04:59:47*ValidationSet(main) *04:59:47* Contribution(EMF COMPARE) *04:59:47*MappedRepository(file:/home/data/httpd/download.eclipse.org/modeling/emf/compare/updates/milestones/3.3/S201805161152/ <http://download.eclipse.org/modeling/emf/compare/updates/milestones/3.3/S201805161152/>) *04:59:47* Feature(org.eclipse.emf.compare.egit.feature.group) *04:59:47*InstallableUnit(org.eclipse.emf.compare.egit 1.2.3.201805161152) EMF Compare: Can you please relax this constraint ? [1] https://git.eclipse.org/r/#/c/128264/ [2] https://ci.eclipse.org/simrel/job/simrel.photon.runaggregator.VALIDATE.gerrit/698/console -Matthias ___ 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://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev -- *Laurent Goubet* Consultant +33 2 51 13 51 42 <https://www.obeo.fr/> 7 Boulevard Ampère - Carquefou - France *obeo.fr* <https://www.obeo.fr/> | *twitter* <https://twitter.com/obeo_corp> | *linkedin* <https://www.linkedin.com/company/obeo> <>___ 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://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] Acceleo and EMF Compare participation in 2018-09
Hello, EMF Compare and Acceleo will both be part of the 2018-09 simrel, at offset +2. Versions will be the same as Photon: Acceleo 3.7.3 - https://projects.eclipse.org/projects/modeling.acceleo/releases/3.7.3 EMF Compare 3.3.3 - https://projects.eclipse.org/projects/modeling.emfcompare/releases/3.3.3 Regards, -- *Laurent Goubet* Consultant +33 2 51 13 51 42 <https://www.obeo.fr/> 7 Boulevard Ampère - Carquefou - France *obeo.fr* <https://www.obeo.fr/> | *twitter* <https://twitter.com/obeo_corp> | *linkedin* <https://www.linkedin.com/company/obeo> <>___ 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://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] Acceleo and EMF Compare will be participating in Photon
Hi, Acceleo and EMF Compare will be participating in Photon at offset +2: https://projects.eclipse.org/projects/modeling.acceleo/releases/3.8.0 https://projects.eclipse.org/projects/modeling.emfcompare/releases/4.0.0 -- *Laurent Goubet* Consultant +33 2 51 13 51 42 <https://www.obeo.fr/> 7 Boulevard Ampère - Carquefou - France *obeo.fr* <https://www.obeo.fr/> | *twitter* <https://twitter.com/obeo_corp> | *linkedin* <https://www.linkedin.com/company/obeo> <>___ 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://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] Part of the websites down?
projects [1], hudson [2] and wiki [3] are all failing saying that "Oops, something went wrong and we're completely broken down." Anything currently ongoing on these services? [1] http://projects.eclipse.org/ [2] https://hudson.eclipse.org/ [3] https://wiki.eclipse.org/ -- *Laurent Goubet* Consultant +33 2 51 13 51 42 <https://www.obeo.fr/> 7 Boulevard Ampère - Carquefou - France *obeo.fr* <https://www.obeo.fr/> | *twitter* <https://twitter.com/obeo_corp> | *linkedin* <https://www.linkedin.com/company/obeo> <>___ 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://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Papyrus contribution to Oxygen M3
When I contributed our M3 to the build it didn't fail so I wasn't expecting to wake up to this. I guess we're too late now to fix this for M3 but we'll try to update our dependencies asap and contribute a nightly to the aggregator so that papyrus isn't blocked by this when they try and update next. Laurent Goubet Obeo On 02/11/2016 20:50, Quentin Le Menez wrote: Hi Christian, I feared that it was the case but I kept a secret hope that it was something I could correct on my end. I am not a fan of rewinding versions so I will keep an eye open and see if I it gets picked up. Thanks for the help, Quentin On 2 November 2016 at 19:48, Christian Damus <give.a.da...@gmail.com <mailto:give.a.da...@gmail.com>> wrote: Hi, Quentin, It would seem that the EMF Compare project's UML2 Papyrus Comparison feature was built on an older Papyrus Oxygen build, from before the org.eclipse.papyrus.uml.tools bundle version was changed to 3.0 (I suppose there was some API-breaking change requiring the 3.0 version; I don't know). What is needed to resolve this is that the EMF Compare team update their bundle dependency to encompass the 3.0 version of org.eclipse.papyrus.uml.tools, testing for compatibility and possible breakage due to API changes, then push that new build to the Simultaneous Release. But, they would presumably want to do that only after you have contributed Papyrus M3, which I think means that they would have to disable their contribution (probably only this Papyrus integration feature) in the mean-time. So, in short, I think you’re stuck until you get help from the EMF Compare team, probably to temporarily disable their contribution of this Papyrus integration feature. Or else, if the version bump to 3.0 in org.eclipse.papyrus.uml.tools was not warranted (I’m not suggesting that it wasn’t), you could revert that back to whatever 2.x it was before. Probably other Papyrus bundles would have to update their dependency ranges, too, in that case. HTH, Christian On 2 November, 2016 at 13:05:39, LE MENEZ Quentin (quentin.leme...@cea.fr <mailto:quentin.leme...@cea.fr>) wrote: Hi Everyone, I tried to contribute our M3 build to the aggregator but it tells me that: EMF Compare UML2 Papyrus Comparison Support 1.0.0.201610250603 (org.eclipse.emf.compare.uml2.papyrus 1.0.0.201610250603) requires 'bundle org.eclipse.papyrus.uml.tools [1.0.2,3.0.0)' but it could not be found Strangely enough the oep.uml.tools is contributed at the 3.0.0 version number… (http://download.eclipse.org/modeling/mdt/papyrus/updates/milestones/3.0/M3/main/plugins/?d <http://download.eclipse.org/modeling/mdt/papyrus/updates/milestones/3.0/M3/main/plugins/?d>) Can someone tell me where I might have fumbled? Or what I might have missed? Thanks, Quentin ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org <mailto:cross-project-issues-dev@eclipse.org> To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev> ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org <mailto:cross-project-issues-dev@eclipse.org> To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev <https://dev.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://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev -- *Laurent Goubet* Consultant +33 2 51 13 51 42 <https://www.obeo.fr/> 7 Boulevard Ampère - Carquefou - France *obeo.fr* <https://www.obeo.fr/> | *twitter* <https://twitter.com/obeo_corp> | *linkedin* <https://www.linkedin.com/company/obeo> <>___ 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://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] Acceleo and EMF Compare participation in Oxygen
Acceleo and EMF Compare will both be participating in the Oxygen release train. The offset for both projects is +2. There is not much to be said as far as release plans are concerned yet, they will be amended in the near future with more information : Acceleo participates as the 3.6.5 release : https://projects.eclipse.org/projects/modeling.acceleo/releases/3.6.5 EMF Compare participates as the 3.3.0 release : https://projects.eclipse.org/projects/modeling.emfcompare/releases/3.3.0 Laurent Goubet Obeo -- *Laurent Goubet* Consultant +33 2 51 13 51 42 <https://www.obeo.fr/> 7 Boulevard Ampère - Carquefou - France *obeo.fr* <https://www.obeo.fr/> | *twitter* <https://twitter.com/obeo_corp> | *linkedin* <https://www.linkedin.com/company/obeo> <>___ 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://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] A funny thing happened on the way to Mars.2 -- in Orbit
Hi, This seems strangely reminiscent of https://bugs.eclipse.org/bugs/show_bug.cgi?id=458925 . Though it was the reverse, the jar file was good but the pack200 was not. That time was affecting orbit too. We might want to have a script running to check the signatures over there with each build? Laurent Goubet Obeo On 16/02/2016 16:48, Andreas Sewe wrote: Hi, David M Williams wrote: But since there is a "bad" one out there (in Orbit, at least) with the same version, I was suggesting to verify if it was in your project repositories to make sure you had the good one. If it is the good one, you get "jar verified" as above. If it is "the bad one" it will be pretty obvious: $ jarsigner -verify org.apache.httpcomponents.httpclient_4.3.6.v201411290715.jar jarsigner: java.lang.SecurityException: SHA1 digest error for org/apache/http/client/cache/HttpCacheEntry.class FWIW, I just found out that only the plain JAR in Orbit is "bad"; the JAR.pack.gz is not, i.e., it unpack200s to a JAR that verifies just fine [1]. If your build prefers pack200ed JARs over plain JARs, you should get a "good" JAR from Orbit, but of course it's better to double-check what you are distributing exactly. Best wishes, Andreas [1] <https://bugs.eclipse.org/bugs/show_bug.cgi?id=487833#c12> -- *Laurent Goubet* Consultant +33 2 51 13 51 42 <http://www.obeo.fr/> 7 Boulevard Ampère - Carquefou - France *obeo.fr* <http://www.obeo.fr/> | *twitter* <https://twitter.com/obeo_corp> | *linkedin* <https://www.linkedin.com/company/obeo> <>___ 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://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Acceleo and EMF Compare participation in Neon
Seems like even those who had already stated their intent to participate are resending this... so here is ours :) On 17/08/2015 14:31, Laurent Goubet wrote: Acceleo and EMF Compare will both be participating in the Neon release train. The offset for both projects is +2. There is not much to be said as far as release plans are concerned yet, they will be amended in the near future with more information : Acceleo participates as the 3.7.0 release : https://projects.eclipse.org/projects/modeling.acceleo/releases/3.7.0 EMF Compare participates as the 3.2.0 release : https://projects.eclipse.org/projects/modeling.emfcompare/releases/3.2.0 Laurent Goubet Obeo <>___ 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://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] error while trying to push changes in *.b3aggrcon
I also have trouble pushing my contributions to Neon M1 (master branch of the simrel repo), but Mine are when I try to push through gerrit. Following is an excerpt of my command line, as you can see I even tried on a clean clone of the simrel. Any help appreciated! lgoubet@PCLGOUBET /d/developpement/git $ git clone ssh://lgou...@git.eclipse.org:29418/simrel/org.eclipse.simrel.build testSimrel Cloning into 'testSimrel'... Enter passphrase for key '/c/Users/lgoubet/.ssh/id_rsa': remote: Counting objects: 177, done remote: Finding sources: 100% (77/77) Receiving objects: 97% (9226/9511), 1.88 MiB | 2remote: Total 9511 (delta 3), reused 9498 (del44.00 Receiving objects: 100% (9511/9511), 1.94 MiB | 252.00 KiB/s, done. ta 3) Resolving deltas: 100% (5951/5951), done. Checking connectivity... done lgoubet@PCLGOUBET /d/developpement/git $ cd testSimrel lgoubet@PCLGOUBET /d/developpement/git/testSimrel (master) $ git add . lgoubet@PCLGOUBET /d/developpement/git/testSimrel (master) $ git commit -m 'Acceleo and EMF Compare contributions to Neon M1' [master e0e09bf] Acceleo and EMF Compare contributions to Neon M1 2 files changed, 12 insertions(+), 12 deletions(-) lgoubet@PCLGOUBET /d/developpement/git/testSimrel (master) $ git push origin HEAD:refs/for/master Enter passphrase for key '/c/Users/lgoubet/.ssh/id_rsa': To ssh://lgou...@git.eclipse.org:29418/simrel/org.eclipse.simrel.build ! [rejected]HEAD - refs/for/master (non-fast-forward) error: failed to push some refs to 'ssh://lgou...@git.eclipse.org:29418/simrel/org.eclipse.simrel.bu ild' hint: Updates were rejected because a pushed branch tip is behind its remote hint: counterpart. Check out this branch and integrate the remote changes hint: (e.g. 'git pull ...') before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details. On 18/08/2015 12:13, Alexander Gurov wrote: Hi all! Is there anyone who knows what is the cause and what to do when such problem arises? ssh://agu...@git.eclipse.org/gitroot/simrel/org.eclipse.simrel.build.git: error occurred during unpacking on the remote end: unpack-objects abnormal exit Thank you in advance for your help! P.S. Pull works just fine. attachment: laurent_goubet.vcf___ 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://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] Acceleo and EMF Compare participation in Neon
Acceleo and EMF Compare will both be participating in the Neon release train. The offset for both projects is +2. There is not much to be said as far as release plans are concerned yet, they will be amended in the near future with more information : Acceleo participates as the 3.7.0 release : https://projects.eclipse.org/projects/modeling.acceleo/releases/3.7.0 EMF Compare participates as the 3.2.0 release : https://projects.eclipse.org/projects/modeling.emfcompare/releases/3.2.0 Laurent Goubet Obeo attachment: laurent_goubet.vcf___ 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://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] p2 and optional not too greedy dependencies
Thanks for the suggestion Carsten, this would be possible, but only through the use of very quirky workarounds. Namely, this optional plugin depends on egit for proper compilation and provides adapter factories (org.eclipse.core.runtime.adapters) that directly depend on EGit APIs. If I were to make that dependency optional, I'd need to make the adapter factory completely independent from egit (there mustn't be any org.eclipse.egit.* imports in that class, lest I deal with LinkageErrors of some sort (IIRC, this case is a NoClassDefFoundError)). I would thus need to create a proxy which sole responsibility would be to check for the presence of EGit in its classpath and either delegate to the actual adapter factory or return null (which in itself is also a weird behavior : I tell the platform that I can adapt SomeClass into SomeOther, yet I still return it a null). Not to mention I'd have to do that for every single egit-dependent class, and that these proxies would be called very often even if they can't do a thing. So yes, that would be a workaround... but I'd really rather be able to properly tell that my plugin _does_ depend on EGit, and tell p2 that it is an important dependency of another of my plugins that should be installed if all of its own requirements are met. On 25/11/2014 13:53, Carsten Reckord wrote: There might be a better, p2-based solution, but I think you can move the problem from installation time to runtime: 1. Make the dependency from o.e.e.c.egit to EGit optional and non-greedy, so o.e.e.c.egit doesn't pull in EGit 2. Always include o.e.e.c.egit in your install 3. At runtime, check in o.e.e.c.egit if EGit is present and o.e.e.c.egit can do its thing. Otherwise just ignore it. On 25.11.2014 10:47, Laurent Goubet wrote: Hi all, I'd like the help of p2 experts on a little issue... This question is for emf compare, in namespace org.eclipse.emf.compare. For the sake of brevity, I'll abbreviate this namespace as o.e.e.c everywhere. We have a number of plugins that get installed through a feature, among which is plugin 'o.e.e.c.ide'. We support comparisons for specific files (namely, files representing EMF models) either 'with each other' or 'with a repository version'. This repository can be git, svn, cvs... through either EGit, Subversive, Team's CVS support... Our base implementation is generic and only uses the eclipse Team APIs... but in order to support some of the repository providers' quirks, we are forced to depend on them to use their specific APIs. We have done so in isolated plugins, separated in support for xxx features that the user needs to install manually. For example, if the user uses EGit and wishes to compare his models through that provider, he needs to install the EGit support feature, which contains a single bundle, o.e.e.c.egit. But this feature is not so obvious and the generic support will behave strangely as long as it is not installed. What I'd like is for this bundle to be installed automatically with EMF Compare if EGit is already installed in the environment, but not force the installation of EGit if it is not. I am not sure whether optional dependencies can get me there. case 1 : o.e.e.c.ide has an optional, non-greedy dependency towards o.e.e.c.egit, which has a non-optional dependency on egit. case 2 : o.e.e.c.ide has an optional, greedy dependency towards o.e.e.c.egit, which has a non-optional dependency on egit. In case 1, I believe that o.e.e.c.egit will never be installed automatically, even if its dependency, EGit, is present in the environment? In case 2, however, my understanding is that o.e.e.c.egit will always be installed as long as EGit is accessible i.e. even if it is not installed, if it is reachable through the registered repository URIs, p2 will install it along? Note that currently, o.e.e.c.ide does not even depend on o.e.e.c.egit : the dependency is not needed, we just think that p2 will need it somehow if we want this automatic installation to happen one way or another. In other words, what we'd like is : if the user selects the feature EGit support for EMF Compare in p2, then EGit will be installed along. After all, we need it and in this particular case, the user has asked for it. But if he does not select that feature, we'd like the support bundle, o.e.e.c.egit, to still be installed if and only if EGit already is (or has been selected for install)... Greedy, but not too much :p. Is that possible through p2.inf or anything? Regards, Laurent Goubet Obeo ___ 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://dev.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
[cross-project-issues-dev] Acceleo and EMF Compare participation in Mars
Acceleo and EMF Compare will both be participating in the Mars release train. The offset for both projects is +2. There is not much to be said as far as release plans are concerned yet, they will be amended in the near future with more information : Acceleo participates as the 3.6.0 release : https://projects.eclipse.org/projects/modeling.acceleo/releases/3.6.0 EMF Compare participates with what is planned as its 3.1.0 release for now : https://projects.eclipse.org/projects/modeling.emfcompare/releases/3.1.0 Laurent Goubet Obeo attachment: laurent_goubet.vcf___ 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://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] EMF Compare M6 delayed
Hi, EMF Compare switches from 2.2 to 3.0 for its M6 version... though that breaks a few adopters. The build is ready but adding it to the aggregation would make it fail until CDO can update its own contribution to M6... and disabling CDO for the time being ripples through a few other projects. Eike is currently encountering a few issues on his build, so we're delaying the contribution of EMF Compare M6 until tomorrow in the hopes that these issues will be solved in the meantime. Laurent Goubet Obeo attachment: laurent_goubet.vcf___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Kepler SR2 staging (maintenance) repository is complete
Hi, Yes, the alert mails were all sent to the right people, and thankfully there hasn't been a fire here ;). The first mail from a failed aggregation was sent at 22:00 here, and since we haven't made any change to Acceleo or the aggregation since RC2, we weren't particularly monitoring it. This failure is an unforeseen consequence of https://bugs.eclipse.org/bugs/show_bug.cgi?id=426793 : we've moved out of the M2T sub-project ... and we had not though up about the consequences of the update site moving one level up too. All in all, Jeff's fix was the right one, thanks for taking care of it :). Laurent Goubet Obeo On 20/02/2014 07:21, David M Williams wrote: Thanks Jeff, for fixing the acceleo contribution. I do know that the automatic mail was being sent to that team Stephane Begaudeau stephane.begaud...@obeo.fr, Cedric Brun cedric.b...@obeo.fr, Laurent goubet laurent.gou...@obeo.fr, so can only assume that timezone differences, or a fire at their lab or offices, prevented them from responding and fixing. Only they can say if you made the right fix, but we'll assume so, unless they say otherwise. But for now, we will consider that final build staging repository is complete and ready to become Kepler SR2 after our quiet week buffer. As always, questions welcome. From: Jeff Johnston jjohn...@redhat.com To: Cross project issues cross-project-issues-dev@eclipse.org, Date: 02/19/2014 07:17 PM Subject: Re: [cross-project-issues-dev] Kepler SR2 aggregation is failing Sent by: cross-project-issues-dev-boun...@eclipse.org I have made a patch to the m2t-acceleo.b3aggrcon file. The repo mentioned below has disappeared, but I found file:///home/data/httpd/download.eclipse.org/acceleo/updates/milestones/3.4/S201401221203 Changing the repo to the location above, the aggregation validates. If someone comes along and feels that is the wrong solution, feel free to correct. -- Jeff J. - Original Message - From: Michael Golubev golu...@montages.com To: Cross project issues cross-project-issues-dev@eclipse.org Sent: Wednesday, February 19, 2014 6:20:45 PM Subject: [cross-project-issues-dev] Kepler SR2 aggregation is failing Hello, For last couple of hours Keppler SR2 aggregator is failing [1] trying to find one of the repos: [exec] Unable to load repository file:///home/data/httpd/download.eclipse.org/modeling/m2t/acceleo/updates/milestones/3.4/S201401221203 To my understanding the last commits before the first failing build are not related to Acceleo contribution, so it rather means that the referenced location itself had been accidentally removed. Anyway we are now approaching the deadline and there are at least 2 contributions (Mylyn and GMF-Tooling) that can't be built right now. Can someone please advice on how to proceed from here? [1] https://hudson.eclipse.org/hudson/view/Repository%20Aggregation/job/simrel.kepler.runaggregator/827/ Regards, Michael -- Michael Borlander Golubev Eclipse Committer (GMF, UML2Tools) at Montages Think Tank, Prague, Czech Republic 1165/1 Dvorecka, 14700, Prague-4 Podoli tek: +420 602 483 463 ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev attachment: laurent_goubet.vcf___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] [emf-dev] EMF Compare major version bump
Well... I've been convinced that changing our BREEs to Java 6 does not provide much value (and I wasn't allowed to change them to Java 7 :p), so I've reverted this change and the major version bumps it triggerred. The features of EMF Compare still change to 3.0 (the UI has been revamped enough to break the user's workflow... and suffered a few API breaks in the process), but the core plugins remain at their earlier major version. Feel free to ask here or on the forum if something is not clear and you can't find the versions you need. Laurent Goubet Obeo On 31/01/2014 11:20, Laurent Goubet wrote: Hi, Just a quick note to let you know that we have now bumped the major version segment of EMF Compare plugins and features. We plan on releasing 3.0 to Luna and this change will make its way into M6. There are very few API breakages in this version (see the very raw list on https://wiki.eclipse.org/EMF_Compare/API_Breaks. Note that there is a chace we simply haven't searched for replacement for some of the APIs. If you needed one of them, please let us know.). Still, we used this opportunity to change all of our BREEs to JDK 6. We do not use Java 6-specific features yet... but with the BREE out of the way we will not hesitate to do so in the future. Note that we still plan on opening new APIs (releasing some of our 'internal' classes into the open); other than that we should be done with the API breaks with these first nightlies of the M6 bits. For anyone wishing to check the compatibility, nightly builds are aggregated to http://download.eclipse.org/modeling/emf/compare/updates/nightly/3.x every day. We're also here to answer if we broke something unexpected. Laurent Goubet Obeo ___ emf-dev mailing list emf-...@eclipse.org https://dev.eclipse.org/mailman/listinfo/emf-dev attachment: laurent_goubet.vcf___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] Fwd: EMF Compare major version bump
Cross-posting from emf-dev in case someone depends on EMF Compare but is not subscribed to emf-dev. Original Message Subject:EMF Compare major version bump Date: Fri, 31 Jan 2014 11:20:57 +0100 From: Laurent Goubet laurent.gou...@obeo.fr Reply-To: laurent.gou...@obeo.fr To: emf-...@eclipse.org Hi, Just a quick note to let you know that we have now bumped the major version segment of EMF Compare plugins and features. We plan on releasing 3.0 to Luna and this change will make its way into M6. There are very few API breakages in this version (see the very raw list on https://wiki.eclipse.org/EMF_Compare/API_Breaks. Note that there is a chace we simply haven't searched for replacement for some of the APIs. If you needed one of them, please let us know.). Still, we used this opportunity to change all of our BREEs to JDK 6. We do not use Java 6-specific features yet... but with the BREE out of the way we will not hesitate to do so in the future. Note that we still plan on opening new APIs (releasing some of our 'internal' classes into the open); other than that we should be done with the API breaks with these first nightlies of the M6 bits. For anyone wishing to check the compatibility, nightly builds are aggregated to http://download.eclipse.org/modeling/emf/compare/updates/nightly/3.x every day. We're also here to answer if we broke something unexpected. Laurent Goubet Obeo attachment: laurent_goubet.vcf___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Change in the default java on build.eclipse.org
Ed : No, this was seen directly on build.eclipse.org, and our failing build (ecoretools) is not on an HIPP (as far as I know since I am not the main releng there). Dennis : M4 is the first time we see this failure, and we had never changed the default VM before. The default alternative (I'm talking about ubuntu's update-alternatives and the related set of utilities) for Java has changed somehow : JAVA_HOME was pointing to /usr/lib64/jvm/java which in turn is a symbolik link that references the alternative : /etc/alternatives/java_sdk. If we follow the whole set of symbolic links : $JAVA_HOME - /usr/lib64/jvm/java - /etc/alternatives/java_sdk - /usr/lib64/jvm/java-1.5.0-gcj - /usr/lib64/jvm/java-1.5.0-gcj-4.3-1.5.0.0 Since this is only failing now and we have not changed our ant files for years, I believe that the link to the java alternative was not pointing towards this gcj implementation for M3 and all releases before that. This can be worked around by just exporting our own JAVA_HOME instead of depending on the system's alternatives... but that also means making sure we never use the default in our build jobs and all other tasks that may use 'java' on the server. Laurent Goubet Obeo On 18/12/2013 08:43, Dennis Hübner wrote: Hi all, I had the same problem with build.eclipse.org http://build.eclipse.org last week. After trying around with combination of different processors and ant versions I gave up and switched to the /usr/lib64/jvm/java-1_6_0-ibm-1.6.0 We really need a better JVM default, for HIPPs and build.eclipse.org http://build.eclipse.org. Best regards, Dennis. Am 17.12.2013 um 22:38 schrieb Ed Willink e...@willink.me.uk mailto:e...@willink.me.uk: Hi Laurent A long time ago GNU Java was the almost unuseable default for vanilla Unix systems. Have you perhaps just switched to a new unconfigured platform such as a HIPP where the defaults are different? Regards Ed Willink On 17.12.2013 10:33, Laurent Goubet wrote: Hi, With Luna M4, we've begun to see strange failures in our ant promoters : javax.xml.transform.TransformerConfigurationException: no xsl:version attribute on literal result node This happened for us on the ant promoters for EMF Compare and Acceleo, and we also had a random failure on one of our builds : https://hudson.eclipse.org/hudson/job/emf-ecoretools-1.1.0/51/console It seems like this same failure also happened for EMF : https://bugs.eclipse.org/bugs/show_bug.cgi?id=420481 I ultimately tracked this down to our JAVA_HOME pointing to a 1.5.0 gcj version of the jre on build.eclipse.org http://build.eclipse.org : $JAVA_HOME/bin/java -version java version 1.5.0 gij (GNU libgcj) version 4.3.4 [gcc-4_3-branch revision 152973] Strangely enough, this isn't the version used in our PATH : java -version java version 1.6.0_27 Java(TM) SE Runtime Environment (build 1.6.0_27-b07) Java HotSpot(TM) 64-Bit Server VM (build 20.2-b06, mixed mode) after exporting a more appropriate version, ours promoters started to work anew : export JAVA_HOME=/shared/common/jdk-1.6.x86_64 export JAVA_ROOT=/shared/common/jdk-1.6.x86_64 export JAVA_BINDIR=/shared/common/jdk-1.6.x86_64/bin Likewise, changing our failing hudson job's configuration from (Default) to an explicit Java 6 R 30, the build worked like a charm. Was this change to java 1.5.0-gcj announced somewhere, or is that an unexpected change? Laurent Goubet Obeo ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org mailto:cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev Dennis Hübner Xtext Commiter / Build Engineer Mobile: +49 (0) 151 / 17 39 67 07 Telefon: +49 (0) 431 / 990 268 70 Fax: +49 (0) 431 / 990 268 72 itemis AG Niederlassung Kiel Am Germaniahafen 1 24143 Kiel http://www.itemis.de/ Rechtlicher Hinweis: Amtsgericht Dortmund, HRB 20621 Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens Trompeter, Sebastian Neus Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus attachment: laurent_goubet.vcf___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Requests for respins ... no
Unfortunate for us, but expected. As you point out, at least in our case, there was no show stopper with this issue. I was just hoping to hop on if there was a respin due to blocking bugs in other projects ;). Laurent Goubet Obeo On 14/11/2013 16:49, David M Williams wrote: Greg, Laurent, and Sergey, Sorry for the delay in responding, especially since I must say no. None of you mentioned blocking problems if we don't respin, and rather than delay M3, I'd prefer to think of it as you just having an early start for M4 :) We'll get you into 'staging' on Friday so you can do your own M3++ tests then if you'd like, but I'd rather not hold up EPP and others. M4 is a short cycle anyway, where we move to only a one week window between +0 and EPP so everyone (except +0) gets one week less time. Thanks for keeping us informed though ... sounds like M4 will be better. Thanks all, ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev attachment: laurent_goubet.vcf___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Luna M3 staging repository is complete
Hi, It's my turn this time to try and piggy back on a respin demand... I did meet the M3 deadline and built my two projects, EMF Compare and Acceleo, on +2 day; but I totally forgot to update the corresponding b3 files :s. EMF Compare only provides enhancements and bug fixes between M2 and M3, so this one shouldn't hurt. On the side of Acceleo on the other hand, we update the version range for M3 from 3.4 to 3.5 (3.4 was contributed with Kepler and until now, we had not had the need to branch out the maintenance stream). Any chance for these two to be included in a new aggregation build for Luna M3? I have pushed the commit updating the b3aggrcon files so that future builds see the update. Laurent Goubet Obeo On 14/11/2013 09:16, Sergey Boyko wrote: Hi David, I'm very sorry but QVTo has missed Luna M3 deadline. It's ready now. Is it possible to rebuild Luna M3 repository with it? Best Regards, Sergey. On Thu, Nov 14, 2013 at 2:26 AM, David M Williams david_willi...@us.ibm.com mailto:david_willi...@us.ibm.com wrote: Here it is ... 5:00 PM on Wednesday (Eastern time), no jobs running, no requests for extensions, so I'm declaring the Luna M3 repository complete. Please test http://download.eclipse.org/releases/staging/ If no blockers reported, I'll add M3 to the composite .../releases/luna on Friday morning. Here is the state of disabled projects ... I think this matches what the many previous notes/replies said ... Contribution disabled: (indicating no commitment yet to join Luna) amp.b3aggrcon pdt.b3aggrcon soa-sca.b3aggrcon Repository disabled: (indicating plans to join Luna, just not quite ready) riena.b3aggrcon sphinx.b3aggrcon Feature disabled: (indicating issue with just one feature) dltk.b3aggrcon (long standing disabled feature: Bug 415535) I'll re-enable the runaggregator job on Friday after EPP builds are ready. Thanks! ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org mailto:cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev attachment: laurent_goubet.vcf___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Reminder M2 closes tomorrow, Wednesday 10/2, approximately 5 PM
In case anyone was waiting for it as a dependency, EMF Compare 2.2.0M2 is now available. Sorry about the delay. On 01/10/2013 16:58, Laurent Goubet wrote: I have trouble signing EMF Compare (an issues with the https://repo.eclipse.org/content/repositories/cbi-releases/ server? see https://hudson.eclipse.org/hudson/view/Modeling/job/emf-compare-master/606/console , an SSLHandshakeException is thrown right from the start). EMF Compare 2.2.0M2 will thus be delayed for one day and will join the aggregation at +3. If anyone has any lead on what could be happening, I'd be grategul for any hint. Laurent Goubet Obeo On 01/10/2013 16:14, David M Williams wrote: Please join if you are able. The following projects still have disabled contributions elements: actf.b3aggrcon - org.eclipse.simrel.build amp.b3aggrcon - org.eclipse.simrel.build ecf.b3aggrcon - org.eclipse.simrel.build emft-eef.b3aggrcon - org.eclipse.simrel.build emft-egf.b3aggrcon - org.eclipse.simrel.build jwt.b3aggrcon - org.eclipse.simrel.build koneki.b3aggrcon - org.eclipse.simrel.build mft.b3aggrcon - org.eclipse.simrel.build pdt.b3aggrcon - org.eclipse.simrel.build scout-rap.b3aggrcon - org.eclipse.simrel.build soa-bpel.b3aggrcon - org.eclipse.simrel.build soa-sca.b3aggrcon - org.eclipse.simrel.build And the following have disabled repositories or features: dltk.b3aggrcon - org.eclipse.simrel.build egit.b3aggrcon - org.eclipse.simrel.build mat.b3aggrcon - org.eclipse.simrel.build riena.b3aggrcon - org.eclipse.simrel.build stardust.b3aggrcon - org.eclipse.simrel.build I've been seeing a lot of contributions in last day or two. Thanks! (to all you actively participating projects). ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev attachment: laurent_goubet.vcf___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] Acceleo and EMF Compare participation in Luna
Acceleo and EMF Compare will both be participating in the Luna release train. The offset for both projects is +2. There is not much to be said as far as release plans are concerned yet, they will be amended in the near future with more information : Acceleo participates as the 3.5.0 release : https://projects.eclipse.org/projects/modeling.m2t.acceleo/releases/3.5.0 EMF Compare participates with its 2.2.0 release, though that will most likely change to a 3.0.0 to accomodate for the current version discrepancy between the projects' plugins (some already being versionned as 3.0.*, others at 2.1.*) : https://projects.eclipse.org/projects/modeling.emfcompare/releases/2.2.0 Acceleo missed M1 because of the team's absence, so M2 will be the first milestone for that project. Laurent Goubet Obeo attachment: laurent_goubet.vcf___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Wrong push on Kepler SR2
Hi Dennis, Thanks for the confirmation, I didn't really know why there was an additional commit on my clone, but I think it was only due to an unexpected pull --merge from my side, it does not seem like anything broke/reverted because of it. I'll just curse the default pull strategy :p. Laurent Goubet Obeo On 04/09/2013 10:37, Dennis Hübner wrote: Hi Laurent, our changes are still there (emf,xtext). So there is nothing to revert I think. Regards, Dennis. Am 03.09.2013 um 17:00 schrieb Laurent Goubet: In fact ... I think the issue is just that I've used the default EGit's pull instead of a pull rebase, so probably nothing to revert? Laurent Goubet Obeo On 03/09/2013 16:53, Laurent Goubet wrote: Hi all, I just did something I don't really understand on the aggregation repository, and pushed a merging commit ( http://git.eclipse.org/c/simrel/org.eclipse.simrel.build.git/commit/?h=Kepler_maintenanceid=0caf9d67fc9d0d0bdcc18485fbb3f1181387d565 ) along with my real commit, as a result I think I broke a number of other projects (emf, xtext, koneki...). I will revert these changes and hope that the merge didn't break anything else. Sorry about that. Laurent Goubet Obeo ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev laurent_goubet.vcf___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org mailto:cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev Dennis Hübner Xtext Commiter / Build Engineer Mobile: +49 (0) 151 / 17 39 67 07 Telefon: +49 (0) 431 / 990 268 70 Fax: +49 (0) 431 / 990 268 72 itemis AG Niederlassung Kiel Am Germaniahafen 1 24143 Kiel http://www.itemis.de/ Rechtlicher Hinweis: Amtsgericht Dortmund, HRB 20621 Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens Trompeter, Sebastian Neus Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus attachment: laurent_goubet.vcf___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Status and Outlook for Luna M1
Hi Grégoire, The editor validated, so I hope the build will pass too. ATL and Acceleo have now been reenabled for Luna, though that will only be useful for M2 now. Laurent Goubet Obeo On 02/09/2013 16:34, Laurent Goubet wrote: Disabling all projects every year will always cause such issues : the Acceleo team was in holidays for most of August, which makes us miss M1. The same goes for ATL. Per change, we had one of the EMF Compare Team at hand to activate that one contribution (and even still, he had to tweak our build to manually remove features for which our dependencies are also marked as disabled). I think that leaving the contributions enabled would be better than forcing everyone into this situation : we have to load the aggregator, enable our contribution, check if it works... and come back at regular intervals to check for our dependencies' enablement. This is time consuming for those of us who depend on a few projects... and frustrating since we know that we are in turn blocking others. Not to mention that this always comes at a time where most of us are in holidays and just cannot react. I think this had already been discussed last year, and I do not know if leaving all projects enabled by default is better, at least it would not block anything. Grégoire, Acceleo will be enabled some time tomorrow (CEST), sorry for the wait. Laurent Goubet Obeo On 22/08/2013 18:11, Grégoire Dupé wrote: Hello I'm still waiting for Acceleo and ATL (may be more) to deliver MoDisco. It's quite late in Europe; I've to leave the office. I assume that MoDisco will not be included in Luna M1 :-( Regards, Grégoire - Original Message - From: David M Williams david_willi...@us.ibm.com To: cross-project-issues-dev@eclipse.org Sent: Jeudi 22 Août 2013 10:13:05 Subject: [cross-project-issues-dev] Status and Outlook for Luna M1 Ok, it's Thursday morning :) Only a few more have been enabled, but that includes DTP and BIRT, so that should help Luna (Kepler RC1 repo is already considered done). That allowed me to enabled the JPA portions of WTP (since depends on DataTools) which, I noticed, some others depended on, but I had to leave WTPs JPA Diagram Editor disabled, since it depends on Graphiti, which is not enabled yet. Which brings me to my main point. Scanning the list of 22 disabled contributions, I'd guess about half are leaf components, so if you don't get enabled, it'd hurt no one but your self ... and maybe community and adopters? But, I'd guess, the other half such as graphiti, gmf? a few emf ones? and DLTK are definitely building blocks that need to be enabled or else others downstream can not function or be enabled. If you are a consuming project and need some of those lower level ones enabled, I'd encourage a lot of project-to-project communication so they know how much you depend on them, and the effect they have by being late or incomplete, etc. So, I'm just asking everyone to be aware of your place in the eco system and plan accordingly. I suspect I'm just stating the obvious ... but not sure what else I can do to help. Thanks, = = = = = = = = = actf.b3aggrcon - org.eclipse.simrel.build amalgam.b3aggrcon - org.eclipse.simrel.build amp.b3aggrcon - org.eclipse.simrel.build dltk.b3aggrcon - org.eclipse.simrel.build ecf.b3aggrcon - org.eclipse.simrel.build emf-compare.b3aggrcon - org.eclipse.simrel.build emft-ecoretools.b3aggrcon - org.eclipse.simrel.build emft-eef.b3aggrcon - org.eclipse.simrel.build emft-egf.b3aggrcon - org.eclipse.simrel.build gmp-gmf-tooling.b3aggrcon - org.eclipse.simrel.build gmp-graphiti.b3aggrcon - org.eclipse.simrel.build jwt.b3aggrcon - org.eclipse.simrel.build koneki.b3aggrcon - org.eclipse.simrel.build m2m-atl.b3aggrcon - org.eclipse.simrel.build m2t-acceleo.b3aggrcon - org.eclipse.simrel.build mdt-modisco.b3aggrcon - org.eclipse.simrel.build mft.b3aggrcon - org.eclipse.simrel.build mylyn-docs-intent.b3aggrcon - org.eclipse.simrel.build pdt.b3aggrcon - org.eclipse.simrel.build soa-bpel.b3aggrcon - org.eclipse.simrel.build soa-sca.b3aggrcon - org.eclipse.simrel.build windowbuilder.b3aggrcon - org.eclipse.simrel.build ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev attachment: laurent_goubet.vcf___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] Wrong push on Kepler SR2
Hi all, I just did something I don't really understand on the aggregation repository, and pushed a merging commit ( http://git.eclipse.org/c/simrel/org.eclipse.simrel.build.git/commit/?h=Kepler_maintenanceid=0caf9d67fc9d0d0bdcc18485fbb3f1181387d565 ) along with my real commit, as a result I think I broke a number of other projects (emf, xtext, koneki...). I will revert these changes and hope that the merge didn't break anything else. Sorry about that. Laurent Goubet Obeo attachment: laurent_goubet.vcf___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Status and Outlook for Luna M1
Disabling all projects every year will always cause such issues : the Acceleo team was in holidays for most of August, which makes us miss M1. The same goes for ATL. Per change, we had one of the EMF Compare Team at hand to activate that one contribution (and even still, he had to tweak our build to manually remove features for which our dependencies are also marked as disabled). I think that leaving the contributions enabled would be better than forcing everyone into this situation : we have to load the aggregator, enable our contribution, check if it works... and come back at regular intervals to check for our dependencies' enablement. This is time consuming for those of us who depend on a few projects... and frustrating since we know that we are in turn blocking others. Not to mention that this always comes at a time where most of us are in holidays and just cannot react. I think this had already been discussed last year, and I do not know if leaving all projects enabled by default is better, at least it would not block anything. Grégoire, Acceleo will be enabled some time tomorrow (CEST), sorry for the wait. Laurent Goubet Obeo On 22/08/2013 18:11, Grégoire Dupé wrote: Hello I'm still waiting for Acceleo and ATL (may be more) to deliver MoDisco. It's quite late in Europe; I've to leave the office. I assume that MoDisco will not be included in Luna M1 :-( Regards, Grégoire - Original Message - From: David M Williams david_willi...@us.ibm.com To: cross-project-issues-dev@eclipse.org Sent: Jeudi 22 Août 2013 10:13:05 Subject: [cross-project-issues-dev] Status and Outlook for Luna M1 Ok, it's Thursday morning :) Only a few more have been enabled, but that includes DTP and BIRT, so that should help Luna (Kepler RC1 repo is already considered done). That allowed me to enabled the JPA portions of WTP (since depends on DataTools) which, I noticed, some others depended on, but I had to leave WTPs JPA Diagram Editor disabled, since it depends on Graphiti, which is not enabled yet. Which brings me to my main point. Scanning the list of 22 disabled contributions, I'd guess about half are leaf components, so if you don't get enabled, it'd hurt no one but your self ... and maybe community and adopters? But, I'd guess, the other half such as graphiti, gmf? a few emf ones? and DLTK are definitely building blocks that need to be enabled or else others downstream can not function or be enabled. If you are a consuming project and need some of those lower level ones enabled, I'd encourage a lot of project-to-project communication so they know how much you depend on them, and the effect they have by being late or incomplete, etc. So, I'm just asking everyone to be aware of your place in the eco system and plan accordingly. I suspect I'm just stating the obvious ... but not sure what else I can do to help. Thanks, = = = = = = = = = actf.b3aggrcon - org.eclipse.simrel.build amalgam.b3aggrcon - org.eclipse.simrel.build amp.b3aggrcon - org.eclipse.simrel.build dltk.b3aggrcon - org.eclipse.simrel.build ecf.b3aggrcon - org.eclipse.simrel.build emf-compare.b3aggrcon - org.eclipse.simrel.build emft-ecoretools.b3aggrcon - org.eclipse.simrel.build emft-eef.b3aggrcon - org.eclipse.simrel.build emft-egf.b3aggrcon - org.eclipse.simrel.build gmp-gmf-tooling.b3aggrcon - org.eclipse.simrel.build gmp-graphiti.b3aggrcon - org.eclipse.simrel.build jwt.b3aggrcon - org.eclipse.simrel.build koneki.b3aggrcon - org.eclipse.simrel.build m2m-atl.b3aggrcon - org.eclipse.simrel.build m2t-acceleo.b3aggrcon - org.eclipse.simrel.build mdt-modisco.b3aggrcon - org.eclipse.simrel.build mft.b3aggrcon - org.eclipse.simrel.build mylyn-docs-intent.b3aggrcon - org.eclipse.simrel.build pdt.b3aggrcon - org.eclipse.simrel.build soa-bpel.b3aggrcon - org.eclipse.simrel.build soa-sca.b3aggrcon - org.eclipse.simrel.build windowbuilder.b3aggrcon - org.eclipse.simrel.build ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev attachment: laurent_goubet.vcf___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] Permission issues on build.eclipse.org
Hi, We usually use a common script to manage composite repositories : /shared/modeling/tools/promotion/manage-composite.xml. I don't know when it started, but this script now fails with (apparently) permission issues on the server : cd /home/data/httpd/download.eclipse.org/modeling/emf/compare/updates/interim/2.1 ant -f /shared/modeling/tools/promotion/manage-composite.xml add -Dchild.repository=I201304240820 -Dcomposite.name=EMF Compare 2.1 interim [...] BUILD FAILED /shared/modeling/tools/promotion/manage-composite.xml:8: The following error occurred while executing this line: /shared/modeling/tools/promotion/manage-composite.xml:50: The following error occurred while executing this line: /shared/modeling/tools/promotion/manage-composite.xml:55: Java returned: 13 The log at /opt/public/common/buckminster-3.6/configuration/1366792579588.log tells us a little more : java.lang.IllegalStateException: The platform metadata area could not be written: /tmp/temporary-workspace-1157871083/.metadata. By default the platform writes its content under the current working directory when the platform is launched. Use the -data parameter to specify a different content area for the platform. Is anyone else using this script to manage his composite repositories? If yes, are you seeing this issue too? Laurent Goubet Obeo attachment: laurent_goubet.vcf___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Permission issues on build.eclipse.org
I have seen many strange things happen since this morning (CEST) with *.eclipse.org (wiki, forum, bugzilla, ...) with pages sometimes throwing an error and refusing to load, a refresh usually solves the issue. The latest I've seen is bugzilla throwing a Data error in the similar bugs box when filing a new bug. Might be the same/a related issue? Laurent Goubet Obeo On 24/04/2013 11:34, Eike Stepper wrote: Hi Laurent, I think the drive is full: https://bugs.eclipse.org/bugs/show_bug.cgi?id=406391 Cheers /Eike http://www.esc-net.de http://thegordian.blogspot.com http://twitter.com/eikestepper ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev attachment: laurent_goubet.vcf___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Is bugzilla out ?
Might be a location specific issue? The bugzilla does not respond at all from my side, started a little before 16h CET. Laurent Goubet Obeo On 01/03/2013 16:27, Ed Willink wrote: Hi Fine for me. Regards Ed Willink On 01/03/2013 15:06, Adolfo Sanchez-Barbudo Herrera wrote: Hi all, I'm wondering if somebody else is experiencing bugzilla unresponsiveness... It's not usual. Cheers, Adolfo. ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev - No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2899 / Virus Database: 2641/6138 - Release Date: 02/28/13 ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev attachment: laurent_goubet.vcf___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Is bugzilla out ?
Thanks Denis, it now works indeed :). On 01/03/2013 16:47, Denis Roy wrote: There was a brief pause in service while I installed some security updates on Bugzilla. I typically snapshot the database before doing changes so I can easily revert should things go wrong. Apologies -- Bugzilla is now stable. Denis On 03/01/2013 10:31 AM, Laurent Goubet wrote: Might be a location specific issue? The bugzilla does not respond at all from my side, started a little before 16h CET. Laurent Goubet Obeo ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev attachment: laurent_goubet.vcf___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Status and outlook for Final Juno SR2
Hi, EMF Compare (1.3.3RC4) and Acceleo (3.3.2RC4) were both a bit late : I could not build yesterday. I have now promoted both builds, they should be taken up by the next aggregation build. Sorry for the lack of updates, hopefully this shouldn't break anybody (builds that have been made against our RC3 should not need a respin as only bug fixes were included in these RC4). Laurent Goubet Obeo On 13/02/2013 00:52, Greg Watson wrote: PTP is rebuilding now. Should be finished by around 7:30pm. Thanks! On Feb 12, 2013, at 6:39 PM, David Dykstal david_dyks...@us.ibm.com mailto:david_dyks...@us.ibm.com wrote: David Williams -- The TM RC4 contribution has been updated to supply a fix for PTP. We now have RC4b. Is this all the notice you need? -- David Dykstal, Architect - Rational Developer for Power Systems From: David Dykstal/Rochester/IBM@IBMUS To: Cross project issues cross-project-issues-dev@eclipse.org mailto:cross-project-issues-dev@eclipse.org, Date: 02/12/2013 03:00 PM Subject: Re: [cross-project-issues-dev] Status and outlook for Final Juno SR2 Sent by: cross-project-issues-dev-boun...@eclipse.org mailto:cross-project-issues-dev-boun...@eclipse.org Where would we be without some excitement? We're have a fix and are attempting a rebuild if Hudson will cooperate. We'll then resubmit our RC4 contribution. -- David Dykstal, Architect - Rational Developer for Power Systems From: Greg Watson g.wat...@computer.org mailto:g.wat...@computer.org To: Cross project issues cross-project-issues-dev@eclipse.org mailto:cross-project-issues-dev@eclipse.org, Date: 02/12/2013 02:10 PM Subject: Re: [cross-project-issues-dev] Status and outlook for Final Juno SR2 Sent by: cross-project-issues-dev-boun...@eclipse.org mailto:cross-project-issues-dev-boun...@eclipse.org PTP may be late depending on a resolution of an RSE regression issue. Regards, Greg On Feb 12, 2013, at 2:50 PM, David M Williams _david_willi...@us.ibm.com_ mailto:david_willi...@us.ibm.com wrote: Its been a pretty quiet RC4 week! Just wanted to send a reminder that final contributions are due tomorrow, 2/13, 5 PM (with final EPP packages done by Friday). And then begins quiet week. While there is no specific document for Final Daze for maintenance releases, the release engineers among you should re-read _ __http://wiki.eclipse.org/Juno/Final_Daze_ to be reminded of the concepts (e.g. leave builds/repos invisible until the release date, 2/22). Thanks, ___ cross-project-issues-dev mailing list_ __cross-project-issues-dev@eclipse.org_ mailto:cross-project-issues-dev@eclipse.org_ __https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_ ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org mailto:cross-project-issues-dev@eclipse.org_ __https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_ ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org mailto:cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org mailto:cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev attachment: laurent_goubet.vcf___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Status and Outlook for Kepler M4, +2 day
Hi, The 4 missing about.html files for EMF Compare were due to the usual mistake of forgetting the corresponding build.properties entry. The fix is pushed and these 4 won't be an issue for M5. Three of the 5 plugins with no license : # org.eclipse.acceleo.source.feature.group # org.eclipse.emf.compare.ide.ui.source.feature.group # org.eclipse.emf.compare.source.feature.group are features generated through the use of tycho-source-feature. The two others look to be much the same. I was waiting on https://bugs.eclipse.org/bugs/show_bug.cgi?id=374349 to begin looking into this. Since this has been fixed, using tycho 0.17 should be enough to remove these issues by M5. Laurent Goubet Obeo On 18/12/2012 23:47, David M Williams wrote: Lots of activities today, going much better than yesterday. Appears nearly everyone is mostly in, some waiting for the BIRT fix. One day to go! amp.b3aggrcon - org.eclipse.simrel.build birt.b3aggrcon - org.eclipse.simrel.build dltk.b3aggrcon - org.eclipse.simrel.build (2 matches) egit.b3aggrcon - org.eclipse.simrel.build mat.b3aggrcon - org.eclipse.simrel.build soa-bpel.b3aggrcon - org.eclipse.simrel.build webtools.b3aggrcon - org.eclipse.simrel.build Thanks for everyone's attention and quick fixes when the aggregation does break. We don't have to be perfectly clean for M4, but for those 64 missing about.html http://build.eclipse.org/simrel/kepler/reporeports/reports/layoutCheck.txt or 8 incorrect or missing license files in features, http://build.eclipse.org/simrel/kepler/reporeports/reports/licenseConsistency.html be sure to set aside some time in January to fix these types of issues early, if you don't fix for M4, and not leave to the very end. Thanks, ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev attachment: laurent_goubet.vcf___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] Kepler simrel
Hi, I was searching for the simultaneous release reports (missing about file, unsigned bundles...) to check my M3 bits, but could not find the wiki page (I think there was one) pointing to the latest simrel reports for Kepler. There were once on http://build.eclipse.org/juno/simrel/ http://build.eclipse.org/indigo/simrel/, but I get an object not found! error when trying to access it (same if I replace juno by kepler in the url :). Are those still run for the milestones? As a side note, the post-M4 milestones do not seem to be filled on the planning council calendar (https://www.google.com/calendar/embed?src=gchs7nm4nvpm837469ddj9t...@group.calendar.google.comctz=America/New_Yorkgsessionid=OK). Could someone update it with the Kepler milestones? I believe the dates on http://wiki.eclipse.org/Kepler/Simultaneous_Release_Plan are accurate, but I find it way easier to use the calendar :). Thanks, Laurent Goubet Obeo attachment: laurent_goubet.vcf___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Kepler simrel
Thanks David, This will ease the hunt for missing legal files in some of my generated bundles :). As for the calendar, sorry for the reminder if that was already on your todo list. Laurent Goubet Obeo On 20/11/2012 16:42, David M Williams wrote: The URLs for the reports changed a little as we moved to Git, improved the build structure, and began Kepler: http://build.eclipse.org/simrel/kepler/reporeports/ http://build.eclipse.org/simrel/juno/reporeports/ For future reference, these are kept up to date in the description of the Hudson job that runs them, such as https://hudson.eclipse.org/hudson/view/Repository%20Aggregation/job/simrel.kepler.runReports/ has See _Repository Reports_ http://build.eclipse.org/simrel/kepler/reporeports/for information about the latest staging repository. And, yes, I have been meaning to finish up transposing the calendar so am sure I will soon with your reminder. Thanks, From: Laurent Goubet laurent.gou...@obeo.fr To: Cross project issues cross-project-issues-dev@eclipse.org, Date: 11/20/2012 05:24 AM Subject: [cross-project-issues-dev] Kepler simrel Sent by: cross-project-issues-dev-boun...@eclipse.org Hi, I was searching for the simultaneous release reports (missing about file, unsigned bundles...) to check my M3 bits, but could not find the wiki page (I think there was one) pointing to the latest simrel reports for Kepler. There were once on _http://build.eclipse.org/juno/simrel/_ http://build.eclipse.org/indigo/simrel/, but I get an object not found! error when trying to access it (same if I replace juno by kepler in the url :). Are those still run for the milestones? As a side note, the post-M4 milestones do not seem to be filled on the planning council calendar (_https://www.google.com/calendar/embed?src=gchs7nm4nvpm837469ddj9t...@group.calendar.google.comctz=America/New_Yorkgsessionid=OK_). Could someone update it with the Kepler milestones? I believe the dates on _http://wiki.eclipse.org/Kepler/Simultaneous_Release_Plan_are accurate, but I find it way easier to use the calendar :). Thanks, Laurent Goubet Obeo[attachment laurent_goubet.vcf deleted by David M Williams/Raleigh/IBM] ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev attachment: laurent_goubet.vcf___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Status and outlook for Kepler M3
The most recent builds I launched are failing because of granite.eclipse.org too (or so it seems : https://hudson.eclipse.org/hudson/view/Modeling/job/emf-compare-master/400/console ) : Caused by: java.net.UnknownHostException: granite.eclipse.org Should I refrain from trying to build atm? :p Laurent On 14/11/2012 21:21, Denis Roy wrote: Sorry Jeff. I've discontinued that redirect until it catches up. Denis On 11/14/2012 03:20 PM, Jeff Johnston wrote: Linux Tools has a backup M3 offering in place but I wanted to refresh today. I am experiencing problems using the b3 aggregator editor. It claims it can't find a number of repositories that have to be there, including the Linux Tools one used in the previous successful aggregation: http://download.eclipse.org/linuxtools/update-kepler-m3. I have verified the repos exist by logging into build.eclipse.org. I was able to do so maybe an hour ago, but now it is not working. Has something changed very recently? I keep getting redirected to granite.eclipse.org and the repos are said to not be there. I want to load http://download.eclipse.org/linuxtools/update-kepler-m3-b I could just make my change, but I would prefer to ensure it is loading. -- Jeff J. - Original Message - From: David M Williams david_willi...@us.ibm.com To: Cross project issues cross-project-issues-dev@eclipse.org Sent: Wednesday, November 14, 2012 2:53:29 PM Subject: [cross-project-issues-dev] Status and outlook for Kepler M3 We've been without a clean build for past day or so but we just got one, so I promoted it to staging. http://download.eclipse.org/releases/staging/ I hope that everyone can check/confirm and get any other contributions made by 5 PM, as today is +3 day of Kepler M3. Let us know if anyone needs an extra hour or two ... otherwise we'll assume done at 5 PM ( Looks like we are nearly complete with contributions being enabled with only three remaining: emf-query2.b3aggrcon - org.eclipse.simrel.build jwt.b3aggrcon - org.eclipse.simrel.build soa-sca.b3aggrcon - org.eclipse.simrel.build But still several others with some features or repositories disabled: amp.b3aggrcon - org.eclipse.simrel.build dltk.b3aggrcon - org.eclipse.simrel.build (2 matches) egit.b3aggrcon - org.eclipse.simrel.build emf-emf.b3aggrcon - org.eclipse.simrel.build soa-bpel.b3aggrcon - org.eclipse.simrel.build tcf.b3aggrcon - org.eclipse.simrel.build (2 matches) tm.b3aggrcon - org.eclipse.simrel.build webtools.b3aggrcon - org.eclipse.simrel.build ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev attachment: laurent_goubet.vcf___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Status and outlook for Kepler M3
Thanks Denis, it is working fine now (though I missed my 400th build, here I was hoping that one would finally be green :'(). Laurent On 15/11/2012 16:35, Denis Roy wrote: I've disabled the redirect from local servers. Sorry about that. Please try now. Denis On 11/15/2012 10:30 AM, Laurent Goubet wrote: The most recent builds I launched are failing because of granite.eclipse.org too (or so it seems : https://hudson.eclipse.org/hudson/view/Modeling/job/emf-compare-master/400/console ) : Caused by: java.net.UnknownHostException: granite.eclipse.org Should I refrain from trying to build atm? :p Laurent On 14/11/2012 21:21, Denis Roy wrote: Sorry Jeff. I've discontinued that redirect until it catches up. Denis On 11/14/2012 03:20 PM, Jeff Johnston wrote: Linux Tools has a backup M3 offering in place but I wanted to refresh today. I am experiencing problems using the b3 aggregator editor. It claims it can't find a number of repositories that have to be there, including the Linux Tools one used in the previous successful aggregation: http://download.eclipse.org/linuxtools/update-kepler-m3. I have verified the repos exist by logging into build.eclipse.org. I was able to do so maybe an hour ago, but now it is not working. Has something changed very recently? I keep getting redirected to granite.eclipse.org and the repos are said to not be there. I want to load http://download.eclipse.org/linuxtools/update-kepler-m3-b I could just make my change, but I would prefer to ensure it is loading. -- Jeff J. - Original Message - From: David M Williams david_willi...@us.ibm.com To: Cross project issues cross-project-issues-dev@eclipse.org Sent: Wednesday, November 14, 2012 2:53:29 PM Subject: [cross-project-issues-dev] Status and outlook for Kepler M3 We've been without a clean build for past day or so but we just got one, so I promoted it to staging. http://download.eclipse.org/releases/staging/ I hope that everyone can check/confirm and get any other contributions made by 5 PM, as today is +3 day of Kepler M3. Let us know if anyone needs an extra hour or two ... otherwise we'll assume done at 5 PM ( Looks like we are nearly complete with contributions being enabled with only three remaining: emf-query2.b3aggrcon - org.eclipse.simrel.build jwt.b3aggrcon - org.eclipse.simrel.build soa-sca.b3aggrcon - org.eclipse.simrel.build But still several others with some features or repositories disabled: amp.b3aggrcon - org.eclipse.simrel.build dltk.b3aggrcon - org.eclipse.simrel.build (2 matches) egit.b3aggrcon - org.eclipse.simrel.build emf-emf.b3aggrcon - org.eclipse.simrel.build soa-bpel.b3aggrcon - org.eclipse.simrel.build tcf.b3aggrcon - org.eclipse.simrel.build (2 matches) tm.b3aggrcon - org.eclipse.simrel.build webtools.b3aggrcon - org.eclipse.simrel.build ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev attachment: laurent_goubet.vcf___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
[cross-project-issues-dev] hudson, tycho - Compiling against java 1.5
Hi all,
One of our plugins cannot be compiled against java 1.6 and has to be
compiled with the javac of jdk 1.5. In short, one of the jdk classes has
changed the signature of one of its methods' generics between the two
versions (see version 1.5 [1] and version 1.6 [2]). AFAIK, the
incompatibility is only at source level and the compiled classes should
work with both the 1.5 and 1.6 runtimes. The problem, however, is how
can I force tycho to use the jdk 1.5 compiler when run from the Eclipse
hudson instance?
I read some documentation, most notably
http://www.eclipse.org/tycho/sitedocs/tycho-compiler-plugin/compile-mojo.html
that describes some potentially interesting options. source and
target are not enough in my case. Telling javac that my sources are in
1.5 is not enough. fork seems out of the question when using
tycho-compiler-plugin from version 0.14.1. My builds fail in
compileOutOfProcess is not supported which rules out all options that
require forking (compilerVersion, executable, ... and maybe others).
The useJDK option was promising... but for the life of me I could not
understand how to provide the accurate toolchains.xml to my builds.
Should it be located in the home/.m2 of the hudsonBuild user? A way
seems to exist since I found this option used in one of the eclipse
repositories. See
http://git.eclipse.org/c/cbi/platform-aggregator.git/tree/eclipse-parent/pom.xml?h=JunoSR1_RC1_R4
... and the line just above the use of this option :
|TODO provide CBI-specific wiki that explains how to setup BREE libraries and
toolchain.xml|
Yup, the wiki would have helped :).
The only remaining option I could find was to use the workaround
outlined by Bernd on the forum :
http://www.eclipse.org/forums/index.php/t/201042/ .
pluginManagement
plugins
plugin
groupIdorg.eclipse.tycho/groupId
artifactIdtycho-compiler-plugin/artifactId
version${tycho-version}/version
configuration
compilerIdjdt/compilerId
compilerArguments
bootclasspath/shared/common/jdk-1.5.0-22.x86_64/jre/lib/rt.jar/bootclasspath
/compilerArguments
/configuration
/plugin
/pluginManagement
But that seems like a very fragile work around. Not to mention that now,
my tests fail because of the tycho-surefire-plugin
(https://hudson.eclipse.org/hudson/view/Modeling/job/emf-compare-master/322/console)...
If anyone here has any experience with tying tycho/hudson builds to a
specific jdk, any workaround as to how we can provide a toolchains.xml
for our build, or simply some input as to whether this toolchains.xml
should be provided for all jobs that would like to use it (it seems to
me like using the BREE of our plugins should be the default way of
building our plugins instead of using the jdk 6...), I'd really
appreciate the help :).
Laurent
[1]
http://docs.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/ExecutorService.html#invokeAll%28java.util.Collection%29
[2]
http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/ExecutorService.html#invokeAll%28java.util.Collection%29
attachment: laurent_goubet.vcf___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] hudson, tycho - Compiling against java 1.5
Okay, forget this last mention about my tests failing because of the
surefire plugin... this was a mistake from my side. All other questions
remain though :).
Laurent
On 25/09/2012 13:05, Laurent Goubet wrote:
Hi all,
One of our plugins cannot be compiled against java 1.6 and has to be
compiled with the javac of jdk 1.5. In short, one of the jdk classes
has changed the signature of one of its methods' generics between the
two versions (see version 1.5 [1] and version 1.6 [2]). AFAIK, the
incompatibility is only at source level and the compiled classes
should work with both the 1.5 and 1.6 runtimes. The problem, however,
is how can I force tycho to use the jdk 1.5 compiler when run from
the Eclipse hudson instance?
I read some documentation, most notably
http://www.eclipse.org/tycho/sitedocs/tycho-compiler-plugin/compile-mojo.html
that describes some potentially interesting options. source and
target are not enough in my case. Telling javac that my sources are
in 1.5 is not enough. fork seems out of the question when using
tycho-compiler-plugin from version 0.14.1. My builds fail in
compileOutOfProcess is not supported which rules out all options
that require forking (compilerVersion, executable, ... and maybe others).
The useJDK option was promising... but for the life of me I could
not understand how to provide the accurate toolchains.xml to my
builds. Should it be located in the home/.m2 of the hudsonBuild
user? A way seems to exist since I found this option used in one of
the eclipse repositories. See
http://git.eclipse.org/c/cbi/platform-aggregator.git/tree/eclipse-parent/pom.xml?h=JunoSR1_RC1_R4
... and the line just above the use of this option :
|TODO provide CBI-specific wiki that explains how to setup BREE libraries and
toolchain.xml|
Yup, the wiki would have helped :).
The only remaining option I could find was to use the workaround
outlined by Bernd on the forum :
http://www.eclipse.org/forums/index.php/t/201042/ .
pluginManagement
plugins
plugin
groupIdorg.eclipse.tycho/groupId
artifactIdtycho-compiler-plugin/artifactId
version${tycho-version}/version
configuration
compilerIdjdt/compilerId
compilerArguments
bootclasspath/shared/common/jdk-1.5.0-22.x86_64/jre/lib/rt.jar/bootclasspath
/compilerArguments
/configuration
/plugin
/pluginManagement
But that seems like a very fragile work around. Not to mention that
now, my tests fail because of the tycho-surefire-plugin
(https://hudson.eclipse.org/hudson/view/Modeling/job/emf-compare-master/322/console)...
If anyone here has any experience with tying tycho/hudson builds to a
specific jdk, any workaround as to how we can provide a toolchains.xml
for our build, or simply some input as to whether this
toolchains.xml should be provided for all jobs that would like to
use it (it seems to me like using the BREE of our plugins should be
the default way of building our plugins instead of using the jdk
6...), I'd really appreciate the help :).
Laurent
[1]
http://docs.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/ExecutorService.html#invokeAll%28java.util.Collection%29
[2]
http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/ExecutorService.html#invokeAll%28java.util.Collection%29
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
attachment: laurent_goubet.vcf___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] More on greedy install attribute ...
Hi, Some bundles from Acceleo (org.eclipse.acceleo.*) appear in this list. For example : 1. org.eclipse.core.filesystem Number of IUs using optional, but greedy for this case: 2 1. org.eclipse.acceleo.common Acceleo is developped as an Eclipse plugin, yet it is also meant to be useable in a standalone environment. When installed in Eclipse, we depend on org.eclipse.core.* bundles to provide additional functionality and integration. However, none of these dependencies are mandatory when using it as a standalone generation tool. So yes, we are indeed greedy (but in fact, it should be quite difficult to _not_ have o.e.c.filesystem installed before us right? org.eclipse.core.runtime and org.eclipse.core.resources should probably be ignored too by this report), _and_ optional since the dependency is not really needed in other environments. I believe that these cases should be exceptions to the greedy report. How could we document/track these? Or is my understanding wrong here? Laurent Goubet Obeo On 29/05/2012 07:36, David M Williams wrote: I did add some blame tracking and data to the greediness reports. http://build.eclipse.org/juno/simrel/reporeports/reports/greedyReport.html I'm not 100% sure the report is 100% correct, but if it is, the top 10 list of projects not using new publisher (or, deliberately circumventing it) is pretty obvious. Some I'm surprised to see on this list, some not. Thanks to the scores of other projects (not on the list) who have moved to new publisher, and are trying to give users and adopters a better experience. (Some of the other reports are improving too ... thanks! but, not much time left!) org.eclipse.amp.* org.eclipse.emf.mwe2* org.eclipse.emf.mwe.* org.eclipse.emf.query2* org.eclipse.papyrus.uml* org.eclipse.xtend* org.eclipse.xtext* org.eclipse.tm.terminal.serial org.eclipse.persistence.* org.eclipse.jetty.osgi.* osgi.enterprise org.eclipse.birt.* org.eclipse.m2m.* org.eclipse.xsd.* org.eclipse.acceleo.* org.eclipse.mylyn.* org.eclipse.team.svn.ui org.eclipse.amalgam.discovery.ui org.eclipse.egit.doc org.eclipse.acceleo.* org.eclipse.graphiti.ui org.eclipse.epp.mpc.ui ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev attachment: laurent_goubet.vcf___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] 2 executors instead of 4 question ...
Just tested anew ... and the build failed with the same error it had in august : https://hudson.eclipse.org/hudson/view/Modeling/job/m2t-acceleo-master/124/console failed with the single message Required plug-in 'org.eclipse.jdt.junit4.runtime' could not be found. I might be missing something, but I really have no idea why this would work on slave1 and not on master. Are there configuration changes between the Eclipse used on the two nodes? I should mention that we have no explicit dependency towards this jdt.junit4 plugin. Laurent Goubet Obeo On 19/01/2012 09:11, Ed Willink wrote: Hi Laurent On 19/01/2012 08:04, Laurent Goubet wrote: I mentionned it as an aside, but this is aggravated by the fact we cannot build on master and are thus tied down to slave1. I'll need to try again now, but I am pretty sure I'll stumble once again on the bug Adolfo and I hit for our builds earlier this year (something with hudson unable to find jdt.junit4 ... see this old cross-project thread for reference : http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg06420.html). MDT/OCL builds now work on master. I'm afraid I don't know if Adolfo fixed something or the problem just went away. Regards Ed Willink ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev attachment: laurent_goubet.vcf___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] 2 executors instead of 4 question ...
Ed, I'll try and get in touch with Adolfo to see if he remembers doing anything on that matter. Laurent Goubet Obeo On 19/01/2012 09:11, Ed Willink wrote: Hi Laurent On 19/01/2012 08:04, Laurent Goubet wrote: I mentionned it as an aside, but this is aggravated by the fact we cannot build on master and are thus tied down to slave1. I'll need to try again now, but I am pretty sure I'll stumble once again on the bug Adolfo and I hit for our builds earlier this year (something with hudson unable to find jdt.junit4 ... see this old cross-project thread for reference : http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg06420.html). MDT/OCL builds now work on master. I'm afraid I don't know if Adolfo fixed something or the problem just went away. Regards Ed Willink ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev attachment: laurent_goubet.vcf___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
