Problème

Un plugin Maven qui ne rebuild qu'en cas de changement.

Le chemin est affecté à la propriété ${maven.multiModuleProjectDirectory} à la condition qu'à côté du pom.xml racine se trouve un dossier .mvn/ même s'il est vide !

Attention, Java 6 n'étant plus supportée les dépendances kotlin-stdlib-jdk7 et kotlin-stdlib-jdk8 n'existent plus (puisque c'est Java 8 la version minimale requise pour Kotlin à présent).

Il faut donc les remplacer par kotlin-stdlib. Une migration simple qui va poser de nombreux problèmes à certains, sans aucun doute.

Ceci se fait en deux étapes :

1) Déclarer la property dans le plugin Surefire comme suit

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>LAST_SUREFIRE_VERSION</version>
    <configuration>
        <systemProperties>
            <property>
                <name>name-the-property-will-have-in-test</name>
                <value>${my-property}</value>
            </property>
        </systemProperties>
    </configuration>
</plugin>

2) La récupérer en tant que propriété système dans les TU

val property = System.getProperty("name-the-property-will-have-in-test")

Je me le note pour plus tard, comment ne copier que les dépendances en scope "compile" via le maven-dependency-plugin :

mvn dependency:copy-dependencies -DincludeScope=compile

Excellente idée ! Merci à @Philou pour le lien.

