Quantcast

[Brainstorming] Gradle exploration?

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[Brainstorming] Gradle exploration?

vmassol
Administrator
BTW I think we’ll need to think about exploring gradle in not too long.

Maven continues to stagnate while gradle is moving fast ahead.

One important feature of gradle is performance (see also https://blog.gradle.org/introducing-gradle-build-cache and https://blog.gradle.org/incremental-compiler-avoidance). Apparently it beats maven easily and that coud make things much nicer for us. The worrying point for me is the ability to find existing gradle plugins to replace the maven ones that we use.

What we could do is to commit the start of a gradle build in our SCM (starting with xwiki-commons) as a way to explore Gradle and see what’s missing compared to our current maven build. In other words, it would be a way to slowly start to learn Gradle.

WDYT?

Thanks
-Vincent

PS1: FTR I did my first gradle build at https://github.com/xwiki-contrib/docker-xwiki/blob/master/build.gradle
PS2: I’m worried about the smaller reliance on conventions in gradle than in Maven (as you can see from https://github.com/xwiki-contrib/docker-xwiki/blob/master/build.gradle, it doesn’t use any fixed structure and we’ll need plenty of best practices, it really reminds me of Ant…).

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Brainstorming] Gradle exploration?

Thomas Mortagne
Administrator
On Mon, Apr 10, 2017 at 9:31 PM, Vincent Massol <[hidden email]> wrote:
> BTW I think we’ll need to think about exploring gradle in not too long.
>
> Maven continues to stagnate while gradle is moving fast ahead.
>
> One important feature of gradle is performance (see also https://blog.gradle.org/introducing-gradle-build-cache and https://blog.gradle.org/incremental-compiler-avoidance). Apparently it beats maven easily and that coud make things much nicer for us. The worrying point for me is the ability to find existing gradle plugins to replace the maven ones that we use.
>
> What we could do is to commit the start of a gradle build in our SCM (starting with xwiki-commons) as a way to explore Gradle and see what’s missing compared to our current maven build. In other words, it would be a way to slowly start to learn Gradle.

Not really sure what you mean exactly. Create a Gradle based branch in
xwiki-commons and a dedicated Jenkins job ?

>
> WDYT?
>
> Thanks
> -Vincent
>

> PS1: FTR I did my first gradle build at https://github.com/xwiki-contrib/docker-xwiki/blob/master/build.gradle

About that, you should probably setup gradlew. See
https://docs.gradle.org/current/userguide/gradle_wrapper.html and
example on https://github.com/xwiki-contrib/android-authenticator.

> PS2: I’m worried about the smaller reliance on conventions in gradle than in Maven (as you can see from https://github.com/xwiki-contrib/docker-xwiki/blob/master/build.gradle, it doesn’t use any fixed structure and we’ll need plenty of best practices, it really reminds me of Ant…).
>



--
Thomas Mortagne
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Brainstorming] Gradle exploration?

vmassol
Administrator

> On 11 Apr 2017, at 09:25, Thomas Mortagne <[hidden email]> wrote:
>
> On Mon, Apr 10, 2017 at 9:31 PM, Vincent Massol <[hidden email]> wrote:
>> BTW I think we’ll need to think about exploring gradle in not too long.
>>
>> Maven continues to stagnate while gradle is moving fast ahead.
>>
>> One important feature of gradle is performance (see also https://blog.gradle.org/introducing-gradle-build-cache and https://blog.gradle.org/incremental-compiler-avoidance). Apparently it beats maven easily and that coud make things much nicer for us. The worrying point for me is the ability to find existing gradle plugins to replace the maven ones that we use.
>>
>> What we could do is to commit the start of a gradle build in our SCM (starting with xwiki-commons) as a way to explore Gradle and see what’s missing compared to our current maven build. In other words, it would be a way to slowly start to learn Gradle.
>
> Not really sure what you mean exactly. Create a Gradle based branch in
> xwiki-commons and a dedicated Jenkins job ?

No, I meant to commit it in master, next to the pom.xml file (it’s called build.gradle) with a warning in the file explaining it’s experimental and that the Maven should be used for the full-fledged build.

IMO it wouldn’t be visible enough in a branch and would require too much merging. And IMO it’s not a big issue if it’s not fully working yet provided there’s some explanation about the state in the file itself or output when you run it.

Thanks
-Vincent

> WDYT?
>>
>> Thanks
>> -Vincent
>>
>
>> PS1: FTR I did my first gradle build at https://github.com/xwiki-contrib/docker-xwiki/blob/master/build.gradle
>
> About that, you should probably setup gradlew. See
> https://docs.gradle.org/current/userguide/gradle_wrapper.html and
> example on https://github.com/xwiki-contrib/android-authenticator.
>
>> PS2: I’m worried about the smaller reliance on conventions in gradle than in Maven (as you can see from https://github.com/xwiki-contrib/docker-xwiki/blob/master/build.gradle, it doesn’t use any fixed structure and we’ll need plenty of best practices, it really reminds me of Ant…).
>>
>
>
>
> --
> Thomas Mortagne

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Brainstorming] Gradle exploration?

Marius Dumitru Florea
On Tue, Apr 11, 2017 at 8:05 PM, Vincent Massol <[hidden email]> wrote:

>
> > On 11 Apr 2017, at 09:25, Thomas Mortagne <[hidden email]>
> wrote:
> >
> > On Mon, Apr 10, 2017 at 9:31 PM, Vincent Massol <[hidden email]>
> wrote:
> >> BTW I think we’ll need to think about exploring gradle in not too long.
> >>
> >> Maven continues to stagnate while gradle is moving fast ahead.
> >>
> >> One important feature of gradle is performance (see also
> https://blog.gradle.org/introducing-gradle-build-cache and
> https://blog.gradle.org/incremental-compiler-avoidance). Apparently it
> beats maven easily and that coud make things much nicer for us. The
> worrying point for me is the ability to find existing gradle plugins to
> replace the maven ones that we use.
> >>
> >> What we could do is to commit the start of a gradle build in our SCM
> (starting with xwiki-commons) as a way to explore Gradle and see what’s
> missing compared to our current maven build. In other words, it would be a
> way to slowly start to learn Gradle.
> >
> > Not really sure what you mean exactly. Create a Gradle based branch in
> > xwiki-commons and a dedicated Jenkins job ?
>
> No, I meant to commit it in master, next to the pom.xml file (it’s called
> build.gradle) with a warning in the file explaining it’s experimental and
> that the Maven should be used for the full-fledged build.
>
> IMO it wouldn’t be visible enough in a branch and would require too much
> merging. And IMO it’s not a big issue if it’s not fully working yet
> provided there’s some explanation about the state in the file itself or
> output when you run it.
>

+1 to do it on master. We could also try it on some of the contrib
extensions we support (like CKEditor), but we need a replacement for the
XAR maven plugin, right?

Thanks,
Marius


>
> Thanks
> -Vincent
>
> > WDYT?
> >>
> >> Thanks
> >> -Vincent
> >>
> >
> >> PS1: FTR I did my first gradle build at https://github.com/xwiki-
> contrib/docker-xwiki/blob/master/build.gradle
> >
> > About that, you should probably setup gradlew. See
> > https://docs.gradle.org/current/userguide/gradle_wrapper.html and
> > example on https://github.com/xwiki-contrib/android-authenticator.
> >
> >> PS2: I’m worried about the smaller reliance on conventions in gradle
> than in Maven (as you can see from https://github.com/xwiki-
> contrib/docker-xwiki/blob/master/build.gradle, it doesn’t use any fixed
> structure and we’ll need plenty of best practices, it really reminds me of
> Ant…).
> >>
> >
> >
> >
> > --
> > Thomas Mortagne
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Brainstorming] Gradle exploration?

Thomas Mortagne
Administrator
On Wed, Apr 12, 2017 at 9:45 AM, Marius Dumitru Florea
<[hidden email]> wrote:

> On Tue, Apr 11, 2017 at 8:05 PM, Vincent Massol <[hidden email]> wrote:
>
>>
>> > On 11 Apr 2017, at 09:25, Thomas Mortagne <[hidden email]>
>> wrote:
>> >
>> > On Mon, Apr 10, 2017 at 9:31 PM, Vincent Massol <[hidden email]>
>> wrote:
>> >> BTW I think we’ll need to think about exploring gradle in not too long.
>> >>
>> >> Maven continues to stagnate while gradle is moving fast ahead.
>> >>
>> >> One important feature of gradle is performance (see also
>> https://blog.gradle.org/introducing-gradle-build-cache and
>> https://blog.gradle.org/incremental-compiler-avoidance). Apparently it
>> beats maven easily and that coud make things much nicer for us. The
>> worrying point for me is the ability to find existing gradle plugins to
>> replace the maven ones that we use.
>> >>
>> >> What we could do is to commit the start of a gradle build in our SCM
>> (starting with xwiki-commons) as a way to explore Gradle and see what’s
>> missing compared to our current maven build. In other words, it would be a
>> way to slowly start to learn Gradle.
>> >
>> > Not really sure what you mean exactly. Create a Gradle based branch in
>> > xwiki-commons and a dedicated Jenkins job ?
>>
>> No, I meant to commit it in master, next to the pom.xml file (it’s called
>> build.gradle) with a warning in the file explaining it’s experimental and
>> that the Maven should be used for the full-fledged build.
>>
>> IMO it wouldn’t be visible enough in a branch and would require too much
>> merging. And IMO it’s not a big issue if it’s not fully working yet
>> provided there’s some explanation about the state in the file itself or
>> output when you run it.
>>
>
> +1 to do it on master. We could also try it on some of the contrib
> extensions we support (like CKEditor), but we need a replacement for the
> XAR maven plugin, right?

We need replacement for many plugins :)

>
> Thanks,
> Marius
>
>
>>
>> Thanks
>> -Vincent
>>
>> > WDYT?
>> >>
>> >> Thanks
>> >> -Vincent
>> >>
>> >
>> >> PS1: FTR I did my first gradle build at https://github.com/xwiki-
>> contrib/docker-xwiki/blob/master/build.gradle
>> >
>> > About that, you should probably setup gradlew. See
>> > https://docs.gradle.org/current/userguide/gradle_wrapper.html and
>> > example on https://github.com/xwiki-contrib/android-authenticator.
>> >
>> >> PS2: I’m worried about the smaller reliance on conventions in gradle
>> than in Maven (as you can see from https://github.com/xwiki-
>> contrib/docker-xwiki/blob/master/build.gradle, it doesn’t use any fixed
>> structure and we’ll need plenty of best practices, it really reminds me of
>> Ant…).
>> >>
>> >
>> >
>> >
>> > --
>> > Thomas Mortagne
>>
>>



--
Thomas Mortagne
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Brainstorming] Gradle exploration?

vmassol
Administrator
In reply to this post by vmassol
FWIW, I’ve done a first commit at https://github.com/xwiki/xwiki-commons/commit/de3b11c575720c34c32a9f16fe84e9e0b491e108

I’m still unsure whether we should do this in master or not.

One issue is going to be the maintenance of dependencies between the Maven build and the Gradle build. Thus I think it might be better to move the gradle stuff into a branch and perform a move/rewrite the day we’re ready to switch.

WDYT?

Thanks
-Vincent

PS: If you’re curious here are some typical Gradle builds:
* https://github.com/hibernate/hibernate-orm/blob/master/build.gradle
* https://github.com/mockito/mockito/blob/release/2.x/build.gradle
* https://github.com/spring-projects/spring-framework/blob/master/build.gradle
* https://github.com/groovy/groovy-core/blob/master/build.gradle

> On 10 Apr 2017, at 21:31, Vincent Massol <[hidden email]> wrote:
>
> BTW I think we’ll need to think about exploring gradle in not too long.
>
> Maven continues to stagnate while gradle is moving fast ahead.
>
> One important feature of gradle is performance (see also https://blog.gradle.org/introducing-gradle-build-cache and https://blog.gradle.org/incremental-compiler-avoidance). Apparently it beats maven easily and that coud make things much nicer for us. The worrying point for me is the ability to find existing gradle plugins to replace the maven ones that we use.
>
> What we could do is to commit the start of a gradle build in our SCM (starting with xwiki-commons) as a way to explore Gradle and see what’s missing compared to our current maven build. In other words, it would be a way to slowly start to learn Gradle.
>
> WDYT?
>
> Thanks
> -Vincent
>
> PS1: FTR I did my first gradle build at https://github.com/xwiki-contrib/docker-xwiki/blob/master/build.gradle
> PS2: I’m worried about the smaller reliance on conventions in gradle than in Maven (as you can see from https://github.com/xwiki-contrib/docker-xwiki/blob/master/build.gradle, it doesn’t use any fixed structure and we’ll need plenty of best practices, it really reminds me of Ant…).

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Brainstorming] Gradle exploration?

vmassol
Administrator
First feelings:

Pros:
* Feels fast
* Powerful (you can do anything with it)

Cons:
* I don’t like it much
* Gradle is very hackish
* You need lots of best practices for someone else to be able to read your gradle build (what maven fixed from Ant)
* I don’t like the settings.gradle file and the fact that you have to declare all your modules in it

Thanks
-Vincent

> On 12 Apr 2017, at 17:49, Vincent Massol <[hidden email]> wrote:
>
> FWIW, I’ve done a first commit at https://github.com/xwiki/xwiki-commons/commit/de3b11c575720c34c32a9f16fe84e9e0b491e108
>
> I’m still unsure whether we should do this in master or not.
>
> One issue is going to be the maintenance of dependencies between the Maven build and the Gradle build. Thus I think it might be better to move the gradle stuff into a branch and perform a move/rewrite the day we’re ready to switch.
>
> WDYT?
>
> Thanks
> -Vincent
>
> PS: If you’re curious here are some typical Gradle builds:
> * https://github.com/hibernate/hibernate-orm/blob/master/build.gradle
> * https://github.com/mockito/mockito/blob/release/2.x/build.gradle
> * https://github.com/spring-projects/spring-framework/blob/master/build.gradle
> * https://github.com/groovy/groovy-core/blob/master/build.gradle
>
>> On 10 Apr 2017, at 21:31, Vincent Massol <[hidden email]> wrote:
>>
>> BTW I think we’ll need to think about exploring gradle in not too long.
>>
>> Maven continues to stagnate while gradle is moving fast ahead.
>>
>> One important feature of gradle is performance (see also https://blog.gradle.org/introducing-gradle-build-cache and https://blog.gradle.org/incremental-compiler-avoidance). Apparently it beats maven easily and that coud make things much nicer for us. The worrying point for me is the ability to find existing gradle plugins to replace the maven ones that we use.
>>
>> What we could do is to commit the start of a gradle build in our SCM (starting with xwiki-commons) as a way to explore Gradle and see what’s missing compared to our current maven build. In other words, it would be a way to slowly start to learn Gradle.
>>
>> WDYT?
>>
>> Thanks
>> -Vincent
>>
>> PS1: FTR I did my first gradle build at https://github.com/xwiki-contrib/docker-xwiki/blob/master/build.gradle
>> PS2: I’m worried about the smaller reliance on conventions in gradle than in Maven (as you can see from https://github.com/xwiki-contrib/docker-xwiki/blob/master/build.gradle, it doesn’t use any fixed structure and we’ll need plenty of best practices, it really reminds me of Ant…).
>

Loading...