Excluding one or two sub-projects from publication in gradle - gradle

I have a multi-project gradle build and I have applied the maven-publish plugin to all subprojects in my master build file.
I have also defined a default publication there called mavenJava.
This is all fine and now when I run ./gradlew artifactoryPublish I deploy artifacts from all the subprojects.
However, I would like to exclude two of my subprojects from publishing this mavenJava publication.
I've tried a bunch of things such as defining a boolean (skipDefaultPublish) in the ext block in the subprojects block in my master build file and including the publication definition inside a conditional if block and overwriting this variable in the ext block of the subprojects I do not want to publish it. That doesn't work and gradle complains that it Cannot configure the 'publishing' extension after it has been accessed..
I've tried other things but nothing seems to work.
The only thing that I know will work is defining the default publication block in all subprojects except for the ones that I do not want to publish from, but I have ~20 subprojects but only two that should not publish this type of artifact so this doesn't seem like the best thing to do.
So is there any way I can configure all subprojects to publish an artifact but override that in only two of the subprojects so that they don't do that?
UPDATE
To try to clarify what my project looks like.
root build.gradle
subprojects {
apply plugin: 'maven-publish'
publishing {
publications {
mavenJava(MavenPublication) {
from components.java
artifactId = getCustomProjectId()
groupId = 'com.our.group.id'
}
}
}
apply plugin: "com.jfrog.artifactory"
artifactory {
contextUrl = ourContextUrl
publish {
repository {
repoKey = "ourRepoKey"
username = "ourArtifactoryUser"
password = "ourArtifactoryPass"
}
defaults {
publications('mavenJava')
publishArtifacts = true
publishPom = true
}
}
}
}
and in a subproject which should publish an artifact, just not the default one:
project(':exsub'){
publishing {
publications {
mavenSrc(MavenPublication) {
groupId "com.our.group.id"
artifactId "stuff-src"
artifact srcStuff
}
}
}
artifactoryPublish {
// publications.removeAll() //<- putting this here doesn't work
// publications.remove('mavenJava') //<- neither does this
publications ('mavenSrc') //<- this adds mavenSrc to the publication list but does not remove the mavenJava publication from it
}
}

There are several ways to publish artifacts, depending on used plugins.
To exclude particular module from publishing with modern (Gradle 4.x-7.x) publish like tasks:
tasks.withType(PublishToMavenRepository).configureEach { it.enabled = false }
Legacy uploadArchives:
uploadArchives.enabled = false
With com.jfrog.artifactory plugin:
artifactoryPublish.skip = true

Pheww... I think I finally figured out a way to do this (the aesthetics of the solution are quite debatable).
For me, it was sufficient to put a publishing.publications.remove(publishing.publications.mavenJava) line in the subproject.
However, I had to take care to put that line below the publishing{...} block in that subproject.
So now, the subprojects that should not publish the "default publication" look something like this:
project(':exsub'){
publishing {
publications {
mavenSrc(MavenPublication) {
groupId "com.our.group.id"
artifactId "stuff-src"
artifact srcStuff
}
}
}
// Remove the default publication (note: this must be located after the publishing block above)
publishing.publications.remove(publishing.publications.mavenJava)
artifactoryPublish {
publications ('mavenSrc') //<- this adds mavenSrc to the publication list but does not remove the mavenJava publication from it
}
}

Setting the following on subprojects you want to exclude worked for me:
project.tasks.publish.enabled = false
This does still require the maven-pulish plugin to be applied to the project, but no additional configuration is needed.
I found this setting here: https://discuss.gradle.org/t/disable-maven-publish-related-tasks-not-possible/13488

Let's consider the following multi-module project structure.
photos:
-> photo-client
-> photo-model
-> photo-service
In the above multimodule project, If I want to exclude the functionality of the photo-service submodule build jar (any distributive file(jar/war)) from uploading to the configured artifactory, then we have to use the below code snippet in the photo-service's build.gradle file
build.gradle
dependencies {
.....
}
project.afterEvaluate {
project.tasks.artifactoryPublish.enabled(false)
}

This question is specifically about what to do when some general configuration introduces one publication for all subprojects, but in one specific project you want to remove that "default" publication, but still have another publication. Most of the answers don't address this.
The answer by the original questioner does, but it didn't work for me.
This did:
tasks.withType(PublishToMavenRepository) {
onlyIf {
publication != publishing.publications.mavenJava
}
}
(where mavenJava is the name of the "default" publication to prevent).
This kind of solution is suggested by the Gradle documentation here: https://docs.gradle.org/current/userguide/publishing_customization.html#sec:publishing_maven:conditional_publishing

