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