Le plugin Gradle java-library comparé au plugin java

Question

Dans la documentation Gradle pour l'option plugin java-library Il y est dit que

Le plugin Java Library étend les capacités du plugin Java en fournissant des connaissances spécifiques sur les bibliothèques Java. En particulier, une bibliothèque Java expose une API aux consommateurs (c'est-à-dire d'autres projets utilisant le plugin Java ou le plugin Java Library)

Cette déclaration implique que seuls les programmes Java destinés à être consommés (bibliothèques) doivent utiliser la fonction java-library tandis que les programmes Java qui ne sont pas destinés à être consommés (applications) devraient utiliser le plugin java plugin.

Avant d'utiliser le java-library brancher une racine build.gradle pourrait contenir les éléments suivants :

subprojects {
    apply plugin: 'java'
    sourceCompatibility '1.8'
    targetCompatibility '1.8'

    // other common java stuff
}

Cependant, dans les projets multi-modules qui contiennent à la fois des applications et des bibliothèques, vous ne pouvez pas déléguer la sélection des plugins aux sous-projets et vous vous retrouvez avec le problème Root suivant build.gradle :

subprojects {
    sourceCompatibility '1.8'
    targetCompatibility '1.8'

    // other common java stuff
}

Cette opération échouera pour les raisons suivantes sourceCompatibility y targetCompatibility sont définis par le java y java-library plugins. Idéalement, je voudrais faire ce qui suit :

subprojects {
    apply plugin: 'java-library'
    sourceCompatibility '1.8'
    targetCompatibility '1.8'

    // other common java stuff
}

Existe-t-il une raison d'imposer aux applications Java l'utilisation de l'option java et que les bibliothèques Java utilisent le plugin java-library plugin ? Y a-t-il une raison pour que le java doit être utilisé à la place du plugin java-library plugin ?

Editer

Pour clarifier ma question, dans les exemples de Gradle, il y a un projet multi-modules pour lequel l'option java plugin aquí et pour les java-library plugin aquí . Dans l'échantillon pour le java le plugin Root build.grade utilise le plugin apply plugin: 'java' . Le fichier build.gradle racine pour le projet java-library n'utilise aucun plugin. Le projet d'application utilise apply plugin: 'java' ; tandis que les projets core et utils utilisent apply plugin: 'java-library' .

Ma question est la suivante : pourquoi certains projets devraient-ils utiliser l'option java et d'autres utilisent le plugin java-library plugin ? Il semble qu'il soit plus difficile de ne pas violer le principe DRY. Il est difficile de spécifier le sourceCompatibility y targetCompatibility une seule fois. Je pense à plusieurs façons de spécifier ces propriétés une seule fois, mais la solution la plus simple semble être l'utilisation de l'élément java-library pour tous les projets.

Y a-t-il un avantage à utiliser le java pour certains sous-projets et le plugin java-library plugin pour les autres ?

Answer 1

Selon la docs

[...] le plugin Java Library n'est câblé pour se comporter correctement qu'avec le plugin java plugin.

Vous ne devriez donc pas rencontrer de problèmes si vous appliquez les deux plugins à un projet. Par exemple, vous pouvez appliquer le plugin java à chaque projet via le plugin subprojects et d'appliquer ensuite la fermeture java-library aux sous-projets qui requièrent les fonctionnalités supplémentaires du plugin (par l'intermédiaire de leur build.gradle ).

Veuillez noter que vous pouvez spécifier une configuration dépendante du plugin via l'option withPlugin de la méthode PluginManager ou le withId de la méthode PluginContainer . Les deux méthodes s'appliquent :

Si le plugin a déjà été appliqué, l'action est exécutée. Si le plugin est appliqué ultérieurement, l'action sera exécutée après l'application du plugin. Si le plugin n'est jamais appliqué, l'action n'est jamais exécutée.

subprojects { sub ->
    sub.plugins.withId('java-library') {
        // configure sub
    }
}

Answer 2

Le plugin expose deux configurations qui peuvent être utilisées pour déclarer des dépendances : api y implementation .

Et aussi :

En api doit être utilisée pour déclarer les dépendances exportées par l'API de la bibliothèque, tandis que la configuration implementation doit être utilisée pour déclarer les dépendances internes au composant.

Introduction de Gradle 3.4 nouvelles configurations du plugin de la bibliothèque Java qui vous permettent de contrôler si une dépendance est publiée dans les chemins d'accès de compilation et d'exécution des projets qui consomment cette bibliothèque.
Si vous souhaitez utiliser le nouveau api au lieu de la configuration compile vous devez utiliser le nouveau plugin.

Answer 3

J'ai eu la même question et j'ai trouvé des réponses à la fin de la documentation officielle du plugin : Problèmes connus .

Votre question

Y a-t-il un avantage à utiliser le plugin java pour certains sous-projets et le plugin java-library pour d'autres ?

est répondu par

Augmentation de l'utilisation de la mémoire pour les consommateurs

Lorsqu'un projet utilise le plugin Java Library, les consommateurs utiliseront le répertoire des classes de sortie de ce projet directement sur leur classpath de compilation, au lieu du fichier jar si le projet utilise le plugin Java. Une conséquence indirecte est que la vérification à jour nécessitera plus de mémoire, parce que Gradle fera un instantané des fichiers de classe individuels au lieu d'un seul fichier jar. Cela peut entraîner une augmentation de la consommation de mémoire pour les grands projets.

Un paragraphe est également consacré aux problèmes rencontrés avec d'autres plugins et à la manière de les contourner.

Dans Gradle 5.3 ou antérieur, certains plugins, comme le plugin Groovy, peuvent ne pas se comporter correctement.