On Fri, 17 Dec 2021 at 11:08, Aleksandar Kurtakov <akurt...@redhat.com> wrote:
> > > On Fri, Dec 17, 2021 at 5:03 PM Jonah Graham <jo...@kichwacoders.com> > wrote: > >> (there are two mailing lists in this chain - some emails are not in >> planning council archive) >> >> > The community with which I'm familiar tended to build consensus around >> decisions. >> >> I empathise with the Eclipse PMC, and as I pointed out in >> various Planning Council and IDE WG calls, Eclipse PMC are a TLP that can >> do what they want (within EDP, etc). As far as I can tell they have tried >> to build consensus, but we are 4 months into the process of trying to get >> consensus on this issue and we remain log jammed. >> >> As a reminder, the next step is "Wayne has volunteered to try and put >> together the document that is digestible by the IDE WG and reviewers." >> (from https://wiki.eclipse.org/Planning_Council/2021-12-01) >> >> If the 2022-03 release ships with Eclipse Platform 4.22, that would be >> surprising, but not the end of the world. However my understanding is that >> for Eclipse Platform 4.23 all bundles that are currently in SimRel will >> continue to be jarsigned anyway. If something has changed in that regard: >> >> > So from now on things like Jetty updates and other third party updates >> will go with PGP signing only from Eclipse TLP. >> > > My (personal) plan is to not do any dependency updates for 2022-03 of > platform content that gets in Simrel. If there are updates that can't be > updated (CVE, breakage with newer Java, etc.) - these go with PGP signing . > Thank you for that extra detail. > > > >> >> then maybe we have something to hurry us along. >> >> Thank you Eclipse PMC for lighting a suitable sized fire under our >> collective behinds. >> >> And finally another reminder "The steering committee is onboard with the >> general direction of this work. The work looks promising and no plan to >> change direction." (from 16 Nov IDE WG minutes >> https://www.eclipse.org/lists/eclipse-ide-wg/msg00114.html) >> >> Jonah >> >> ~~~ >> Jonah Graham >> Kichwa Coders >> www.kichwacoders.com >> >> >> On Fri, 17 Dec 2021 at 03:45, Mickael Istria <mist...@redhat.com> wrote: >> >>> >>> >>> On Fri, Dec 17, 2021 at 9:11 AM Ed Merks <ed.me...@gmail.com> wrote: >>> >>>> Here is what happens when the installer tries to install >>>> org.mockito.mockito-core into a Platform SDK IDE: >>>> >>>> java.lang.NullPointerException >>>> at >>>> org.eclipse.equinox.internal.p2.engine.phases.CertificateChecker.buildPGPTrustore(CertificateChecker.java:311) >>>> at >>>> org.eclipse.equinox.internal.p2.engine.phases.CertificateChecker$1.get(CertificateChecker.java:63) >>>> at >>>> org.eclipse.equinox.internal.p2.engine.phases.CertificateChecker$1.get(CertificateChecker.java:1) >>>> at >>>> org.eclipse.equinox.internal.p2.engine.phases.CertificateChecker.checkCertificates(CertificateChecker.java:126) >>>> at >>>> org.eclipse.equinox.internal.p2.engine.phases.CertificateChecker.start(CertificateChecker.java:83) >>>> at >>>> org.eclipse.equinox.internal.p2.engine.phases.CheckTrust.completePhase(CheckTrust.java:63) >>>> at >>>> org.eclipse.equinox.internal.p2.engine.Phase.postPerform(Phase.java:254) >>>> at >>>> org.eclipse.equinox.internal.p2.engine.Phase.perform(Phase.java:105) >>>> at >>>> org.eclipse.equinox.internal.p2.engine.PhaseSet.perform(PhaseSet.java:50) >>>> at >>>> org.eclipse.equinox.internal.p2.engine.Engine.perform(Engine.java:80) >>>> at >>>> org.eclipse.equinox.internal.p2.engine.Engine.perform(Engine.java:48) >>>> at >>>> org.eclipse.equinox.internal.provisional.p2.director.PlanExecutionHelper.executePlan(PlanExecutionHelper.java:46) >>>> at >>>> org.eclipse.oomph.p2.internal.core.ProfileTransactionImpl$3.commit(ProfileTransactionImpl.java:549) >>>> at >>>> org.eclipse.oomph.p2.internal.core.ProfileTransactionImpl.commit(ProfileTransactionImpl.java:345) >>>> at >>>> org.eclipse.oomph.setup.p2.impl.P2TaskImpl.perform(P2TaskImpl.java:905) >>>> at >>>> org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.doPerformNeededSetupTasks(SetupTaskPerformer.java:3851) >>>> at >>>> org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.performNeededSetupTasks(SetupTaskPerformer.java:3779) >>>> at >>>> org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.performTriggeredSetupTasks(SetupTaskPerformer.java:3760) >>>> at >>>> org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.perform(SetupTaskPerformer.java:3638) >>>> at >>>> org.eclipse.oomph.setup.ui.wizards.ProgressPage$9.run(ProgressPage.java:600) >>>> at >>>> org.eclipse.oomph.setup.ui.wizards.ProgressPage$11$1.run(ProgressPage.java:727) >>>> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63) >>>> Why? Because >>>> org.eclipse.equinox.internal.p2.engine.phases.CheckTrust.completePhase(IProgressMonitor, >>>> IProfile, Map<String, Object>) knows the profile, but the certificate >>>> checker doesn't know to check that profile but rather checks the self >>>> profile. I imagine the p2 director will have such problems too, or perhaps >>>> it will not fail but also might not actually check the correct profile... >>>> >>> >>> Such feedback is really welcome. Can you please open a dedicated bug for >>> this issue and add me as CC ? >>> >>> I wonder though if n projects have to duplicate the effort n times if >>>> that will be n times the work. >>>> >>> >>> The effort of consuming upstream artifacts from Maven is equivalent to >>> the effort of consuming artifacts from Orbit. So there is no extra effort >>> involved for consumers, they just change a version in their .target and >>> that's all. >>> "Downstream" projects can also directly consume bundles provided by >>> their "upstream" ones in a plain p2 way. For example, a project that need >>> mockito can just take Mockito from Platform instead of Orbit, without >>> playing with Maven dependencies. It's actually already a common and >>> efficient: may target files don't reference Orbit and pick the libs that's >>> provided by their "upstream". >>> >>> >>>> Also, might we end up with n versions of each such bundle? >>>> >>> >>> We already do have N versions of several libs, split across multiple >>> repositories (eg some older projects don't rebuild against latest Orbit and >>> still include older libs). p2 -during SimRel aggregation or installation on >>> user end- does take care of picking the best and tries to avoid multiple >>> versions when this can be avoided. >>> Consuming libs from Maven instead of Orbit doesn't really change the >>> problem/solution in the end. >>> >>> _______________________________________________ >>> platform-dev mailing list >>> platform-dev@eclipse.org >>> To unsubscribe from this list, visit >>> https://www.eclipse.org/mailman/listinfo/platform-dev >>> >> _______________________________________________ >> eclipse.org-planning-council mailing list >> eclipse.org-planning-coun...@eclipse.org >> To unsubscribe from this list, visit >> https://www.eclipse.org/mailman/listinfo/eclipse.org-planning-council >> > > > -- > Aleksandar Kurtakov > Red Hat Eclipse Team > _______________________________________________ > platform-dev mailing list > platform-dev@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/platform-dev >
_______________________________________________ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