Related

How to publish to Artifactory with Gradle without publishing dependent projects

I'm updating some build.gradle files to add Artifactory publishing. In some cases I want to publish the top level project's artifacts without publishing artifacts for its dependent projects. The dependent projects get published on their own or when built by a different project.
I've added basic publishing and artifactory tasks to the build.gradle files and they work, but for example if there's a project called "api" that has a dependent project called "db", when I run the build.gradle for "api", it publishes the artifacts for both "api" and "db". I want it to only publish the api artifacts.
I'm not having much luck finding what I want on Jfrog's site. The documentation mentions "Use the artifactoryPublish.skip flag to deactivate analysis and publication", but honestly I don't know what to do with that and if it would help in my case.
The gradle scripts are referencing dependencies like this:
implementation project(path: ':db', configuration: 'default')
I've run the builds in both Eclipse and Jenkins. We use Gradle 7.4. I'm calling the clean, build, and artifactoryPublish tasks. I suspect there's probably an easy way to do this, and I'm just not seeing it.
For reference, this is my publishing task:
publishing {
publications {
mavenJava(MavenPublication) {
from components.java
}
}
}
And here's the publish part of the artifactory section:
publish {
repository {
repoKey = 'libs-release-local'
username = "${artifactory_user}"
password = "${artifactory_password}"
ivy {
ivyLayout = '[organization]/[module]/[revision]/ivy-[revision].xml'
artifactLayout = '[organization]/[module]/[revision]/[artifact]-[revision].[ext]'
mavenCompatible = true
}
}
defaults {
publications('mavenJava')
publishArtifacts = true
properties = ['qa.level': 'basic', 'dev.team' : 'core']
publishPom = true
publishIvy = true
}
}
I found an answer. For a project that has "db" as a dependency, after the dependencies section of my build.gradle file, I added the following:
gradle.startParameter.excludedTaskNames += "db:artifactoryPublish"
Now when I run the artifactoryPublish task for the api project, it does not execute for the db project, too.
For excluding the "db" project from publishing to Artifactory, you can add the following in your build.gradle file:
project('db') {
artifactoryPublish.skip = true
}

Gradle: publish an artifact with a subset of files/dependencies of a project

