Add Require-Bundle dependency checking to DependencyCheckMojo

[Copilot]

• Analyze existing DependencyCheckMojo code structure
• Understand how Import-Package checking works
• Identify key classes: ArtifactVersionProvider, ArtifactMatcher
• Understand how require-bundle works differently from import-package
• Enhance ArtifactVersionProvider interface with getBundleVersions method
• Implement getBundleVersions in MavenArtifactVersionProvider
• Implement getBundleVersions in EclipseIndexArtifactVersionProvider
• Add findBundle method to ArtifactMatcher
• Refactor DependencyCheckMojo to use checker classes (per review feedback)
  • Create DependencyChecker base class with CheckContext record
  • Create ImportPackageChecker for Import-Package checking
  • Create RequireBundleChecker for Require-Bundle checking
  • Simplify DependencyCheckMojo to use checker classes
• Build verification passes
• Run code review
• Run CodeQL security check (no issues found)

Original prompt

DependencyCheckMojo currently do a good job on import-package and should now be enhanced to also check require bundle dependecies. Required bundles behave a little bit different from packages because all packages they export are implicitly imported. Aslo the package version does not match (or if it has a version at all) but only the bundle version. So what we need to do first for a require bundle is to collect all bundle version that match the requirement, then the lowest valid version is the one that has no issue for any of its provided packages. On crucial part of the job is to identify how we possibly can reuse existing code (maybe extracting methods or new classes) so we do not blow up this already complex class by replicate everything for require bundle!

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[laeubi]

@copilot The number of method arguments are quite high and hard to understand can we possibly use records to group related information? Possibly even extract the code in an own class e.g. assume we have a ImportPackageChecker and an RequireBundleChecker, these can hold the lowest/all/error collections and we pass static inforation in their constructors, then move the coresponding check method there so we can incrementally update and read only the final results at the end.

[Copilot]

Refactored in 75e34e7. Created:

• DependencyChecker base class with CheckContext record to hold shared state
• ImportPackageChecker for Import-Package checking
• RequireBundleChecker for Require-Bundle checking

The checkers hold their own state (lowestVersion, allVersions, withError collections) and expose results via getters. The mojo now creates instances with a shared context and reads final results from them.

[Copilot]

Just as a heads up, I was blocked by some firewall rules while working on your feedback. Expand below for details.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• testng.org
  • Triggering command: /opt/hostedtoolcache/CodeQL/2.24.0/x64/codeql/tools/linux64/java/bin/java /opt/hostedtoolcache/CodeQL/2.24.0/x64/codeql/tools/linux64/java/bin/java -jar /opt/hostedtoolcache/CodeQL/2.24.0/x64/codeql/xml/tools/xml-extractor.jar --fileList=/home/REDACTED/work/tycho/.codeql-scratch/dbs/java/working/files-to-index5588883825930985295.list --sourceArchiveDir=/home/REDACTED/work/tycho/.codeql-scratch/dbs/java/src --outputDir=/home/REDACTED/work/tycho/.codeql-scratch/dbs/java/trap/java (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)