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 listplatform-...@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

Reply via email to