I've now updated and re-enabled the EMF Compare contribution to cope with the EGit breaks. Please take this into account as well for the respin.
> 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...
EGit broke its APIs twice in the last few releases. "no upper limit" wouldn't have broken the simrel, but the final repository itself would have either been broken (NoSuchMethodException from any user of EMF Compare) or there would have been two versions of EGit, depending on how the wiring would have gone.
What was Activator.getDefault().getRepositoryCache().lookupRepository(gitDir); Became RepositoryCache.getInstance().lookupRepository(gitDir); between 5.10 and 5.11 This once again changed to RepositoryCache.INSTANCE.lookupRepository(gitDir); between 5.13 and 6.0. Removing the upper limit is not an answer here. Laurent 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, JonahOn Wed., Oct. 6, 2021, 17:14 Matthias Sohn, <matthias.s...@gmail.com> 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 <matthias.s...@gmail.com> 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 <jo...@kichwacoders.com> 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 <matthias.s...@gmail.com> 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 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 <matthias.s...@gmail.com> 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>
<<attachment: laurent_goubet.vcf>>
_______________________________________________ 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
