https://bugs.eclipse.org/bugs/show_bug.cgi?id=577863

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, 
visithttps://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

Reply via email to