[jira] [Updated] (MENFORCER-335) Documentation suggests unreliable practice for dependency convergence

2019-07-24 Thread Roland Illig (JIRA)


 [ 
https://issues.apache.org/jira/browse/MENFORCER-335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roland Illig updated MENFORCER-335:
---
Description: 
The [documentation for Dependency 
Convergence|https://maven.apache.org/enforcer/enforcer-rules/dependencyConvergence.html]
 describes how to suppress an error reported by the check. This description 
leads to unreliable project configurations. It may or may not be intentional 
that the documentation merely states "And this will succeed" without explicitly 
saying that doing this is good or bad practice.

In the example from the documentation, using an exclusion element works for the 
very moment, but as soon as the dependency slf4j-jdk14 is no longer needed, the 
project will break since slf4j-api is still required by slf4j-nop, but not 
included anymore.

A more reliable and sustainable solution would be to have declarations like the 
following:
 * If one dependency chain ends in org.slf4j:slf4j-api:1.6.1 and another ends 
in org.slf4j:slf4j-api:1.6.0, use version 1.6.1.

The general pattern is:
 * If one dependency chain ends in $coordinate1 and another ends in 
$coordinate2, use version $version.

Using this pattern instead of globally saying "don't use version 1.6.0" would 
not break the above scenario where slf4j-jdk14 is no longer needed. Even 
better, since during dependency resolution this particular conflict does not 
occur anymore, this rule can be flagged as being no longer necessary.

It should be possible to specify not only the last coordinate of a dependency 
chain but any elements, as in the following example:
 * If one dependency chain ends in org.slf4j:slf4j-jdk14:1.6.1, 
org.slf4j:slf4j-api:1.6.1 and another ends in org.slf4j:slf4j-nop:1.6.0, 
org.slf4j:slf4j-api:1.6.0, use version 1.6.1.

As it is now, the dependency convergence test encourages Maven users to specify 
overly general and therefore wrong exclusion rules. This should be avoided.

  was:
The [documentation for Dependency 
Convergence|https://maven.apache.org/enforcer/enforcer-rules/dependencyConvergence.html]
 describes how to suppress an error reported by the check. This description 
leads to unreliable project configurations.

In the example from the documentation, using an exclusion element works for the 
very moment, but as soon as the dependency slf4j-jdk14 is no longer needed, the 
project will break since slf4j-api is still required by slf4j-nop, but not 
included anymore.

A more reliable and sustainable solution would be to have declarations like the 
following:
 * If one dependency chain ends in org.slf4j:slf4j-api:1.6.1 and another ends 
in org.slf4j:slf4j-api:1.6.0, use version 1.6.1.

The general pattern is:
 * If one dependency chain ends in $coordinate1 and another ends in 
$coordinate2, use version $version.

Using this pattern instead of globally saying "don't use version 1.6.0" would 
not break the above scenario where slf4j-jdk14 is no longer needed. Even 
better, since during dependency resolution this particular conflict does not 
occur anymore, this rule can be flagged as being no longer necessary.

It should be possible to specify not only the last coordinate of a dependency 
chain but any elements, as in the following example:
 * If one dependency chain ends in org.slf4j:slf4j-jdk14:1.6.1, 
org.slf4j:slf4j-api:1.6.1 and another ends in org.slf4j:slf4j-nop:1.6.0, 
org.slf4j:slf4j-api:1.6.0, use version 1.6.1.

As it is now, the dependency convergence test encourages Maven users to specify 
overly general and therefore wrong exclusion rules. This should be avoided.


> Documentation suggests unreliable practice for dependency convergence
> -
>
> Key: MENFORCER-335
> URL: https://issues.apache.org/jira/browse/MENFORCER-335
> Project: Maven Enforcer Plugin
>  Issue Type: Bug
>  Components: Documentation
>Reporter: Roland Illig
>Priority: Major
>
> The [documentation for Dependency 
> Convergence|https://maven.apache.org/enforcer/enforcer-rules/dependencyConvergence.html]
>  describes how to suppress an error reported by the check. This description 
> leads to unreliable project configurations. It may or may not be intentional 
> that the documentation merely states "And this will succeed" without 
> explicitly saying that doing this is good or bad practice.
> In the example from the documentation, using an exclusion element works for 
> the very moment, but as soon as the dependency slf4j-jdk14 is no longer 
> needed, the project will break since slf4j-api is still required by 
> slf4j-nop, but not included anymore.
> A more reliable and sustainable solution would be to have declarations like 
> the following:
>  * If one dependency chain ends in org.slf4j:slf4j-api:1.6.1 and another ends 
> in org.slf4j:slf4j-api:1.6.0, use version 

[jira] [Updated] (MENFORCER-335) Documentation suggests unreliable practice for dependency convergence

2019-07-24 Thread Roland Illig (JIRA)


 [ 
https://issues.apache.org/jira/browse/MENFORCER-335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roland Illig updated MENFORCER-335:
---
Affects Version/s: 3.0.0-M2

> Documentation suggests unreliable practice for dependency convergence
> -
>
> Key: MENFORCER-335
> URL: https://issues.apache.org/jira/browse/MENFORCER-335
> Project: Maven Enforcer Plugin
>  Issue Type: Bug
>  Components: Documentation
>Affects Versions: 3.0.0-M2
>Reporter: Roland Illig
>Priority: Major
>
> The [documentation for Dependency 
> Convergence|https://maven.apache.org/enforcer/enforcer-rules/dependencyConvergence.html]
>  describes how to suppress an error reported by the check. This description 
> leads to unreliable project configurations. It may or may not be intentional 
> that the documentation merely states "And this will succeed" without 
> explicitly saying that doing this is good or bad practice.
> In the example from the documentation, using an exclusion element works for 
> the very moment, but as soon as the dependency slf4j-jdk14 is no longer 
> needed, the project will break since slf4j-api is still required by 
> slf4j-nop, but not included anymore.
> A more reliable and sustainable solution would be to have declarations like 
> the following:
>  * If one dependency chain ends in org.slf4j:slf4j-api:1.6.1 and another ends 
> in org.slf4j:slf4j-api:1.6.0, use version 1.6.1.
> The general pattern is:
>  * If one dependency chain ends in $coordinate1 and another ends in 
> $coordinate2, use version $version.
> Using this pattern instead of globally saying "don't use version 1.6.0" would 
> not break the above scenario where slf4j-jdk14 is no longer needed. Even 
> better, since during dependency resolution this particular conflict does not 
> occur anymore, this rule can be flagged as being no longer necessary.
> It should be possible to specify not only the last coordinate of a dependency 
> chain but any elements, as in the following example:
>  * If one dependency chain ends in org.slf4j:slf4j-jdk14:1.6.1, 
> org.slf4j:slf4j-api:1.6.1 and another ends in org.slf4j:slf4j-nop:1.6.0, 
> org.slf4j:slf4j-api:1.6.0, use version 1.6.1.
> As it is now, the dependency convergence test encourages Maven users to 
> specify overly general and therefore wrong exclusion rules. This should be 
> avoided.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)