@Robert @Stephan Thanks for clarifying! Of course it would be better to have a concise quickstart pom.xml but the necessary workarounds justify the current state.
On Thu, Jun 18, 2015 at 11:48 PM, Stephan Ewen <se...@apache.org> wrote: > I remember we had a similar discussion a while back. > > The current solution is the best out-of-the-box experience for the > quickstarts across Eclipse, IntelliJ, and command-line Maven. This is more > important that nice and compact POM files, IMHO. > > > > On Thu, Jun 18, 2015 at 11:26 AM, Robert Metzger <rmetz...@apache.org> > wrote: > > > Hi, > > > > I'm against cancelling a release for something that is not nice ;) It has > > to be at least broken to cancel :) > > > > I agree that the pom looks complicated and I would love to do it better, > > but in my opinion the current approach is giving our users the best out > of > > the box experience. > > > > The right approach of creating a Flink fat jar would be using the > > maven-shade-plugin with the Flink dependencies set to "provided". This > way > > we tell the shade plugin that it can assume the core flink code to be > > available. So there is no need to package those classes into the fat-jar. > > > > The problem is that IntelliJ is not adding "provided" classes into the > > classpath when importing the pom. So IntelliJ users will not be able to > run > > Flink jobs out of the IDE. > > > > That's why the Flink dependencies are in the default scope. > > The exclusions are in the maven-shade-plugin to reduce the jar size as > much > > as possible. > > > > But there is also a maven profile to set the Flink dependencies to > > provided, making the resulting jar as small as possible. > > > > By the way, it is not possible to just exclude everything from > > "org.apache.flink", because > > a) users sometimes put their code into that package, so we would exclude > > the code > > b) Libraries like Gelly of Flink ML are also in the "org.apache.flink" > > namespace but not provided on the server. > > > > There is an ongoing discussion in IntelliJ's issue tracker whether to > > change the behavior: https://youtrack.jetbrains.com/issue/IDEA-107048 > > > > > > Best, > > Robert > > > > On Thu, Jun 18, 2015 at 6:46 PM, Chiwan Park <chiwanp...@icloud.com> > > wrote: > > > > > Is it okay when the user runs the built jar in LocalEnvironment? (Just > > run > > > with `java -jar` command.) > > > I know that it is special case but it is a possible scenario for local > > > testing. > > > > > > If we change Quickstart POM to use provided scope for dependencies, we > > > should add a guide about this into document. > > > > > > Regards, > > > Chiwan Park > > > > > > > On Jun 19, 2015, at 12:53 AM, Aljoscha Krettek <aljos...@apache.org> > > > wrote: > > > > > > > > I'm also for simplification but let's hear what those who put the > > > build-jar > > > > profile there have to say about it.? > > > > > > > > On Thu, 18 Jun 2015 at 17:25 Ufuk Celebi <u...@apache.org> wrote: > > > > > > > >> > > > >> On 18 Jun 2015, at 16:58, Fabian Hueske <fhue...@gmail.com> wrote: > > > >> > > > >>> Why? > > > >>> > > > >>> mvn package > > > >>> > > > >>> builds the program correctly, no? > > > >> > > > >> Yes, but: > > > >> > > > >> - Dependencies not specified by the user may be included (Metrics, > > > >> javaassist) > > > >> - Dependencies specified by the user may be excluded > > > >> - If you use the build-jar profile you have to understand what the > > > >> difference to the default profile is and then you have to include > your > > > >> dependencies again for the profile > > > >> - The pom comments are confusing > > > > > > > > > > > > > > > > > >
