Home » Eclipse Projects » Oomph » Modular target resolution
| Modular target resolution [message #1778814] |
Thu, 21 December 2017 17:57  |
 Ernesto Posse
Messages: 438
Registered: March 2011 |
Senior Member |
|
|
Hi. I have run into a rather strange behaviour involving the modular target resolution, and more precisely the requirements and dependencies calculation.
The scenario is this: in my p2 pool I have a plugin, let's call it A_1, from repo RA1 and which depends on another plugin B_1 (also in the pool) from repo RB1. I'm creating a setup model for a project which, in its git repo, has a fork of A with a new version, call it A_2, which depends on a new version of B, B_2 from a different repo RB2. My setup model defines a Neon and an Oxygen stream, with similar but slightly different Modular Targets. The only difference is that the Neon version includes B_1 and RB1, but the Oxygen stream doesn't include either, but includes B_2 and RB2 instead. None of the code in the git repo, the workspace, the requirements in the P2 Director task or the Modular Target for the Oxygen stream require B_1 at all, so I would expect no trouble running the setup model. When I run it specifying the Neon stream, it works. And yet, when I run it specifying the Oxygen stream I get a "Cannot complete request" when calculating the requirements and dependencies of the Modular Target task. The error complains that it cannot find the required B_1!
So it would appear as if the task calculating the dependencies is not looking at the dependencies of A_2 (in the git repo and workspace), but instead, it is looking at A_1's dependencies, even though A_1 is neither in the git repo, nor the workspace (nor the Oxygen TP).
In fact, after some debugging, I found that in the resolution method (org.eclipse.oomph.p2.internal.core.ProfileTransactionImpl.resolve(CommitContext, IProgressMonitor)) after line 422:
IQueryable<IInstallableUnit> metadata = provisioningContext.getMetadata(MonitorUtil.create(monitor, 5));
the metadata includes the old version of A, A_1, and not the one in the git repo and workspace (A_2). The metadata doesn't include the old version of B (B_1) but does include the new version! (*)
So a couple of questions:
1) Is this because the fork of A uses the same name?
2) Looking at Oomph's code, it seems like the dependency calculation is delegated to
org.eclipse.equinox.internal.p2.director.SimplePlanner
(in org.eclipse.oomph.p2.internal.core.ProfileTransactionImpl.resolve, calling planner.getProvisioningPlan). Is this indeed the class responsible for the dependency calculation?
3) If so, are the plugins already installed (in the p2 pool) used to calculate dependencies, but not the plugins in the workspace?
4) Is (*) expected behaviour?
Thanks
|
|
|
| Re: Modular target resolution [message #1778825 is a reply to message #1778814] |
Fri, 22 December 2017 07:31  |
Ed Merks
Messages: 33139
Registered: July 2009 |
Senior Member |
|
|
Certainly quite tricky situations can arise with unified workspace IUs and p2 repo IUs. If during resolution A_1is found, then it must be visible via a source locator (a workspace IU) or via a p2 repository location (a p2 repository IU). The bundle pool is a p2 artifact repository, but it is not a p2 metadata repository. In other words the bundle is used only to resolve artifacts, not during resolution to resolve metadata about those artifacts. So regardless of what is or isn't in the bundle pool, that will have no impact on the resolution process. And yes, the resolution process is purely using the p2 APIs, though seeded with metadata gathered from the workspace IUs so the behave as if they were actually in a p2 repository.
By default each Targlet will have "Include Binary Equivalents" set to true. The net effect of this is that for each workspace IU a.b.c, if there is a p2 repo IU a.b.c, the metadata for the workspace IU is masked/replaced by the metadata for the p2 repo IU a.b.c, though augmented with any additional requirements that the workspace IU might have (newly introduced requirements) but that the p2 repo IU doesn't have, and modified to relax the version constraints (within the micro version range) of the requirements and to relax the filters. So likely what's happening is that your workspace IU A has a p2 repo equivalent A and that has a requirement strict enough that the workspace B no longer satisfies it. This type of problem sometimes (at the start of a release cycle) arises with the platform code when they make version changes and have not yet built a new p2 repo with those changed IUs.
In any case, what you can try is to set "Include Binary Equivalents" to false. If that's false for any Targlet, the overall resolution will not try to resolve both a workspace IU and the p2 repo IU. In the worst case, you can try setting "Include All Requirements" to false. If any Targlet does this, the overall resolution will not fail, but will try to resolve as many IUs as possible. In this case the resulting binary TP might not have properly resolved all of the requirements of the workspace IUs but will be as complete as possible and the workspace IUs will all be imported as projects in the workspace so you'll be able to investigate what's not compiling in the workspace and what's missing from the binary TP and try to figure out what's missing.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Modular target resolution [message #1778875 is a reply to message #1778825] |
Fri, 22 December 2017 20:04 |
Ernesto Posse
Messages: 438
Registered: March 2011 |
Senior Member |
|
|
Ed Merks wrote on Fri, 22 December 2017 02:31
Certainly quite tricky situations can arise with unified workspace IUs and p2 repo IUs. If during resolution A_1is found, then it must be visible via a source locator (a workspace IU) or via a p2 repository location (a p2 repository IU). The bundle pool is a p2 artifact repository, but it is not a p2 metadata repository. In other words the bundle is used only to resolve artifacts, not during resolution to resolve metadata about those artifacts. So regardless of what is or isn't in the bundle pool, that will have no impact on the resolution process. And yes, the resolution process is purely using the p2 APIs, though seeded with metadata gathered from the workspace IUs so the behave as if they were actually in a p2 repository.
Ed Merks wrote on Fri, 22 December 2017 02:31
By default each Targlet will have "Include Binary Equivalents" set to true. The net effect of this is that for each workspace IU a.b.c, if there is a p2 repo IU a.b.c, the metadata for the workspace IU is masked/replaced by the metadata for the p2 repo IU a.b.c, though augmented with any additional requirements that the workspace IU might have (newly introduced requirements) but that the p2 repo IU doesn't have, and modified to relax the version constraints (within the micro version range) of the requirements and to relax the filters. So likely what's happening is that your workspace IU A has a p2 repo equivalent A and that has a requirement strict enough that the workspace B no longer satisfies it. This type of problem sometimes (at the start of a release cycle) arises with the platform code when they make version changes and have not yet built a new p2 repo with those changed IUs.
Oh! I see. The explanation is plausible.
So the IUs in the p2 pool are not the ones used to get the metadata, but rather the p2 repos?
What is the rationale for masking the metadata for the workspace IU with the one from the p2 repo? I would have expected this to be the other way around. And when doing this masking isn't the version of the IU considered?
In my case, there is a p2 repo with the new version of B, (B_2), but none yet for the updated A (A_2) that depends on B_2.
Ed Merks wrote on Fri, 22 December 2017 02:31
In any case, what you can try is to set "Include Binary Equivalents" to false. If that's false for any Targlet, the overall resolution will not try to resolve both a workspace IU and the p2 repo IU.
So in this case what happens? Only the workspace IU will be attempted?
Ed Merks wrote on Fri, 22 December 2017 02:31
In the worst case, you can try setting "Include All Requirements" to false. If any Targlet does this, the overall resolution will not fail, but will try to resolve as many IUs as possible. In this case the resulting binary TP might not have properly resolved all of the requirements of the workspace IUs but will be as complete as possible and the workspace IUs will all be imported as projects in the workspace so you'll be able to investigate what's not compiling in the workspace and what's missing from the binary TP and try to figure out what's missing.
Thanks
|
|
|
| Re: Modular target resolution [message #1778885 is a reply to message #1778875] |
Fri, 22 December 2017 20:57 |
Ed Merks
Messages: 33139
Registered: July 2009 |
Senior Member |
|
|
Yes, the pool is used only to resolve artifacts, not as a source of information about which IUs are visible for resolution.
The rationale for the resolution process that include binary IUs is complex. For large projects such as Papyrus, the workspace ends up huge to the point of taking a long time to build, so they desire being able to close workspace projects so that the binary IUs are available. Also the platform itself is quite tricky. Imagine you work on p2's source, but want the full Eclipse SKD in your TP so you can launch and IDE and debug with sources for everything. But the IDE depends on p2 and requires a version of p2's bundles that are not exactly those in the workspace (which of course use x.y.z.qualifier). Trying to resolve in this scenario is complex and I could spend a 1/2 hour explaining the subtleties.
If you don't "Include Binary Equivalents" then generally you won't end up with a binary p2 IU form any IU for which there is a workspace IU, but the workspace IU's requirements will all be satisfied. But in a complex scenario such as p2 source and wanting a full Eclipse SDK resolve, this resolution might fail.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Sat Apr 20 15:59:43 GMT 2024
Powered by FUDForum. Page generated in 0.04301 seconds |
] 
Search
Help
Register
Login
Home
