Re: Build behavior differences between 3.2.5 and 3.3.9 with dependency shading

Hi Stephen, Thanks for the offer, I'll try to make sure we return the favor. Building the current Flink master with a current maven version (3.6.3 on my machine), leads to the distribution (in flink/build-target/lib/flink-dist_2.11-1.12-SNAPSHOT.jar) containing "org/jboss/netty/util" classes.

Re: Build behavior differences between 3.2.5 and 3.3.9 with dependency shading

You can make Maven do the right thing if you scope the shades dependencies correctly... but it’s a pain. Can you point me to one pom that’s a good example. I might be able to give some pointers in return for a bugfix :rofl: On Fri 3 Jul 2020 at 09:10, Robert Metzger wrote: > Hi all, > > sorry

Re: Build behavior differences between 3.2.5 and 3.3.9 with dependency shading

Hi all, sorry for bringing up this very old thread again: The Flink project is still using Maven 3.2.5 to have the shading behave as we need it. Using such an old Maven version has some issues in our development workflow, as the http library is quite outdated, and developers are working with much

Re: Build behavior differences between 3.2.5 and 3.3.9 with dependency shading

yes that was the advice I gave on this thread originally. you do have to fight a bit with the shade plugin to get them shaded in though... which is why I think we may need to rethink how we do shade On 6 November 2016 at 22:36, Jörg Schaible wrote: > Stephen Connolly

Re: Build behavior differences between 3.2.5 and 3.3.9 with dependency shading

Stephen Connolly wrote: > Hmmm I did some digging... > > https://maven.apache.org/ref/3.2.3/apidocs/org/apache/maven/artifact/handler/ArtifactHandler.html#isIncludesDependencies() > is i think the idea JvZ was hinting at. > > For the case where a shaded JAR shades *everything* then a custom >

Re: Build behavior differences between 3.2.5 and 3.3.9 with dependency shading

Hmmm I did some digging... https://maven.apache.org/ref/3.2.3/apidocs/org/apache/maven/artifact/handler/ArtifactHandler.html#isIncludesDependencies() is i think the idea JvZ was hinting at. For the case where a shaded JAR shades *everything* then a custom packaging will work as we could set this

Re: Build behavior differences between 3.2.5 and 3.3.9 with dependency shading

Thank you for the information. I've changed now all our Guava dependencies to optional, but it is still contained in the first build of the parent-pom. This is the repository https://github.com/rmetzger/flink/tree/flink3158 ("flink3158" branch). The dependency:tree of "flink-dist" is not showing

Re: Build behavior differences between 3.2.5 and 3.3.9 with dependency shading

Dependency reduced poms require mutation of the model after the build started. JvZ is investigating a different packaging type to resolve this... Workaround for now is to mark all the dependencies that are removed as true so that they are no longer transitive and that way the effective reactor Pom

Re: Build behavior differences between 3.2.5 and 3.3.9 with dependency shading

Okay, the true suggestion sounds interesting. I'll try that out. However, I'm still wondering why the behavior between 3.2 and 3.3 is different? Our CI system runs Maven 3.2, so the shading is done correctly there. If a project committer now adds a guava dependency and forgets the , we end up

Re: Build behavior differences between 3.2.5 and 3.3.9 with dependency shading

You need to do this in any module that is producing a dependency reduced pom (and only in those modules) You can leave the version being inherited from dependencyManagement. I advise using the optional technique until Jason gets a new packaging for dependency reduced artifacts (or decides to