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

xample. 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 for bringing up this very old thread again: The Flink project is > > still using Maven 3.2.5 to have the

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

3.2 behaviour is currently viewed as a bug that has been abused by the > shade plugin rather than a feature. 3.3 enforces the immutability of the > model and I don't see that being rolled back > > On Thursday 10 December 2015, Robert Metzger <rmetz...@apache.org> wrote:

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

they are no longer transitive and that > way the effective reactor Pom is the same from a transitive dependency PoV > as the dependency reduced one that gets published > > On Thursday 10 December 2015, Robert Metzger <rmetz...@apache.org> wrote: > > > Hi, > > > &g

Build behavior differences between 3.2.5 and 3.3.9 with dependency shading

Hi, The Apache Flink project is using Maven for dependency management. We shade Google's Guava away (to org.apache.flink.shaded.com.google.commons) to avoid conflicts with user guava versions. Building Flink with Maven 3.2.5 will create a valid fat-jar without guava. However, Maven 3.3.9 (and

mvn -nsu (--no-snapshot-updates) is still downloading SNAPSHOT versions

Hi, At our project we recently had an issue where we accidentally included outdated artifacts (which were still available on snapshot repositories). To detect those issues in the future by our integration tests, I want to instruct maven not to download snapshot updates, using the -nsu command

Re: mvn -nsu (--no-snapshot-updates) is still downloading SNAPSHOT versions

happy in feeling that at any rate you have not wasted your time but have done your best ~~~ Lord Baden-Powell On Tue, May 26, 2015 at 11:18 AM, Robert Metzger rmetz...@apache.org wrote: Hi, At our project we recently had an issue where we accidentally included outdated artifacts (which

Re: Build fat jar transitively excluding some dependencies

=classname -Dexec.classpathScope=test) On Fri, Feb 27, 2015 at 1:13 AM, Robert Metzger rmetz...@apache.org wrote: Thank you for the replies. Martin: Will the maven-assemby-plugin also exclude transitive dependencies? Ben: Our users are used to run Flink programs out of the main() method, so

Re: Build fat jar transitively excluding some dependencies

to do testing via actual tests, rather than manual scripts. On Tue, Feb 24, 2015 at 4:53 AM, Robert Metzger rmetz...@apache.org wrote: Hi, I'm a committer at the Apache Flink project (a system for distrib. data processing). We provide our users a quickstart maven archetype to bootstrap

Build fat jar transitively excluding some dependencies

Hi, I'm a committer at the Apache Flink project (a system for distrib. data processing). We provide our users a quickstart maven archetype to bootstrap new Flink jobs. For the generated Flink job's maven project, I would like to build a fat-jar that contains all the dependencies the user added

Re: Change dependency version through property

Hi, thank you Ron and Jörg for the responses! Using the dependency management in the common parent pom resolved my problem! Thank you again, Robert On Fri, Nov 14, 2014 at 7:55 PM, Jörg Schaible joerg.schai...@gmx.de wrote: Hi Robert, Robert Metzger wrote: Hi, I'm a developer

Change dependency version through property

Hi, I'm a developer at the Apache Flink (incubating) project. I'm trying to pass the version of a dependency using a property from the command line to the binary build. But it seems that the version I've set is not respected everywhere. We have the following setup: - flink-parent -

archetype:integration-test generated archetype build depends on parent project

Hi, we use the archetype:integration-test to test if the archetypes we generate successfully compile. Our archetypes (we call them quickstart) are located within the main project. So we have - parent - core - runtime - clients - quickstart - quickstart-java - quickstart-scala as