Eclipse Community Forums: Equinox » Debugging dependency resolution

Help

Home

Home » Eclipse Projects » Equinox » Debugging dependency resolution

Show: Today's Messages :: Show Polls :: Message Navigator

Debugging dependency resolution [message #1851620]

Mon, 11 April 2022 11:23

Vaclav Hala

Messages: 4
Registered: December 2021

Junior Member

Hello, the other day I had a problem with investigating why some plugins are ending up in my materialized product. I found no simple way to display the walk through the target platform which eventually results in list of bundles being present in the product. I ended up using debugger and printing breakpoints to get this information by printing this

System.out.format("%s -[%s]> %s\n", iu.getId(), req, match.getId());

inside Slicer at line

consider(match);

which gave me output like this that quickly helped me find what I was looking for

[INFO] Resolving dependencies of MavenProject: group:my.product:0.0.1-SNAPSHOT @ /data/my.product/pom.xml
my.product -[org.eclipse.equinox.p2.iu; my.feature.feature.group 0.0.0]> my.feature.feature.group
my.product -[org.eclipse.equinox.p2.iu; other.feature.feature.group 0.0.0]> other.feature.feature.group
my.feature.feature.group -[java.package; my.bundle.api 0.0.0]> my.bundle
...

So first a question - is there some better way to get to this information?

And second, if there is no way to do this, would it be possible to add some listener to Slicer and other similar algorithms which would enable arbitrary visualization like simply printing the walk as I did or e.g. assembling a .dot file that can be used to visualize it graphically. I'm thinking something as simple as this

public class Slicer {

  public IQueryable<IInstallableUnit> slice(
    IInstallableUnit[] ius, 
    ISlicingListener slicingListener,
    IProgressMonitor monitor) { ... }

  interface ISlicingListener{
  void slicingStarted(IInstallableUnit[] ius);
  void considered(
    IInstallableUnit requestor,
    IRequirement requirement,
    IInstallableUnit match)
  }
  void slicingSucceeded();
  void slicingFailed();
}

so that tooling like Tycho can provide own useful implementations

Report message to a moderator

Re: Debugging dependency resolution [message #1851631 is a reply to message #1851620]

Mon, 11 April 2022 13:26

Ed Merks

Messages: 33137
Registered: July 2009

Senior Member

There are tools out there that show can show a plug-in dependency graph; I'd have to Google them.. I think the general problem is that the graph gets huge and unmanageable really quickly.

One possible alternative approach is to build a report of the product's repository. The report is documented here:

https://wiki.eclipse.org/Oomph_Repository_Analyzer#Update_Site_Pages

This job configuration shows how you can generate such a report:

https://ci.eclipse.org/oomph/job/repository-analyzer/configure

As an example, you can see which IUs in the repository link to each other by their provided capabilities and their required capabilities. E.g., here is a pair of such links:

https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/eclipse/updates/4.23/R-4.23-202203080310/index/assertj-core_3.21.0.html#org.eclipse.equinox.p2.iu;_version:OSGiVersion=3.21.0;_org.eclipse.equinox.p2.iu:String=assertj-core
https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/eclipse/updates/4.23/R-4.23-202203080310/index/org.eclipse.test.feature.group_3.8.0.v20211210-1030.html#org.eclipse.equinox.p2.iu;_assertj-core_[3.21.0,3.21.0]

In the end, you don't really need a listener. All this dependency information is in the IUs and it's mostly a process of linking the provided capabilities with the required capabilities...

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: Debugging dependency resolution [message #1851699 is a reply to message #1851631]

Tue, 12 April 2022 17:16

Vaclav Hala

Messages: 4
Registered: December 2021

Junior Member

Thanks for the tip, the hyperlinks to provided/required bundles seem like just the thing I need.
Unfortunately I have trouble generating the report for my product. I'm trying to run it like this:

/opt/eclipse/eclipse-installer/eclipse-inst \
  -application org.eclipse.oomph.p2.core.RepositoryIntegrityAnalyzer  \
  -consoleLog   -noSplash  -v \
  -o /tmp/eclipse_report \
  -s "https://ci.eclipse.org/oomph/job/repository-analyzer/" \
  file:///data/myapp/releng/my.product/target/products/my.product/linux/gtk/x86_64/

but I'm getting error No repository found at file:///data/myapp/releng/my.product/target/products/my.product/linux/gtk/x86_64.

I can run it successfully by putting path to file:///data/myapp/releng/my.product/target/repository,
trouble is this repository does not event contain the problematic bundle I'm hunting so it is not in the report as well.
When I tried to find places where the bundle is present in the target the only place was in the target/products/my.product/linux/gtk/x86_64..
I'm not sure if this is normal or we have some problem in our build configuration? If there is problem it can't be anything fatal as the materialized product from the target/products folder works as expected.

Is it possible to create the report from contents of the materialized product? If so, could you please give me some hints how to invoke the command? Thanks

Report message to a moderator

Re: Debugging dependency resolution [message #1851705 is a reply to message #1851699]

Wed, 13 April 2022 06:02

Ed Merks

Messages: 33137
Registered: July 2009

Senior Member

No, a materialized product doesn't have the content metadata file; though it does have profile with the same content metadata and does have an artifacts.xml so could in principle be analyzed.

For Oomph's product we build the repository to include all transitive dependencies like this in the pom.xml

  <build>
    <plugins>
      <plugin>
         <groupId>org.eclipse.tycho</groupId>
         <artifactId>tycho-p2-repository-plugin</artifactId>
         <version>${tycho-version}</version>
         <configuration>
           [<includeAllDependencies>true</includeAllDependencies> <!---- here ---->
            <repositoryName>Eclipse Installer Build ${build.id}</repositoryName>
            <skipArchive>true</skipArchive>
         </configuration>
      </plugin>

You could enable that at least temporarily for the analysis.

Alternatively, you could create a composite repository that composes all the source repositories used to build your product and analyze that...

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator