Issues since version 6.3.0

[StefanHirche]

Hi,
I was using version 6.2.2 and wanted to upgrade to 7.2 but I got this issue

Unable to resolve system scoped dependency: p2.eclipse.plugin:org.apache.xerces:eclipse-plugin:2.12.1.v20210115-0812:system
exception: org.owasp.dependencycheck.exception.DependencyNotFoundException: Unable to resolve system scoped dependency: p2.eclipse.plugin:org.apache.xerces:eclipse-plugin:2.12.1.v20210115-0812:system

org.owasp.dependencycheck.maven.BaseDependencyCheckMojo.collectMavenDependencies(BaseDependencyCheckMojo.java:1292)
org.owasp.dependencycheck.maven.BaseDependencyCheckMojo.collectDependencies(BaseDependencyCheckMojo.java:1437)
org.owasp.dependencycheck.maven.BaseDependencyCheckMojo.scanArtifacts(BaseDependencyCheckMojo.java:1098)
org.owasp.dependencycheck.maven.AggregateMojo.scanDependencies(AggregateMojo.java:73)
org.owasp.dependencycheck.maven.BaseDependencyCheckMojo.runCheck(BaseDependencyCheckMojo.java:1689)
org.owasp.dependencycheck.maven.BaseDependencyCheckMojo.execute(BaseDependencyCheckMojo.java:950)
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:210)
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:156)
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305)
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192)
org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105)
org.apache.maven.cli.MavenCli.execute(MavenCli.java:972)
org.apache.maven.cli.MavenCli.doMain(MavenCli.java:293)
org.apache.maven.cli.MavenCli.main(MavenCli.java:196)
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
java.base/java.lang.reflect.Method.invoke(Method.java:566)
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
java.base/java.lang.reflect.Method.invoke(Method.java:566)
org.apache.maven.wrapper.BootstrapMainStarter.start(BootstrapMainStarter.java:39)
org.apache.maven.wrapper.WrapperExecutor.execute(WrapperExecutor.java:122)
org.apache.maven.wrapper.MavenWrapperMain.main(MavenWrapperMain.java:61)

So I tried different versions and this issue first occures with version 6.3.0.
I do not have the slightest clue on why this happens.
The build uses tycho pomless , maybe this is related.

Thanks for this great plugin andyour work maintaining it.

[jeremylong]

Any chance you can provide an example project that causes this issue?

[aikebah]

Likely related to jeremylong/DependencyCheck#3501 - an upgrade of the maven internal libraries

[aikebah]

In one or more of your project's dependencies there is a transitive dependency with scope set to system that is listing a path (potentially with an environment variable) that does not resolve to the given dependency.

[aikebah]

I think we can improve the error message somewhat by also listing what according to the dependency is the system path where it was supposed to be found.

[StefanHirche]

I just tried to create a small project, but this is not as easy as I thought.
But I then saw, that xerces has a dependency to org.apache.xml.resolver and that again has a dependency to
org.eclipse.osgi. And this dependency is written as (at least in the eclipse editor I use) system.bundle [org.eclipse.osgi]

[StefanHirche]

@aikebah Hi, would it be possible to add your change to the error message, so I could maybe dig deeper into the problem?
Thx.

[aikebah]

@StefanHirche would you be able to build a snapshot from branch issue-4969 to see if added logging does shine more light on the subject?
If it turns out there is no info to show in these cases I'd rather not confuse users with strange log messages.

[StefanHirche]

Hi, I build your branch and run the plugin-in. I got this
[ERROR] DependencyNotFoundException: Unable to resolve system scoped dependency: myplugin:myplugin.source:eclipse-plugin:libs/3rdparty.jar:8.1.0.qualifier:system at path null

I use a 3rdparty plugin withoutputting it into maven, just into the libs folder of my plugin, because it is actively developed and changes very fast at the moment.

But this is a new construct, so I'll try to remove this to look at the older issues mentioned in this ticket.

[aikebah]

@StefanHirche how is the system-path setup in the pom? Because it looks like how we currently collect/resolve dependencies does not resolve it to the actual configured location, but to null.

[StefanHirche]

There is no configuration for the system path in the pom.

[StefanHirche]

I now also get this error after removing the local lib:
[ERROR] DependencyNotFoundException: Unable to resolve system scoped dependency: p2.eclipse.plugin:jakarta.activation-api:eclipse-plugin:1.2.2:system at path null
Seems to be the same issue, but I don't even have a clue what to set the system path to. And where.

[aikebah]

