[
https://issues.apache.org/jira/browse/FLINK-9091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16487170#comment-16487170
]
Chesnay Schepler edited comment on FLINK-9091 at 5/23/18 12:39 PM:
-------------------------------------------------------------------
Alright, I finally understand _what_ is happening.
The problem has to do with what information the enforcer plugin relies on when
determining the dependency versions.
Let's use {{flink-orc}} as an example, which depends on {{flink-table}}, which
depends on 2 different janino versions.
If a cached artifact for flink-table exists in the local repository then the
enforcer will use this artifacts' pom to determine the dependencies.
Since this is a properly deployed artifact it uses the dependency-reduced pom
(i.e. the pom after removing shaded dependencies), which in the case of
flink-table means that it doesn't contain janino anymore.
Since the janino dependency is thus not visible the dependency convergence will
succeed.
On the other hand, if no cached artifact exists in the local repository when
executing {{mvn package/install}} the enforcer uses the dependency information
gathered during the current build, which is *not* dependency-reduced. This is
due to the immutability of the reactor build; all dependencies are fixed from
the start as far as maven is concerned (which is why one has to build
flink-dist separately with maven 3.3+).
This causes Janino to still be visible, causing the dependency convergence to
fail.
We observed the convergence failures on the website buildbot since it always
starts with a fresh repository.
The same applies when building an RC for the first time; since the version
changed no artifact exists in the local repository.
We could not reliably reproduce it locally since our caches are usually
populated with various SNAPSHOT artifacts.
You may be wondering how the dependency convergence can succeed for
{{flink-table}}, but fail for {{flink-orc}} due to dependencies of
{{flink-table}}.
The answer is MNG-5761. Essentially, the dependency management entries in
{{flink-table}} are ignored when the enforcer looks at {{flink-orc}}.
Unfortunately this _massive_ limitation is incredibly tedious to work around;
in fact this may actually be a reason to drop dependency convergence altogether.
We can partially cover this by moving dependency management entries to the root
{{pom.xml}} since these are never ignored. These cannot cover all dependencies
though, primarily shaded dependencies which frequently have a different version
than the rest of the project / other dependencies.
For the remaining dependencies we will have to resort to gratuitous use of
exclusions, which is the tedious part.
was (Author: zentol):
Alright, I finally understand _what_ is happening, but I don't quite know the
cause.
The problem has to do with what information the enforcer plugin relies on when
determining the dependency versions.
Let's use {{flink-orc}} as an example, which depends on {{flink-table}}, which
depends on 2 different janino versions.
If a cached artifact for flink-table exists in the local repository then the
enforcer will use this artifacts' pom to determine the dependencies.
Since this is a properly deployed artifact it uses the dependency-reduced pom
(i.e. the pom after removing shaded dependencies), which in the case of
flink-table means that it doesn't contain janino anymore.
Since the janino dependency is thus not visible the dependency convergence will
succeed.
On the other hand, if no cached artifact exists in the local repository when
executing {{mvn package/install}} the enforcer uses the dependency information
gathered during the current build, which is *not* dependency-reduced. This is
due to the immutability of the reactor build; all dependencies are fixed from
the start as far as maven is concerned (which is why one has to build
flink-dist separately with maven 3.3+).
This causes Janino to still be visible, causing the dependency convergence to
fail.
We observed the convergence failures on the website buildbot since it always
starts with a fresh repository.
The same applies when building an RC for the first time; since the version
changed no artifact exists in the local repository.
We could not reliably reproduce it locally since our caches are usually
populated with various SNAPSHOT artifacts.
You may be wondering how the dependency convergence can succeed for
{{flink-table}}, but fail for {{flink-orc}} due to dependencies of
{{flink-table}}.
The answer is MNG-5761. Essentially, the dependency management entries in
{{flink-table}} are ignored when the enforcer looks at {{flink-orc}}.
Unfortunately this _massive_ limitation is incredibly tedious to work around;
in fact this may actually be a reason to drop dependency convergence altogether.
We can partially cover this by moving dependency management entries to the root
{{pom.xml}} since these are never ignored. These cannot cover all dependencies
though, primarily shaded dependencies which frequently have a different version
than the rest of the project / other dependencies.
For the remaining dependencies we will have to resort to gratuitous use of
exclusions, which is the tedious part.
> Failure while enforcing releasability in building flink-json module
> -------------------------------------------------------------------
>
> Key: FLINK-9091
> URL: https://issues.apache.org/jira/browse/FLINK-9091
> Project: Flink
> Issue Type: Bug
> Components: Build System
> Reporter: Ted Yu
> Assignee: Hai Zhou
> Priority: Major
> Attachments: f-json.out
>
>
> Got the following when building flink-json module:
> {code}
> [WARNING] Rule 0: org.apache.maven.plugins.enforcer.DependencyConvergence
> failed with message:
> Failed while enforcing releasability. See above detailed error message.
> ...
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1:enforce
> (dependency-convergence) on project flink-json: Some Enforcer rules have
> failed. Look above for specific messages explaining why the rule failed. ->
> [Help 1]
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
