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.