You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Kirk Lund <kl...@apache.org> on 2018/07/18 18:00:19 UTC
Moving from gradle to maven
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?
Re: Moving from gradle to maven
Posted by Jacob Barrett <jb...@pivotal.io>.
Well we are the practically the maintainers of the Gradle docker plugin...
;)
On Wed, Jul 18, 2018 at 1:50 PM Jens Deppe <jd...@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 <sg...@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 <jd...@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 <
> prhomberg@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 <ud...@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?
> > > > >>
> > > > >>
> > > > >
> > > >
> > >
> >
>
Re: Moving from gradle to maven
Posted by Jens Deppe <jd...@pivotal.io>.
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 <sg...@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 <jd...@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 <pr...@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 <ud...@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?
> > > >>
> > > >>
> > > >
> > >
> >
>
Re: Moving from gradle to maven
Posted by Sean Goller <sg...@pivotal.io>.
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 <jd...@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 <pr...@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 <ud...@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?
> > >>
> > >>
> > >
> >
>
Re: Moving from gradle to maven
Posted by Jens Deppe <jd...@pivotal.io>.
+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 <pr...@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 <ud...@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?
> >>
> >>
> >
>
Re: Moving from gradle to maven
Posted by Patrick Rhomberg <pr...@pivotal.io>.
+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 <ud...@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?
>>
>>
>
Re: Moving from gradle to maven
Posted by Udo Kohlmeyer <ud...@apache.org>.
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?
>