delanym commented on issue #280:
URL:
https://github.com/apache/maven-dependency-analyzer/issues/280#issuecomment-4751806770
Sure. So i recently added this configuration to our multi-module project to
require that all **used** dependencies are **declared**.
It is no longer acceptable to depend on classes provided by transitive
dependencies:
```xml
<plugin>
<artifactId>maven-dependency-plugin</artifactId>
<version>3.11.0</version>
<executions>
<execution>
<id>enforce-explicit-dependencies</id>
<goals>
<goal>analyze-only</goal>
</goals>
<phase>verify</phase>
<configuration>
<failOnWarning>true</failOnWarning>
<!-- Temporary -->
<ignoreAllNonTestScoped>true</ignoreAllNonTestScoped>
<ignoreNonCompile>true</ignoreNonCompile>
<ignoreUnusedRuntime>true</ignoreUnusedRuntime>
<ignoredUsedUndeclaredDependencies>
<!-- Test infrastructure -->
<usedUndeclaredDependency>org.junit.jupiter:junit-jupiter-api:jar:*</usedUndeclaredDependency>
<usedUndeclaredDependency>org.junit.jupiter:junit-jupiter-params:jar:*</usedUndeclaredDependency>
<usedUndeclaredDependency>com.tngtech.archunit:archunit:jar:*</usedUndeclaredDependency>
<usedUndeclaredDependency>org.mockito:mockito-core:jar:*</usedUndeclaredDependency>
<usedUndeclaredDependency>org.slf4j:slf4j-api:jar:*</usedUndeclaredDependency>
<!-- Deprecated -->
<usedUndeclaredDependency>com.google.code.findbugs:jsr305:jar:*</usedUndeclaredDependency>
<!-- Shaded -->
<usedUndeclaredDependency>org.glassfish.metro:webservices-api:jar:*</usedUndeclaredDependency>
</ignoredUsedUndeclaredDependencies>
</configuration>
</execution>
</executions>
</plugin>
```
You'll notice that `webservices-api` is ignored. This is because as long as
it is on the classpath the dependency plugin will suggest to add it to satisfy
this rule when a dependent project requires a class that it has. However,
`webservices-api` is an artifact shading various jakarta micro apis
(`activation`, `jws`, `mail` and `xml`). I would rather my colleagues were
prompted to include those dependencies, not the `webservices-api` dependency.
You might ask: why do we have both dependencies on the classpath in the
first place? I agree, we need to sort that out. I was actually hoping the
dependency plugin could help with this. When there are **more than one**
potential dependency the plugin should suggest **all** potential dependencies.
I removed from this config other `usedUndeclaredDependency`of shaded company
artifacts that had to be ignored. Unlike metro dependencies, these are not
going to be easy to remove/replace.
Another example is where shading is unavoidable, but exclusions have not
been properly applied.
For example, the [kryo
](https://github.com/EsotericSoftware/kryo)persistency project depends on a
static logger called [minlog](https://github.com/EsotericSoftware/minlog).
I want to use kryo, but i want all logs to pass through slf4j.
Until https://github.com/EsotericSoftware/minlog/pull/17 is accepted my only
option is to shade the `com.esotericsoftware.minlog.Log` class. I suspect this
would only be a problem if I forgot to exclude minlog from the kryo dependency,
and i ended up with some code compiling against it but not declaring the
dependency.
Its an unlikely situation, but it does demonstrate another possible grey
area that i shouldn't have to concern myself with (or my colleagues, who know
and care less).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
