Well we are the practically the maintainers of the Gradle docker plugin... ;)
On Wed, Jul 18, 2018 at 1:50 PM Jens Deppe <jde...@pivotal.io> wrote: > Right regarding the dockerized plugin - that was another pain point when we > moved to from 3.x to 4.x. We'll run into the same thing again with every > Gradle update when there is an API change. > > If we think it's worth moving to maven we should do a spike on producing a > dockerized test runner. > > --Jens > > On Wed, Jul 18, 2018 at 1:34 PM Sean Goller <sgol...@pivotal.io> wrote: > > > This is a non starter without a maven equivalent of the gradle dockerized > > plugin. Switching to maven without that will mean longer testing times, > > which I feel is unacceptable. > > > > So far I've found this reference on stack overflow ( > > > > > https://stackoverflow.com/questions/36808351/running-junit-tests-in-parallel-with-docker > > ) to a homebuilt solution, but I'm unsure how replicable it is. > > > > -Sean. > > > > On Wed, Jul 18, 2018 at 1:21 PM Jens Deppe <jde...@pivotal.io> wrote: > > > > > +1 For moving to maven. > > > > > > I think the blog Kirk linked hits all the relevant pain points. > > > > > > This is the third time we've done significant Gradle work and every > time > > it > > > is painful. It's also probably never going to get any better. > > > > > > For myself, Gradle certainly feels like a lot of magic happening under > > the > > > covers - it feels like it requires a fair bit of mental effort to > > > understand and distinguish configuration phases and execution phases > and > > > which parts fit into which phase. Maven has its own magic, but is > > > definitely more linear and obvious in it's execution steps. > > > > > > --Jens > > > > > > On Wed, Jul 18, 2018 at 12:27 PM Patrick Rhomberg < > prhomb...@pivotal.io> > > > wrote: > > > > > > > +1 to correcting our current broken gradle build. > > > > > > > > > > > > The fault, dear Brutus, is not in our [tools], but in ourselves. > > > > > > > > I think the root pain point is that our dependency tree is neither > > > explicit > > > > nor correct in several places. I have myself had frequent issues > > > > surrounding our Protobuf and OQLLexer classes requiring a > command-line > > > > build and re-import. It's also why, after we bumped gradle versions, > > we > > > > were prone to errors when building in parallel. > > > > > > > > Correctly documenting and making explicit the gradle build > dependencies > > > is > > > > something that I am meaning to look into soon, but I am currently > > looking > > > > into improving our pipelines and metrics scripting. > > > > > > > > On Wed, Jul 18, 2018 at 12:04 PM, Udo Kohlmeyer <u...@apache.org> > > wrote: > > > > > > > > > I must agree, the fact that IntelliJ cannot handle the current > > project > > > > > structure, is that I believe that we have a complicated project > > > > structure. > > > > > Moving to maven would force a more strict project structure. > > > > > > > > > > I don't mind moving to maven, but I believe that we would have > > similar > > > > > experiences with maven and a complex project structure. I was > > thinking > > > > > would could move to Gradle-Kotlin DSL, but that also would not > solve > > > the > > > > > current structure problem. > > > > > > > > > > So... +1 on move to maven OR +1 on refactoring to the current > gradle > > > > > setup to be less "custom" and maybe a little more rigid. > > > > > > > > > > > > > > > On 7/18/18 11:00, Kirk Lund wrote: > > > > > > > > > >> Gradle appears to not play well with IntelliJ unless the project > is > > > > overly > > > > >> simple. I don't want to spend my days fighting with tools that > don't > > > > work > > > > >> well together. > > > > >> > > > > >> Here's an interesting blog article about moving from gradle to > > maven: > > > > >> > > > > >> https://blog.philipphauer.de/moving-back-from-gradle-to-maven/ > > > > >> > > > > >> Any other data points or opinions about moving from gradle to > maven? > > > > >> > > > > >> > > > > > > > > > > > > > > >
