(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. 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 >
_______________________________________________ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
