On Mon, Apr 10, 2017 at 9:31 PM, Vincent Massol <[email protected]> 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