La polygot maven extension permet de produit des pom en Yaml (j'avais fait un tuto ici en son temps) et maintenant en Kotlin. Vous savez que j'adore Kotlin et pourtant je vois dans cette opportunité une immondice sans nom pour ne pas dire la plus grande des saloperies !

Pourquoi ?
Parce que le DSL Kotlin permet de coder dans le pom dont le but est qu'il soit pourtant 100 % déclaratif. Car du code dans un pom n'aura jamais de TU, a un probabilité très haute de ne pas être portable et surtout, chaque évolution du code ne profitera ni à la communauté (car pas de plugin) et deviendra un risque pour l'entreprise qui va accentuer l'effet "copier-coller".

Non vraiment, si c'était pour faire de Maven la même horreur de maintenance que l'est Gradle, mais les performances en moins, je pense qu'il valait mieux s'abstenir.

Voici l'exemple qui m'a fait vomir deux fois (vous saurez apprécier le code à copier-coller dans chaque projet d'entreprise en début de pom n'est-ce pas ?) :

import java.io.File

// define a comparable data class to simplify handling versions
data class Version(val major: Int, val minor: Int, val patch: Int) : Comparable<Version> {
    override fun compareTo(other: Version): Int =
            compareValuesBy(this, other, Version::major, Version::minor, Version::patch)

    override fun toString(): String = "$major.$minor.$patch"
}

// define a function to execute the git command and return its standard output
fun git(vararg args: String): String {
    // use the basedir of the project as the command's working dir if it contains a '.git' subdir
    // otherwise use the current working directory of this script if it contains a '.git' subdir
    // if both conditions are false the result will be null; the git command will probably fail
    val workingDir = basedir.takeIf { it.resolve(".git").exists() }
            ?: File(".").takeIf { it.resolve(".git").exists() }
    // run the git command with the provided arguments
    val process = ProcessBuilder()
            .directory(workingDir)
            .redirectErrorStream(true)
            .command(listOf("git") + args)
            .start()
    // read the standard output completely as a String
    val output = process.inputStream.bufferedReader().readText().trim()
    // return the output if the exit value is 0 or throw an exception otherwise
    if (process.waitFor() == 0) return output
    else throw IllegalStateException(output)
}

val gitVersions by lazy {
    // run the `git tag` command
    git("tag")
            // the returned list of tags is separated by newlines
            .split("\n")
            // filter out only tags that are versions (such as 1.231.15)
            .filter { it.matches(Regex("[0-9]+\\.[0-9]+\\.[0-9]")) }
            // the separate parts of each version are separated by dots,
            // also parse each part as an int
            .map { it.split('.').map { it.toInt() } }
            // map each triple of numbers to an instance of the `Version` class
            .map { (major, minor, patch) -> Version(major, minor, patch) }
            // sort the list of versions
            .sorted()
}

// the last release is always the tag with the highest version number
val lastRelease by lazy {
    gitVersions.max()
}

// the next version is determined based on the git commit log
val nextVersion by lazy {
    // use the lsat released version as the base
    val baseVersion = lastRelease
    // if there are no releases yet, we use the version 0.0.1
    if (baseVersion == null) Version(0, 0, 1)
    else {
        // split the base version in each separate part using destructuring
        val (major, minor, patch) = baseVersion
        // create a separator to split each log message on (log messages are multiline)
        val separator = "-".repeat(5) + "commit" + "-".repeat(5)
        // get all log messages from the last release tag until the current HEAD
        // for each commit the separator is printed + the full commit message
        val logMessages = git("log", "--pretty=format:$separator%n%B", "$baseVersion..HEAD")
                // split the output on each separator generated earlier
                .split(separator)
                // trim each message, removing excess newlines
                .map { it.trim() }
                // only keep non-empty messages
                .filter { it.isNotEmpty() }
        when {
            // increment the major and reset the minor + patch if any 
            // message contains the words 'BREAKING CHANGE'
            logMessages.any { it.contains("BREAKING CHANGE") } -> Version(major + 1, 0, 0)
            // increment the minor and reset the patch if any message starts with 'feat'
            logMessages.any { it.startsWith("feat") } -> Version(major, minor + 1, 0)
            // increment the patch in all other cases
            else -> Version(major, minor, patch + 1)
        }
    }
}

project {

    // use the next version calculated above when defining our project id
    id("nl.craftsmen.blog.kotlin:kotlin-rest-service:${nextVersion}")

    dependencies {
        compile("org.glassfish.jersey.inject:jersey-hk2:2.29")
        compile("org.glassfish.jersey.containers:jersey-container-netty-http:2.29")
        compile("org.glassfish.jersey.media:jersey-media-json-jackson:2.29")

        runtime("ch.qos.logback:logback-classic:1.2.3")
    }

    properties {
        "project.build.sourceEncoding" to "UTF-8"
        "maven.compiler.source" to "11"
        "maven.compiler.target" to "11"
    }

    distributionManagement {
        repository("local") {
            url(basedir.resolve("repo").toURI().toASCIIString())
        }
    }

    build {
        execute(id = "release", phase = "deploy") {
            // create a new tag using the next version calculated above
            git("tag", "-am", "Release $nextVersion", "$nextVersion")
            // print some output
            println("Tagged current HEAD as $nextVersion")
        }
    }
}

Encore une très bonne nouvelle pour Kotlin ! Le fait d'avoir une fondation à part, disposant d'un modèle économique clair et qui assure au langage sa survit et mieux encore son évolution est ce qu'il fallait faire.

Le parfait contre-exemple que je pourrais donner est ce qu'a fait la fondation Apache avec Maven dans le sens où Apache étant "anti-argent", la fondation a toujours refusé que des contributeurs majeurs de Maven mettent en place un modèle économique de financement de leurs contributions. 15 ans plus tard, le projet n'a qu'une mise à jour tous les 18 mois... Heureusement, des forks sont apparus comme Maven Daemon mais cela fragmente le marché.

Bref, je suis très contente pour Kotlin.

Ça doit faire 4-5 ans que je me remets régulièrement à Gradle dans l'espoir de trouver une solution à un problème pourtant trivial : comment, avec Gradle, mutualiser un processus de build qui doit s'appliquer sur plusieurs projets qui n'ont rien à voir ?

Gradle confond la notion de projets et de modules, donc je dois clarifier ces deux définitions pour la suite :

• Un module, c'est ce qui va produire un jar au sein de votre projet Git et votre projet est composé de modules.
• Donc yn projet, c'est un répo Git et qui en général va produire une application et les modules la composent.

Dans toutes les docs de Gradle, un projet est un module, donc pas besoin d'héritage puisque le build.gradle à la racine va injecter sa conf dans les build.gradle des modules positionnés dans les sous-répertoires.

Sauf que ce genre de bidouilles, ça marche bien dans une startup ne concevant qu'un seul produit, mais imaginez que vous deviez proposer un socle de build gérant Java, Kotlin, Groovy et Scala et qui soit utilisé par 2000 personnes, sur plus de 100 applications et 200 libs, comment faites-vous avec Gradle ?

Permettez-moi de détailler, le processus de build standard inclut :

• La compilation en mode dev (sans optim) et en mode prod (avec optim).
• Les analyses de sécurité.
• Les analyses de code.
• La signature des jars.
• La production des jars des docs et des sources.
• Les analyses des dépendances.
• Etc.

Tout ce processus qui est agnostique du code lui-même DOIT être factorisé pour devenir un standard de l'entreprise et se pose en tant que quality-gate/build-breaker en cas de manquement.

Avec Maven facile, il suffit que le pom parent de votre projet hérite du pom sachant faire tout ça, mais comment faire avec Gradle ? Ce build.gradle "commun" ne peut pas être hérité car Gradle ne permet pas l'héritage et il ne peut pas lancer lui-même le build des 300 répos dont les produits ont des cycles de vie totalement indépendants.

C'est une vraie question car j'aimerai vraiment abandonner Maven (puisqu'il est beaucoup trop lent) au profit de Gradle, mais sans la capacité de mutualiser le processus de build entre deux projets indépendants, cela fait de Gradle un outil pour "amateurs", or sa percée sur le marché me pousse à croire qu'il doit bien exister une astuce mais que je n'ai encore jamais vue. Bref si quelqu'un a l'info...

Pour citer l'article.

mvn versions:display-dependency-updates
Scans a project’s dependencies and produces a report of those dependencies which have newer versions available.

mvn versions:display-plugin-updates
Scans a project’s plugins and produces a report of those plugins which have newer versions available, taking care of Maven version prerequisites.

mvn versions:display-property-updates
Scans a project and produces a report of those properties which are used to control artifact versions and which properties have newer versions available.