Well we are the practically the maintainers of the Gradle docker plugin...
;)
On Wed, Jul 18, 2018 at 1:50 PM Jens Deppe 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 updat
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
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-p
+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
+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 c
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
