Dependencies with RELEASE as version cannot be resolved (in 6.3.2)

[Ripp13]

Dependencies with RELEASE as version cannot be resolved (since 3.6.2)

My department supports all Java application teams in my organisation. To this end my department has created an "application" that contains dependencies that are commonly used in our Java projects. This application creates a daily report with the OWASP dependency check. Some of these dependencies are internally developed components. For the external libraries/frameworks we're using version ranges in the pom.xml, for the internal components we're using the RELEASE tag, so we're always looking at the latest version.

Since version 6.3.2 we're getting resolution exceptions for dependencies that use the RELEASE tag:
Failed to resolve dependency nl.belastingdienst.jacob:jacob-business-calendar:jar:8.1.2-2 with dependencyResolver
exception: org.owasp.dependencycheck.exception.DependencyNotFoundException: Failed to resolve dependency nl.belastingdienst.jacob:jacob-business-calendar:jar:8.1.2-2 with dependencyResolver
org.owasp.dependencycheck.maven.BaseDependencyCheckMojo.collectMavenDependencies(BaseDependencyCheckMojo.java:1334)
org.owasp.dependencycheck.maven.BaseDependencyCheckMojo.collectDependencies(BaseDependencyCheckMojo.java:1467)
org.owasp.dependencycheck.maven.BaseDependencyCheckMojo.scanArtifacts(BaseDependencyCheckMojo.java:1114)
org.owasp.dependencycheck.maven.AggregateMojo.scanDependencies(AggregateMojo.java:69)
org.owasp.dependencycheck.maven.BaseDependencyCheckMojo.runCheck(BaseDependencyCheckMojo.java:1719)
org.owasp.dependencycheck.maven.BaseDependencyCheckMojo.execute(BaseDependencyCheckMojo.java:966)
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:957)
org.apache.maven.cli.MavenCli.doMain(MavenCli.java:289)
org.apache.maven.cli.MavenCli.main(MavenCli.java:193)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
java.lang.reflect.Method.invoke(Method.java:498)
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)

If I replace the for one of those dependencies in a hardcoded version the resolution exception doesn't occur for that dependency.

This issue does not occur with 6.3.1 of dependency-check-maven.

Extract of the pom.xml (I removed parts for readability):

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">

	<modelVersion>4.0.0</modelVersion>

	<parent>
		<groupId>nl.belastingdienst.jacob</groupId>
		<artifactId>jacob-maven-parent-ee7</artifactId>
		<version>8.3.2</version>
	</parent>

	<groupId>nl.belastingdienst.ywb</groupId>
	<artifactId>ywb-check-beheerde-componenten</artifactId>
	<version>1.0.0-SNAPSHOT</version>

	<packaging>war</packaging>
	<name>${project.artifactId}</name>

	<properties>
		<bcao.project.naam>ywb</bcao.project.naam>
		<bcao.component.naam>ywb-check-beheerde-componenten</bcao.component.naam>

		<version.dozer>[6.5.0, 6.999.999]</version.dozer>

		<version.jacob-component-latest-release>RELEASE</version.jacob-component-latest-release>
	</properties>

	<dependencies>

		<!-- this is an example of an external dependency that is monitored by us, it is controlled by a version range -->
		<dependency>
			<groupId>com.github.dozermapper</groupId>
			<artifactId>dozer-core</artifactId>
			<version>${version.dozer}</version>
		</dependency>

		<!-- these are examples of internally developed dependencies, these are using the RELEASE version -->
		<dependency>
			<groupId>nl.belastingdienst.jacob</groupId>
			<artifactId>jacob-business-calendar</artifactId>
			<version>${version.jacob-component-latest-release}</version>
		</dependency>
		<dependency>
			<groupId>nl.belastingdienst.jacob</groupId>
			<artifactId>jacob-document-generator</artifactId>
			<version>${version.jacob-component-latest-release}</version>
		</dependency>

	</dependencies>

</project>

Version info:
Apache Maven 3.6.3
Maven home: /usr/share/maven
Java version: 1.8.0_292, vendor: Private Build, runtime: /usr/lib/jvm/java-8-openjdk-amd64/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.11.0-37-generic", arch: "amd64", family: "unix"

I also tested this with Adopt OpenJDK 11, which gave the same results.

[mprins]

This is atypical use of an invalid version number (no longer supported in Maven 3: https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes#Maven3.xCompatibilityNotes-PluginMetaversionResolution) ,
What happens when you run org.apache.maven.plugins:maven-dependency-plugin:3.2.0:resolve? does that work without error?

The dependency resolution was improved/fixed in 6.3.2: jeremylong/DependencyCheck#3627

[Ripp13]

org.apache.maven.plugins:maven-dependency-plugin:3.2.0:resolve works fine.

[aikebah]

@mprins the 'no longer supported' is for using it as a version for plugins.
@Ripp13 nevertheless for the sake of reproducible builds (being able to recreate an old version artifact from its version controlled sources) it is strongly advised to also not use RELEASE for your dependencies.
If the component referenced has seen a new release in between the original build and your rebuild the rebuild suddenly gets a new version of the library which might no longer be functionally compatible.

[aikebah]

Using RELEASE for a plugin yields

[ERROR]   The project com.example:odc-example:master-SNAPSHOT (/Users/aikebah/Projects/odc-exmple-issue3730/pom.xml) has 1 error
[ERROR]     'build.plugins.plugin.version' for org.owasp:dependency-check-maven must be a valid version but is 'RELEASE'. @ line 30, column 26

Whereas using RELEASE for a dependency yields

[WARNING] 
[WARNING] Some problems were encountered while building the effective model for com.example:security:jar:master-SNAPSHOT
[WARNING] 'dependencies.dependency.version' for org.apache.commons:commons-lang3:jar is either LATEST or RELEASE (both of them are being deprecated) @ line 18, column 22
[WARNING] 
[WARNING] It is highly recommended to fix these problems because they threaten the stability of your build.
[WARNING] 
[WARNING] For this reason, future Maven versions might no longer support building such malformed projects.
[WARNING] 

[Ripp13]

@aikebah Sure, normally I wouldn't use RELEASE because, as you say, "reproducible builds", but as I said before, this particular application is there just for monitoring issues in commonly used internal and external depenendencies, so the "ontwikkelstraat" can monitor vulnerabilities in a single location.

[jeremylong]

@aikebah would this be resolved with the recent updates you made?

[aikebah]

@jeremylong should be resolved by my issue-3721 branch, but had troubles creating a working IT. Think I nailed the issue (invoker runs fail with resolutionException while regular mvn ..... invocation for same it pom.xml succeeds) and expect to add a commit and PR soon

[YSavanier]

Hello

It seems the problem still occurs when checking for a dependency declaring a sub-dependency with a RELEASE or LATEST metaversion.

Exemple, for project AAAA having dependency BBBB with RELEASE metaversion referencing dependency YYYY also with RELEASE metaversion we get the error :

DependencyNotFoundException: Expected dependency not found in resolved artifacts for dependency XXXX:YYYY:jar:RELEASE:compile of project-artifact AAAA

When the sub-dependency BBBB is declared directly in the project AAAA (for exemple with scope provided) there is no more error thrown, so it clearly doesn't fail anymore for dependencies with RELEASE metaversion but still fail on subdependencies with RELEASE metaversion.

So today we are referencing all RELEASE subdependencies directly in our project pom.xml with scope set to provided as a palliative measure to make things work.

Thank you very much.

[aikebah]

@YSavanier Thanks for mentioning it. Created a separate issue for the case of transitive RELEASE/LATEST metaversion case for transitive dependencies.