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)