Well, a system-scoped dependency (while deprecated) is always supposed to have a systemPath telling maven where to find the jar representing/containing that dependency so that it can be included in the classpath. (see also https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#System_Dependencies)
Are you sure these should be system-scoped? Or is there maybe some eclipse/p2 plugin-magic happening behind the scenes that injects those system-paths into maven's internals after maven has done it's dependency resolution and failed to resolve the system dependencies?

[aikebah]

@StefanHirche googled a bit on tycho-pomless and think the two are related indeed. It looks as if the tycho-pomless core extension does not inject the proper system-path when using modern versions of maven shared libraries for dependency-collection/resolution.

[aikebah]

@StefanHirche If you are able to provide a (dummy would be good enough, but real-life public project would also be fine) reproducer project using tycho-pomless and triggering this behaviour that would help in getting me started to dig deeper into this with mvndebug (as I have no experience on tycho / tycho-pomless I don't want to start out on the adventure from scratch)

[StefanHirche]

Yes, but it might take a little time.

[aikebah]

NP... would be nice to try and resolve this so that it also works properly for tycho-pomless, but not in any hurry on that.

[StefanHirche]

Hi,
OK, with 5220 this gets more urgent. Or is there a chance to get the fix backported to 6.2.2?
If not I will start to create an example project tomorrow.
Thanks.

[aikebah]

@StefanHirche Assuming that your CVE database is persistent between builds you should be able to resolve the issue, while continuing to scan with 6.2.2 by running a dedicated job for CVE database update (mvn org.owasp:dependency-check-maven:7.4.4:update-only) as a one-off job.

6.2.2 should run fine with the updated database schema that 7.4.4 will upgrade to.

[StefanHirche]

Hi,

Here you can find my project, I hope it works (or better not)
https://github.com/StefanHirche/OWASPTest

Strange thing is the issue only occurs with a second plugin as fragment to the first and the tycho-source plugin has to be used.

[aikebah]

@StefanHirche Thanks, can confirm that it works for me as a reproducer. Had to fix some configurations that leak your internal setup (mvnw JAVA_HOME, pointing to a windows path and your private maven distribution-url inside the .mvn folder (may I suggest upgrading to Maven 3.8.7?)

[ERROR] Failed to execute goal org.owasp:dependency-check-maven:7.4.4:aggregate (default-cli) on project root: One or more exceptions occurred during dependency-check analysis: One or more exceptions occurred during analysis:
[ERROR] 	DependencyNotFoundException: Unable to resolve system scoped dependency: client:client.bundle.source:eclipse-plugin:libs/uls-client_99.0.0.100.jar:1.0.0.qualifier:system
[ERROR] 	DependencyNotFoundException: Unable to resolve system scoped dependency: client:client.bundle.source:eclipse-plugin:libs/uls-common_99.0.0.100.jar:1.0.0.qualifier:system

[aikebah]

@StefanHirche Hope to dig a bit deeper after finishing up reviews of the currently pending 8.0.0-targeted PRs, but initial looks in debug-mode make me suspect that it should be resolvable by some further updates to the resolution logic (won't make it into 8.0.0 yet which we intend to release this week, but hope to have it available for 8.1.0 (release date still to be decided on, depends on what else gets fixed in the near future))

[StefanHirche]

Thanks,
just in case you still need this example, I just recreated the repo without the leaks, thanks for the notice.
I also upgraded maven and tycho (to 3.0.0), the issue still remains, but Java 17 is now needed.

[aikebah]

@StefanHirche Can you validate my resolution from this branch (working for your 'pet-project') to be also working for the real-life Tycho pomless projects that you have before I file the PR for integrating it into the main development branch?

[aikebah]

@jeremylong I think it would be good that this lands in the next release, so I marked it for 8.0.2 milestone, but unsure whether we should call it a fix (of broken setup with Tycho pomless) which would mean 8.0.2, or a feature/enhancement (now also supporting Tycho pomless extension to maven) which would mean 8.1.0

I tend mostly to a fix as in: we should not assume that maven extensions add system-scoped dependencies with a systemPath prefilled, but should rely on the extensions to also properly extend the artifact resolution for anything added as system-scoped.

[StefanHirche]

@StefanHirche Can you validate my resolution from this branch (working for your 'pet-project') to be also working for the real-life Tycho pomless projects that you have before I file the PR for integrating it into the main development branch?

OK, I tested your noew changes and it seems to work. I don't get any errors anymore and all dependencies, also those provided directly in a plugin, show in the list of all dependencies.

Thanks for your work.

[jeremylong]

@aikebah I vote fix and just bump the patch level.