[
https://issues.apache.org/jira/browse/SLING-11369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated SLING-11369:
------------------------------------
Description:
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:
My Maven Plugin "A" -> 3rd Party Library "B" -> Provided Dependency "C"
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 was originally proposed in MENFORCER-385 but declined as considered too
much of an edge case.
Compare with the discussion at
https://lists.apache.org/thread/ttncrwmsnk29qy6n3on6ymfbq9s7dbnm
was:
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:
My Maven Plugin "A" -> 3rd Party Library "B" -> Provided Dependency "C"
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 was originally proposed in MENFORCER-385.
Compare with the discussion at
https://lists.apache.org/thread/ttncrwmsnk29qy6n3on6ymfbq9s7dbnm
> Provide Maven Enforcer rule which checks that transitive provided
> dependencies are contained in the runtime Maven classpath
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: SLING-11369
> URL: https://issues.apache.org/jira/browse/SLING-11369
> Project: Sling
> Issue Type: New Feature
> Components: Tooling
> Reporter: Konrad Windszus
> Assignee: Konrad Windszus
> 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:
> My Maven Plugin "A" -> 3rd Party Library "B" -> Provided Dependency "C"
> 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 was originally proposed in MENFORCER-385 but declined as considered too
> much of an edge case.
> Compare with the discussion at
> https://lists.apache.org/thread/ttncrwmsnk29qy6n3on6ymfbq9s7dbnm
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
