My RCP clients love the new Maven lib integration. Orbit used to be really really slow with updates. For example, Mockito releases on every commit, replicating this in Orbit would be a huge amount of work. And it feels not as a value add step as in the end the same library is provided.
On Fri, Dec 17, 2021 at 10:39 AM Aleksandar Kurtakov <akurt...@redhat.com> wrote: > > > > On Fri, Dec 17, 2021 at 11:27 AM Ed Merks <ed.me...@gmail.com> wrote: >> >> https://bugs.eclipse.org/bugs/show_bug.cgi?id=577863 > > > Thanks, that would be a priority after vacation. > >> >> >> On 17.12.2021 09:44, Mickael Istria 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 > > > > -- > 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 -- Eclipse Platform project co-lead CEO vogella GmbH Haindaalwisch 17a, 22395 Hamburg Amtsgericht Hamburg: HRB 127058 Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel USt-IdNr.: DE284122352 Fax (040) 5247 6322, Email: lars.vo...@vogella.com, Web: http://www.vogella.com _______________________________________________ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
