[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [platform-dev] Unsigned Content?
|
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
<akurtako@xxxxxxxxxx> wrote:
>
>
>
> On Fri, Dec 17, 2021 at 11:27 AM Ed Merks <ed.merks@xxxxxxxxx> 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.merks@xxxxxxxxx> 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@xxxxxxxxxxx
>> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
>>
>> _______________________________________________
>> platform-dev mailing list
>> platform-dev@xxxxxxxxxxx
>> 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@xxxxxxxxxxx
> 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.vogel@xxxxxxxxxxx, Web: http://www.vogella.com