I am lost in all these plugins :(
What I have so far, looks something like this:
artifactory {
contextUrl = artifactoryUrl
publish {
repository {
repoKey = project.repo
username = artifactoryUser
password = artifactoryPassword
maven = true
defaults {
publications('mavenJava')
}
}
}
version = "${majorVersion}${buildNumber}${snapshot}"
publishing {
publications {
mavenJava(MavenPublication) {
from components.java
artifact sourceJar {
classifier = 'sources'
}
}
}
}
I am sorry, I did write this myself, but, mostly by copying and pasting things from various examples I found on the web, so I am not sure what this is actually doing :(
Surprisingly, this works: I can do gradle artifactoryPublish, and uploads a pom file and two jars (classes and sources) to artifactory.
But, I need to modify it, so that I can publish a subset of the project as a different artifact, and only include the dependencies that it requires.
I managed to build a jar file:
task utilJar(type: Jar) {
from sourceSets.main.output.classesDir
include '**/util/*.class'
baseName 'basic-util'
}
I also defined a Configuration with a subset of dependencies:
configurations {
util
}
dependencies {
util "org.apache.commons:commons-lang3:3.4"
util "com.google.guava:guava:18.0"
}
artifacts {
util utilJar
}
This is where I get stuck. How do I get this new artifact published?
I tried following the same strategy:
publishing {
publications {
mavenUtil(MavenPublication) {
from components.java
artifact utilJar {
classifier = 'util'
}
}
}
}
artifactory {
defaults {
publications('mavenUtil')
}
}
(this is in a subproject, so I need it do be incremental)
This does not work:
Could not find method defaults() for arguments [build_8axxghkylu3559p5lal6spy1u$_run_closure7$_closure11#38abcbd4]
But, even if it did, it would still be not be quite what I need, because I don't know how I could then publish a particular artifact: the only way I could ever publish anything at all is gradle artifactoryPublish, but that does not ask me which artifacts to publish. Will it publish everything every time?
As you can see, I am hopelessly lost here :(
Could someone with a clue please show me the light?
UPDATE So, I removed the last artifactory closure from the build, and now I not getting the error, but still can't get it to do what I need.
My artifactory seems to be not in good mood right now, so I am publishing locally.
gradle publishToMavenLocal creates a single artifact as before, but adds my new "-util" jar to it. This is not at all what I want. I need a new, separate artifact, with that jar file, and its own set of dependencies.
Here: https://docs.gradle.org/current/userguide/publishing_maven.html#publishing_maven:repositories I found a suggestion, that "The created task is named “publish«PUBNAME»PublicationTo«REPONAME»Repository”". This does not seem to to be true, because gradle publishUtilMavenPublicationToMavenLocalRepository (with all the case variations I could think off) says that there is no such task. :(
Have you tried using the set me up feature? It available for all version of Artifactory. It should provide a good starting point to configure you gradle project to work with Artifactory.
Specifically for Gradle it can assist you with generating the relevant configuration according to the repositories you wish to resolve / publish from / to, defining the relevant dependencies to install the jfrog plugin etc.

How do I generate maven-metata.xml with maven-publish and the artifactory-gradle-plugin?

I've written a Gradle plugin in groovy and used Gradle to build it. I've got a local network Artifactory server that I publish the results to using the Gradle Artifactory plugin and the maven-publish plugin in Gradle. I have another Gradle build script that relies on this plugin as a dependency. I've been able to get this all working if I list my dependency with a specific version. I've tried to use a maven version range (ex. '[1.0,2.0)'), but this fails saying it can't find maven-metadata.xml. I checked Artifactory, and sure enough, it isn't there. What do I need to do to produce it, preferably during the build of the plugin?
Here is the build.gradle file for my custom gradle plugin:
buildscript {
repositories {
maven {
url "${artifactory_contextUrl}/plugins-release"
credentials {
username = "${artifactory_user}"
password = "${artifactory_password}"
}
}
}
dependencies {
classpath group: 'org.apache.directory.studio', name: 'org.apache.commons.io', version: '2.4'
classpath group: 'org.jfrog.buildinfo', name: 'build-info-extractor-gradle', version: '2.0.9'
}
}
plugins {
id 'com.jfrog.artifactory' version '3.0.1'
}
apply plugin: 'groovy'
apply plugin: 'maven-publish'
artifactory {
contextUrl = "${artifactory_contextUrl}"
publish {
repository {
repoKey = 'plugins-snapshot-local'
username = "${artifactory_user}"
password = "${artifactory_password}"
maven = true
}
defaults {
publications ('mavenJava')
}
}
resolve {
repository {
repoKey = 'libs-release'
username = "${artifactory_user}"
password = "${artifactory_password}"
maven = true
}
}
}
dependencies {
compile gradleApi()
compile localGroovy()
}
publishing {
publications {
mavenJava(MavenPublication) {
from components.java
}
}
}
I've searched the Gradle, Artifactory, and Maven documentation to understand maven-metadata.xml and how to generate and deploy. It makes sense what it is, and I could probably build one manually, but I can't find anything that explains specifically how to automatically generate it in Gradle with either the maven-publish plugin or the artifactory-gradle-plugin. I don't want to have to manually update the file since that would defeat the automation effort, and I don't want to switch to mvn since I've already invested so much in Gradle.
A groupId had to be added to the publications section. Once implemented, a maven-metadata.xml file was published to the artifact repository.
publishing {
publications {
mavenJava(MavenPublication) {
groupId = 'com.group'
}
}
}
I had the same problem and it turned out that the Artifactory repository was not a Maven repo, it was a Generic repo. It took me forever to notice because I didn't create the repo and I assumed it was a Maven repo, and deploying/resolving otherwise was working as expected.
After switching to a Maven repo, the maven-metadata.xml's were generated upon publishing.
maven-metadata.xml should be handled by Artifactory.
What is your local repository layout in Artifactory?
The accepted answer is correct. And I upvoted it. However, there is also this caveat.
I have a multi module project, so I will use "allprojects". If you have a monolith/single-jar ( :( ).. you can use use a different scope than "allprojects".
They key here is that you set the "group". (and version as well)
allprojects {
apply plugin: 'java-library'
apply plugin: 'maven-publish'
apply plugin: 'com.jfrog.artifactory'
repositories {
jcenter()
}
group = 'com.group'
version = '1.0-SNAPSHOT'
}
Ok, now build.gradle (which in my multi-module project is not the root-build.gradle) (but values in a root build.gradle would be similar)
below is the entire contents of my non-root build.gradle file
// the "name" variable inside the publications/myPublicationName block is getting overwritten. so create a variable here to capture the name (as the artifactid)
def artifactIdForPublicationBlockHolder = "${name}"
dependencies {
testImplementation group: 'junit', name: 'junit', version: junitVersion
}
println("hey.here.read.me")
println("group=${group}")
println("version=${version}")
println("artifactId=${name}")
publishing {
publications {
myCustomPublicationName(MavenPublication) {
// groupId, artifactId and version have defaults, so do not arbitrarily override : https://docs.gradle.org/current/userguide/publishing_maven.html#publishing_maven:publications
//your value below could be slightly different, look for *.jar after you do ./gradlew. build (note, this path value (of "./") is relative to the non-root-build.gradle path, not the overall root-build.gradle
"./build/libs/${artifactIdForPublicationBlockHolder}-${version}.jar"
}
}
}
As the link says, you'll get defaults for
// groupId, artifactId and version have defaults, so do not arbitrarily override : https://docs.gradle.org/current/userguide/publishing_maven.html#publishing_maven:publications
You just have to set these values, like I show above with the
group = 'com.group'
version = '1.0-SNAPSHOT'
code
After going thru the grinder a few times with the
myCustomPublicationName(MavenPublication)
I find the least amount of stuff I custom-set, the better. and prefer to piggy back on the defaults...which means setting the values which drive the defaults... in the build.gradle .. and not to set the myCustomPublicationName(MavenPublication)
altering the values inside
myCustomPublicationName(MavenPublication)
should be reserved (IMHO) to when the defaults don't work for you. which usually is a very small minority of time.
note:
"${name}" at the top of my non-root-gradle.build is getting populated by the directory structure of my multi-module project.
i don't know how it works in a non multi-module since i never write monoliths.
settings.gradle example in my code:
rootProject.name = 'com.me.myproject-rootProjectName'
include ':source:java:mydatalayer'
include ':source:java:mybizlogic'
include ':source:java:mydomain'
Bonus Quote below:
Moreover, modular decomposition represents a key component of software
quality. If you have a tightly coupled system, when you tweak one
component, the whole system breaks. If you thought in terms of APIs,
the intermodular boundaries are clear, so you can maintain and improve
one module without affecting the others.
Massive refactorings prove difficult. If you built something as a
monolithic system and then find you had repeated code all over the
place, and you want to refactor it properly, you'll have a massive
job. In contrast, if you wrote it as components, but you got some of
the component boundaries a little wrong, you can tweak them easily.
-- Joshua Bloch, former Chief Java Architect at Google. Modular Decomposition Link

Gradle's publishToMavenLocal task is not executed correctly

I'm trying to create a gradle based multi-module project. There is also an project that contains different gradle scripts that enables pluggable build configurations. One of those scripts is for publishing artifacts to maven repository. This is the content of that script:
apply plugin: 'maven-publish'
configure(subprojects.findAll()) {
if (it.name.endsWith('web')) {
publishing {
publications {
mavenWeb(MavenPublication) {
from components.web
}
}
}
} else {
publishing {
publications {
mavenJava(MavenPublication) {
from components.java
}
}
}
}
}
build.dependsOn publishToMavenLocal
This script is included in the build gradle file of other project.
apply from: '../../food-orders-online-main/artifact-publish.gradle'
When I run build task it always shows that publishToMavenLocal task is up to date and I cannot find the artifacts in the local repository. Am I doing something wrong?
By adapting answer from here, it works for me.
publishing {
publications {
mavenJava(MavenPublication) {
from components.java
}
}
repositories {
mavenLocal()
}
}
I think this could be a manifestation of a bug with gradle, that modules can lose the publishMavenJavaPublicationToMavenLocal task when they are depended upon in a certain way.
If gradle determines that there is no publishMavenJavaPublicationToMavenLocal task for a module then the publishToMavenLocal task will always report that it is up to date.
The specific case I have found occurs in a multimodule setup, with multiple levels of nested modules. It can be summarised as follows, where shared:domain loses its publishMavenJavaPublicationToMavenLocal when depended upon by A
root
root gradle build file
->A
own gradle build file with dependency on shared:domain
-> shared
gradle build file for shared modules
-> shared:domain
-> shared:B
I have created a small example project demonstrating this behaviour available here - https://github.com/piersy/Gradle2MavenPublishBug
I have also logged a bug with gradle here - http://forums.gradle.org/gradle/topics/the-publishmavenjavapublicationtomavenlocal-task-disappears-from-a-project-when-that-project-is-depended-upon-in-a-specific-way
For now the workarounds I have found are to
Remove A's dependency on shared:domain
Make A a submodule with its configuration specified in its parent module build file
Give shared:domain its own gradle build file

Gradle Maven plugin generates incorrect POM dependencies for custom configuration

I have a Gradle project which does a couple of orthogonal things:
Compile and run some Java.
Generate and publish an artifact.
This artifact is nothing to do with the Java; it's generated by a custom JavaExec task. However, the auto-generated POM (from the Maven plugin) seems to include the wrong dependencies. Question: How can I prevent this?
My build.gradle looks something like this:
apply plugin: "java"
apply plugin: "maven"
configurations {
foo // Custom configuration for the artifact I want to build and publish
}
// Dependencies for Java configurations (nothing to do with foo)
dependencies {
compile "foo:foo:1.1"
testCompile "bar:bar:2.2"
}
// Custom task
task generateFoo(type: JavaExec) {
ext.outputFile = new File(buildDir, "foo.bar")
...
}
artifacts {
foo file: generateFoo.outputFile, builtBy: generateFoo
}
uploadFoo {
repositories {
mavenDeployer { ... }
}
}
I invoke Gradle like this:
./gradlew uploadFoo
AFAICS, the foo configuration is unrelated to the Java configurations. So I expect the published POM to list no dependencies. However, I observe all the unrelated dependencies listed.
The Gradle docs for the Maven plugin hint at dependency mapping with conf2ScopeMappings, but I'm entirely unclear what (if anything) I should be doing with this.
Note: I'm using Gradle wrapper 1.6; I'll be trying the latest to see if that makes a difference...
I managed to setup similar configuration with both maven and maven-publish gradle plugins.
In my case I was using custom Jar task with custom configuration, but it should work because the artifacts { ... } are used in both cases.
With maven plugin, your build.gradle would look like:
apply plugin: "java"
apply plugin: "maven"
configurations {
foo // Custom configuration for the artifact I want to build and publish
}
// Dependencies for Java configurations (nothing to do with foo)
dependencies {
compile "foo:foo:1.1"
testCompile "bar:bar:2.2"
}
// Custom task
task generateFoo(type: JavaExec) {
ext.outputFile = new File(buildDir, "foo.bar")
...
}
artifacts {
foo file: generateFoo.outputFile, builtBy: generateFoo
}
uploadFoo {
repositories {
mavenDeployer {
pom.scopeMappings.with {
mappings.clear()
addMapping(300, configurations.foo, 'runtime')
}
pom.artifactId = 'other artifact id than main jar'
...
}
}
}
This solution was inspired by following thread:
http://gradle.1045684.n5.nabble.com/pom-generation-and-inherited-dependencies-td1436197.html
Note the line:
addMapping(300, configurations.foo, 'runtime')
You can add other configurations as well, or use other maven scope than the 'runtime' scope.
300 stands for priority, which is not significant in this case.
Advantage of this solution is that we have quite fine control over dependencies and their mappings. Disadvantage would be that this will not work for the install task. We would need to setup different poms for the install task, which might be possible, but it is beyond my knowledge.
Alternative with usage of maven-publish plugin:
apply plugin: "java"
apply plugin: "maven-publish"
configurations {
foo // Custom configuration for the artifact I want to build and publish
}
// Dependencies for Java configurations (nothing to do with foo)
dependencies {
compile "foo:foo:1.1"
testCompile "bar:bar:2.2"
}
// Custom task
task generateFoo(type: JavaExec) {
ext.outputFile = new File(buildDir, "foo.bar")
...
}
artifacts {
foo file: generateFoo.outputFile, builtBy: generateFoo
}
publishing {
publications {
foo(MavenPublication) {
from new org.gradle.api.internal.java.JavaLibrary(\
configurations.api.artifacts.toArray()[0], \
configurations.api.allDependencies)
artifactId 'other artifact id than main jar'
}
}
repositories {
maven { ... }
}
}
gradle tasks will give you possible publish commands:
publish - Publishes all publications produced by this project.
publishFooPublicationToMavenLocal - Publishes Maven publication 'foo' to the local Maven repository.
publishFooPublicationToMavenRepository - Publishes Maven publication 'foo' to Maven repository 'maven'.
publishToMavenLocal - Publishes all Maven publications produced by this project to the local Maven cache.
...
The advantege of maven-publish alternative is that it will work for both local and remote maven repositories. Disadvantage may be a fact that we are using the internal API which may change in future and that all dependencies are mapped to the 'runtime' maven scope. Also the MavenPublication snippet would be much more verbose and more internal API would be used if we would like to use some other maven scope or apply some scope mapping.
I am using Gradle 1.10

Resources