Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Equinox » Debugging dependency resolution
Debugging dependency resolution [message #1851620] Mon, 11 April 2022 11:23 Go to next message
Vaclav Hala is currently offline Vaclav HalaFriend
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
Re: Debugging dependency resolution [message #1851631 is a reply to message #1851620] Mon, 11 April 2022 13:26 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 32494
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/
Re: Debugging dependency resolution [message #1851699 is a reply to message #1851631] Tue, 12 April 2022 17:16 Go to previous messageGo to next message
Vaclav Hala is currently offline Vaclav HalaFriend
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
Re: Debugging dependency resolution [message #1851705 is a reply to message #1851699] Wed, 13 April 2022 06:02 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 32494
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/
Re: Debugging dependency resolution [message #1851707 is a reply to message #1851705] Wed, 13 April 2022 07:05 Go to previous message
Vaclav Hala is currently offline Vaclav HalaFriend
Messages: 4
Registered: December 2021
Junior Member
Great, setting the includeAllDependencies option in the pom did the trick, now there is all the info I need in the report. Thanks a lot!
Previous Topic:Building and testing frameworks eclipse.c
Next Topic:Accessing a P2 repository with SSO authentication
Goto Forum:
  


Current Time: Wed Sep 28 09:23:56 GMT 2022

Powered by FUDForum. Page generated in 0.02403 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top