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? > > > >> > > > >> > > > > > > > > > >
