[
https://issues.apache.org/jira/browse/MENFORCER-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17391144#comment-17391144
]
Andy Seaborne commented on MENFORCER-385:
-----------------------------------------
(I'm not sure this is the right place because it isn't about plugins.)
Upgrading 3.0.0-M3 to 3.0.0 has caused enforcer errors on dependency
convergence with scope=provided on artifacts where the provided is not used.
This is occurring on unused features of dependencies 2+ levels down, not in the
project being built.
log4j2 + commons-compress:
{noformat}
...
+-org.apache.logging.log4j:log4j-api:jar:2.14.1:compile
+-org.osgi:org.osgi.core:jar:4.3.1:provided
and
...
+-org.apache.commons:commons-compress:jar:1.21:compile
+-org.osgi:org.osgi.core:jar:6.0.0:provided
{noformat}
(FWIW: there is no use of OSGi in the jar being built.)
log4j2's usage is documented as: (log4j-2.14.1 POM)
{noformat}
<!-- The OSGi API version MUST always be the MINIMUM version Log4j supports
-->
{noformat}
Similar issues arise for shiro-web + log4j2 on servletAPI and Eclipse Jetty
The servlet API is upwards compatible.
Another example:
Apache Common Fileupload latest (1.4), released 2018-12-24, has a servletAPI
dependency of 2.4 , Eclipse Jetty has dependency of 2.5. Some artifacts will be
perfectly functionally yet quite old.
Is there a way to not enforce "scope=provided" artifacts, for these features
multiple levels away?
Or does the project need to write and maintain exclusions for each and everyone
"scope=provided" it does not use.
This sensitivity to dependency features the build isn't using makes the
dependency convergence rule less suitable for general use on the true
dependencies.
> Enforce that transitive provided dependencies are contained in the runtime
> Maven classpath
> ------------------------------------------------------------------------------------------
>
> Key: MENFORCER-385
> URL: https://issues.apache.org/jira/browse/MENFORCER-385
> Project: Maven Enforcer Plugin
> Issue Type: Improvement
> Components: Standard Rules
> Reporter: Konrad Windszus
> Assignee: Robert Scholte
> Priority: Major
>
> All dependencies with {{provided}} scope are not transitively inherited.
> While this isn't a problem usually during compile time it is a problem for
> Maven plugins at run time, as they use the Maven dependency classpath also at
> run time
> (https://maven.apache.org/guides/mini/guide-maven-classloading.html#3-plugin-classloaders).
> At run time they fail if the transitive provided dependency has not been
> declared explicitly.
> As manually specifying all transitive (but hidden) {{provided}} dependencies
> is a very error-prone process an enforcer rule for that would be highly
> beneficial. Especially as the transitive dependencies have to be rechecked
> once you upgrade to a newer version.
> Example:
> {code:java}
> My Maven Plugin "A" -> 3rd Party Library "B" -> Provided Dependency "C"{code}
> As "B" uses "C" at run time it needs to be declared as dependency of "A" as
> well otherwise you might see {{java.lang.ClassNotFoundException}} when
> executing Maven plugin "A".
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
