maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <stephen.alan.conno...@gmail.com>
Subject Re: Build behavior differences between 3.2.5 and 3.3.9 with dependency shading
Date Sun, 06 Nov 2016 21:48:58 GMT
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 flag and it would stop the transitive
dependencies being propagated... but most people do not shade *all*
dependencies, rather they shade a subset.

I think we may need to re-think how we do this or rethink the model being
read-only

On 11 December 2015 at 08:27, Robert Metzger <rmetzger@apache.org> wrote:

> 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 me guava anywhere, so
> its really hard to figure out where the jars are coming from.
>
>
> For completeness, I'll link to the initial discussion about this issue on
> the Flink mailing list:
> http://mail-archives.apache.org/mod_mbox/flink-dev/201512.
> mbox/%3CCANZa%3DGvFA%2B61968DBYoZc%3D8WfEmoF01DJAkmvzUcUH5XycLQ5w
> %40mail.gmail.com%3E
>
>
> On Thu, Dec 10, 2015 at 5:01 PM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
> > 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 agree with my suggestion of
> > limited ability to modify the model after the reactor has been
> constructed)
> >
> > The 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 <rmetzger@apache.org>
> wrote:
> >
> > > Okay, the <optional>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
> <optional>,
> > > we end up with guava in our final fat jar for users building with 3.3.
> > > Putting guava with optional=true into our dependency management is not
> an
> > > option because that would overwrite Hadoop's guava version (we shade
> > hadoop
> > > and its guava in our project as well)
> > >
> > >
> > >
> > > On Thu, Dec 10, 2015 at 2:08 PM, Stephen Connolly <
> > > stephen.alan.connolly@gmail.com <javascript:;>> wrote:
> > >
> > > > 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
> > > > <optional>true</optional> so that 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 <rmetzger@apache.org
> > > <javascript:;>> wrote:
> > > >
> > > > > 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 other 3.3.x versions) are including guava
> > in
> > > > the
> > > > > com/google/commons namespace.
> > > > > Interestingly, doing only a "clean install" in the "flink-dist"
> > package
> > > > > after a build of the parent pom results in a correct "flink-dist"
> fat
> > > > jar.
> > > > >
> > > > > I'm wondering which behavior of Maven is correct 3.2 or 3.3 ?
> > > > > I have the feeling that 3.3 is behaving incorrectly because the
> > > > > dependency:tree of "flink-dist" does not contain Guava.
> > > > > Maybe a "clean install" on the parent pom with Maven 3.3 is not
> > > > respecting
> > > > > the dependency-reduced poms created by the other modules?
> > > > >
> > > > > Regards,
> > > > > Robert
> > > > >
> > > >
> > > >
> > > > --
> > > > Sent from my phone
> > > >
> > >
> >
> >
> > --
> > Sent from my phone
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message