On 11 Apr 2017, at 09:25, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
On Mon, Apr 10, 2017 at 9:31 PM, Vincent Massol <vincent(a)massol.net> 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
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