You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Andy Seaborne (Jira)" <ji...@apache.org> on 2021/08/01 12:57:00 UTC
[jira] [Commented] (MENFORCER-385) Enforce that transitive provided
dependencies are contained in the runtime Maven classpath
[ 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)