[
https://issues.apache.org/jira/browse/FLINK-8193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16278398#comment-16278398
]
ASF GitHub Bot commented on FLINK-8193:
---------------------------------------
Github user StephanEwen commented on the issue:
https://github.com/apache/flink/pull/5118
I am unsure here. The warning is nice, but without some exclusions from the
shading phase, we will have many users wich build gigantic jars (happens to me
as well sometimes). Duplicating dependencies into the user jar is more
dangerous now that it used to be, given that we have the inverted classloading
on as a default. We saw that with Avro, and probably have similar issues with
Kryo and custom serializers as well, if they end up both in app classpath and
in the user jar.
I know its harder to maintain, but in this case I think that immediate user
experience trumps maintenance effort, so I would vote to add the exclusions
back. The exclusions set should be much smaller now that we don't have Hadoop
as a dependency here anymore. Having at least the flink projects (and
flink-shaded projects) as exclusions, as well as scala / akka / kryo should
really help.
We can use wildcard exclusions to make it more future safe, like replacing
scala version with `*` (`<exclude>org.apache.flink:flink-runtime*</exclude>`)
and excluding all artifacts for a group, like
`<exclude>org.scala-lang:*</exclude>` and `<exclude>akka:*</exclude>`.
> Rework quickstart exclusions
> ----------------------------
>
> Key: FLINK-8193
> URL: https://issues.apache.org/jira/browse/FLINK-8193
> Project: Flink
> Issue Type: Improvement
> Components: Build System, Quickstarts
> Affects Versions: 1.4.0
> Reporter: Chesnay Schepler
> Assignee: Chesnay Schepler
>
> The quickstart poms currently contain 2 entirely separate dependency
> exclusion mechanisms:
> A) manual exclusions of dependencies (including transitive dependencies) via
> the {{artifactSet}} of the {{maven-shade-plugin}}
> B) automatic inclusion by marking dependencies as {{<provided>}} with the
> {{build-jar}} profile
> I propose removing A) entirely. By default, all dependencies will be included
> in the jar to allow execution in the IDE (which setting all dependencies to
> provided would not). To execute things on a cluster we now always refer to
> Option B), which is trivial to maintain and also reliable.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
