WARNING: Version 14.x.x requires at least Gradle 5.4
WARNING: Version 17.x.x requires at least Gradle 6.0 or newer for sources and javadoc plugins
WARNING: Version 19.x.x requires at least Gradle 8.0 or newer for sources and javadoc plugins
To apply this plugin if using plugins block
plugins {
id 'com.netflix.nebula.<publishing plugin of your choice>' version '20.2.0'
}
If using an older version of Gradle
buildscript {
repositories { mavenCentral() }
dependencies {
classpath 'com.netflix.nebula:nebula-publishing-plugin:20.2.0'
}
}
apply plugin: 'com.netflix.nebula.<publishing plugin of your choice>'
Provides publishing related plugins to reduce boiler plate and add functionality to maven-publish/ivy-publish.
Create a maven publication named nebula. This named container will be used to generate task names as described in
the Maven Publish documentation on gradle.org. Examples
include publishNebulaPublicationToMavenLocalRepository and publishNebulaPublicationToMyArtifactoryRepository.
All of the maven based publishing plugins will interact with this publication. All of the other maven based plugins will also automatically apply this so most users will not need to.
Eliminates this boilerplate:
apply plugin: 'maven-publish'
publishing {
publications {
nebula(MavenPublication) {
}
}
}
We detect if the war plugin is applied and publish the web component, it will default to publishing the java component.
Applying this plugin would be the same as:
if war detected
publishing {
publications {
nebula(MavenPublication) {
from components.web
// code to append dependencies since they are useful information
}
}
}
if war not detected
publishing {
publications {
nebula(MavenPublication) {
from components.java
}
}
}
Note that nebula.maven-dependencies is based on the Gradle maven-publish plugin, which places first order compile dependencies in the runtime scope in the POM. If you wish your compile dependencies to be compile scope dependencies in the POM, you can add a withXml block like so:
publishing {
publications {
nebula(MavenPublication) {
pom.withXml {
configurations.compile.resolvedConfiguration.firstLevelModuleDependencies.each { dep ->
asNode().dependencies[0].dependency.find {
it.artifactId[0].text() == dep.moduleName &&
it.groupId[0].text() == dep.moduleGroup
}?.scope[0]?.value = 'compile'
}
}
}
}
}
Link all the other maven plugins together.
Adds a properties block to the pom. Copying in data from our gradle-info-plugin.
Walk through all project dependencies and replace all dynamic dependencies with what those jars currently resolve to. Necessary if nebula-dependency-recommender-plugin is used to include version numbers in POM files generated by Gradle's maven-publish.
Adds scm block to the pom. Tries to use the the info-scm plugin from gradle-info-plugin
When Gradle Contacts plugin is applied, it will take the configured contacts and add them to the POM file.
Example, given:
apply plugin: 'com.netflix.nebula.contacts'
contacts {
'[email protected]' {
moniker 'Example Nebula'
github 'nebula-plugins'
}
}
resulting POM will be:
<?xml version="1.0" encoding="UTF-8"?>
<project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd" xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<modelVersion>4.0.0</modelVersion>
<groupId>test.nebula</groupId>
<artifactId>developerpomtest</artifactId>
<version>0.1.0</version>
<packaging>pom</packaging>
<name>developerpomtest</name>
<developers>
<developer>
<id>nebula-plugins</id>
<name>Example Nebula</name>
<email>[email protected]</email>
</developer>
</developers>
</project>
Create an ivy publication named nebulaIvy. This named container will be used to generate task names as described in
the Ivy Publish documentation on gradle.org. Examples
include publishNebulaIvyPublicationToMyLocalIvyRepository and publishNebulaIvyPublicationToMyArtifactoryRepository.
All of the ivy based publishing plugins will interact with this publication. All of the other ivy based plugins will also automatically apply this so most users will not need to.
Eliminates this boilerplate:
apply plugin: 'ivy-publish'
publishing {
publications {
nebulaIvy(IvyPublication) {
}
}
}
We detect if the war plugin is applied and publish the web component, it will default to publishing the java component.
Applying this plugin would be the same as:
if war detected
publishing {
publications {
nebulaIvy(IvyPublication) {
from components.web
// code to append dependencies since they are useful information
}
}
}
if war not detected
publishing {
publications {
nebulaIvy(IvyPublication) {
from components.java
}
}
}
Link all the other ivy plugins together.
Adds a properties block to the ivy.xml. Copying in data from our gradle-info-plugin.
Walk through all project dependencies and replace all dynamic dependencies with what those jars currently resolve to.
Creates a javadocJar task to package up javadoc and add it to publications so it is published.
Eliminates this boilerplate:
tasks.create('javadocJar', Jar) {
dependsOn tasks.javadoc
from tasks.javadoc.destinationDir
archiveClassifier 'javadoc'
archiveExtension 'jar'
group 'build'
}
publishing {
publications {
nebula(MavenPublication) { // if maven-publish is applied
artifact tasks.javadocJar
}
nebulaIvy(IvyPublication) { // if ivy-publish is applied
artifact tasks.javadocJar
}
}
}
Creates a sourceJar tasks to package up the the source code of your project and add it to publications so it is published.
Eliminates this boilerplate:
tasks.create('sourceJar', Jar) {
dependsOn tasks.classes
from sourceSets.main.allSource
archiveClassifier 'sources'
archiveExtension 'jar'
group 'build'
}
publishing {
publications {
nebula(MavenPublication) { // if maven-publish is applied
artifact tasks.sourceJar
}
nebulaIvy(IvyPublication) { // if ivy-publish is applied
artifact tasks.sourceJar
}
}
}
Plugin features are enabled only for Gradle 4.8 and higher. Creates a task which runs before actual publication into repositories. It catches some known bad patters so you can make explicit decision dependency by dependency.
This plugin is NOT automatically applied with nebula.ivy-publish or nebula.maven-publish. You have to apply the plugin to all modules within the project.
allprojects {
apply plugin: 'com.netflix.nebula.publish-verification'
}
Plugin is integrated with Gradle publishing and with Artifactory plugin. The task itself is a dependence of tasks with type PublishToIvyRepository or PublishToMavenRepository. The task will also get hooked to tasks named
artifactoryPublish and artifactoryDeploy coming from com.jfrog.artifactory plugin. If you need any other integration
you have to manually configure relationship in your build file.
When you are publishing a release build and your first level dependency (directly specified in your build file) is with lower status like candidate (e.g. 1.2.0-rc.2 or latest.candidate) or snapshot (e.g. 1.2.0-SNAPSHOT or latest.snapshot) your build will fail. The reason for this check is a protection of your consumers. As a library producer, you could easily introduce lower status of dependencies in your consumer dependency graph. We consider that dependency with lower status means also lower or not completely guaranteed quality. This verification will explicitly highlight such dependencies and you can make an appropriate decision how to handle them instead of silently publishing.
The solution could be slightly different depending on your situation:
- Concrete violating version
1.2.0-rc.2could be replaced with stable version1.2.0 latest.candidatecan be replaced withlatest.release- Open range version
1.+can currently also resolve to1.5-SNAPSHOT, then you can switch to a preferred fixed version. - You might be having the right version in your file but some of your dependencies are depending on a lower status version which will win conflict resolution. The best is to fix your downstream library not depend on the lower status library.
- It can be a completely valid situation, that you depend on a candidate. Then you can ignore given library from this verification.
An incorrect version definition is e.g. 1.1+. It would resolve to 1.1, 1.10, 1.11 etc. but it would miss versions like 1.2, 1.3 etc. This is not what most people would want. We are detecting this situation because it is hard to spot and it leads to unexpected dependency resolutions which are confusing build owners.
The right definition is 1.+ to use the highest version with major version 1 or you can use [1.1,] to use version 1.1 or higher.
It might happen that you need to create a release which has to depend on a library which has a lower status. E.g. it contains critical bug fix or you are early adopter of release candidates. You can exclude those libraries from the checking process.
dependencies {
implementation 'group:this_will_be_checked:1.0'
implementation nebulaPublishVerification.ignore('foo:bar:1.0-SNAPSHOT')
implementation nebulaPublishVerification.ignore(group: 'baz', name: 'bax', version: '1.0-SNAPSHOT')
}
Or you can use extension for this plugin which allows you exclude not just single artifacts but whole groups.
nebulaPublishVerification {
ignore('foo:bar:1.0-SNAPSHOT')
ignoreGroup 'com.company.foo.group'
}
Built with Azul JDK8 Tested with Azul JDK8, JDK11, JDK17
| Gradle Version | Works | | 7.0 | yes | | 8.0 | yes | | 8.1 | yes |
Copyright 2014-2023 Netflix, Inc.
Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.