How to refactor uploadArchives for some subprojects at root build.gradle? - gradle

I have a multi project, and I want to upload some of the subprojects artifact to the maven repository.
For now, I wrote the following code into the main build.gradle:
task sourcesJar(type: Jar, dependsOn: classes) { ... }
project(':subProjName1') {
apply plugin: 'java'
apply plugin: 'maven'
configurations {
subProjName1Archives
}
uploadSubProjName1Archives {
repositories {
mavenDeployer {
repository(url: "file:///$rootDir/mvn-repo/")
}
}
}
artifacts {
subProjName1Archives jar
subProjName1Archives sourcesJar
}
}
project(':subProjName2') { ... }
...
project(':subProjNameN') { ... }
And do following for upload archives:
gradlew.bat uploadSubProjName1Archives
gradlew.bat uploadSubProjName2Archives
...
gradlew.bat uploadSubProjNameNArchives
It's doing what I want, but how can I generalize it into one task in the main build.gradle?

If you put the above code into a subprojects { .. } block in the root build script, you can invoke all tasks at once with gradle uploadMyConfiguration. (Only) if you have a concrete need for a single task (e.g. because another task depends on all artifacts being uploaded), you can add a further lifecycle task:
task uploadAll {
dependsOn { subprojects.uploadMyConfiguration }
}
PS: Unless you have a good reason not to, you can reuse the existing archives configuration and uploadArchives task. The archives configuration already contains the Jar produced by the jar task, so you just have to add the sources Jar.

Related

Gradle - uploadArchives generated snapshot is different from createJar

With my build.gradle file I am creating a jar file using a createJar task, which I later upload using an upload using an uploadArchives task.
The project is in groovy, structured like:
/src/main/groovy/package.name
/src/test/groovy
It's a test jar file, where the main class is in /src/test/groovy and it uses for processing classes from /src/main/groovy/package.name
The createJar task works and creates the jar that I need correctly.
So far so good.
The problem is when I run uploadArchives, which generates a snapshot.jar and it only contains the classes from /src/main/groovy/package.name
Why are the 2 jar files different ?
How can I make uploadArchives to upload the jar from createJar (or at least include the test classes as well & run it using the main class specified in createJar) ?
In build.gradle I have something like :
apply plugin: 'groovy'
apply plugin: 'java'
apply plugin: 'maven'
sourceCompatibility = 1.5
repositories {
mavenCentral()
}
artifacts {
archives file: file('./build/libs/name-'+version+'.jar'), name: 'name', type: 'jar'
}
task createJar(type: Jar) {
classifier 'test'
from sourceSets.test.output
manifest {
attributes 'Implementation-Title': 'Gradle Jar File',
'Implementation-Version': version,
'Main-Class': 'MainClassName'
}
}
uploadArchives {
repositories {
mavenDeployer {
repository(url: "http://url/snapshotsFolder/") {
authentication(userName: "user", password: "pass")
}
}
}
}
To extend my comment, let me add an example:
jar {
classifier 'test'
from sourceSets.test.output
manifest {
attributes 'Implementation-Title': 'Gradle Jar File', 'Implementation-Version': version, 'Main-Class': 'MainClassName'
}
}
This will configure the task jar of type Jar, which is created by the java plugin.

gradle-release build and publish non-snapshot artifacts

I have a multi-module project. And, I want to be able do just do gradle release and get all artifacts of all modules released.
One of the problems is that when I include the plugins, I get
Task with name 'build' not found in root project '
So, following some advice on the internet I created a build task and added a bunch of dependencies on it:
plugins {
id "net.researchgate.release" version "2.6.0"
}
defaultTasks 'clean', 'assemble'
def repoUrl = System.env.REPO ?: "https://company.jfrog.io/company/maven"
allprojects {
repositories {
mavenCentral()
jcenter()
maven {
url 'https://dl.bintray.com/palantir/releases'
}
maven {
credentials {
username System.env.REPO_USER
password System.env.REPO_PASS
}
url repoUrl
name 'company'
}
}
}
task build{}
subprojects { thisProject ->
apply plugin: 'java'
apply plugin: 'maven'
apply plugin: 'checkstyle'
apply plugin: 'maven-publish'
apply plugin: 'findbugs'
build.dependsOn "${thisProject}:build"
publishing {
repositories {
maven {
credentials {
username System.env.REPO_USER
password System.env.REPO_PASS
}
url repoUrl
name 'company'
}
}
publications {
"-$thisProject.name-"(MavenPublication) {
from components.java
}
}
}
sourceCompatibility = 1.8 // java 8
targetCompatibility = 1.8
task sourcesJar(type: Jar, dependsOn: classes) {
classifier = 'sources'
from sourceSets.main.allSource
}
task javadocJar(type: Jar, dependsOn: javadoc) {
classifier = 'javadoc'
from javadoc.destinationDir
}
artifacts {
archives sourcesJar
archives javadocJar
}
}
tasks.each {println(it)}
afterReleaseBuild.dependsOn tasks.publish
when I run gradle tasks --all I get
task ':afterReleaseBuild'
task ':beforeReleaseBuild'
task ':build'
task ':checkCommitNeeded'
task ':checkSnapshotDependencies'
task ':checkUpdateNeeded'
task ':commitNewVersion'
task ':confirmReleaseVersion'
task ':createReleaseTag'
task ':createScmAdapter'
task ':initScmAdapter'
task ':preTagCommit'
task ':release'
task ':runBuildTasks'
task ':unSnapshotVersion'
task ':updateVersion'
"release" works. That is to say it bumps versions, tags, strips the "-SNAPSHOT" off, etc. But, there is a step missing here (and it could totally be my ignorance), but upon stripping the "-SNAPSHOT" from the version I need it to build the artifacts and publish them. This is like the maven release process but without the artifact upload. I am currently using gradle publish and not maven upload.
Caveats: Very new to gradle but not java
Can someone tell me what I am missing?
_
You just can try to remove build task from the relesae plugin configuration.
buildTasks = [] works fine for me.
release {
...
tagTemplate = '${version}'
versionPropertyFile = 'gradle.properties'
buildTasks = []
...
}

How to collect javadoc jars into a zip file

For a multi-project Gradle project, foo, bar and baz. I'm trying to create a task which creates a zip file with both libraries and javadoc, i.e. foo.jar, AND foo-javadoc.jar..
./build.gradle
./settings.gradle
./foo/build.gradle
./bar/build.gradle
./baz/build.gradle
settings.gradle
include ":foo"
include ":bar"
include ":baz"
Top level build
allprojects {
apply plugin: 'java'
task generateJavadoc (type : Javadoc) {
source = sourceSets.main.allJava
classpath = sourceSets.main.compileClasspath
failOnError = false
}
task javadocJar(type: Jar, dependsOn: generateJavadoc) {
classifier = 'javadoc'
from generateJavadoc.destinationDir
}
artifacts {
archives javadocJar
}
}
task buildZip(type: Zip, dependsOn: build) {
duplicatesStrategy = DuplicatesStrategy.EXCLUDE
from (project(':foo').configurations.runtime) {
into 'jars'
}
from (project (':foo').configurations.archives.all) {
into 'jars'
}
}
When I invoke this with gradle clean buildZip a zip file is created, but without the any -javadoc JARs I was expecting... The JavaDoc jars are generated into the project build directories, e.g. foo/build/lib/foo-javadoc.jar I've tried multiple combinations of from project (':foo').artifacts etc.
This is possible using the following. Note javadocJar is the name of the task defined in the allprojects block
from (rootProject.allprojects.javadocJar.outputs) {
into 'javadoc'
}

Gradle war ignores transitive dependencies when using 'configurations.runtime.asPath' in custom task

I'm facing behavior that I can't explain, using gradle 1.10 I have:
settings.gradle:
include('lib1', 'lib2', 'web')
build.gradle:
subprojects {
apply plugin: 'java'
}
project(':web') {
apply plugin: 'war'
dependencies {
compile project(':lib1')
}
task myTask(type: JavaExec, dependsOn: 'compileJava') {
main = "some.thirdparty.Class"
args "--searchPath", configurations.runtime.asPath
}
}
project(':lib1') {
dependencies {
compile project(':lib2')
}
}
project(':lib2') {
}
When I run gradle clean war I only have lib1.jar in war/build/libs/web.war/WEB-INF/lib.
To make WEB-INF/lib contain both lib1.jar and lib2.jar I have to:
move project('web') block to the end of the file
update configurations.runtime.asPath to configurations.runtime (but I need to provide class path as a path, so it is not a solution)
I read the build lifecycle description, tried to compare --debug outputs but that didn't help.
Why is this happening? And what would be a good solution to provide the module runtime class path as a path in JavaExec task please?
asPath resolves the configuration, but resolution will only work correctly if it happens at execution time rather than configuration time (in particular in the presence of project dependencies). Try to wrap the args line with doFirst { ... }.

How to generate multiple jar files with gradle's java plugin

I have a multi-project gradle build using the java plugin setup as follows:
myProj/
settings.gradle
build.gradle
util/
build.gradle
In my util project, I would like to generate 2 jars... one for packageA and one for packageB. I'm a noob with gradle so any help here would be much appreciated. Here are my settings and gradle files:
myProj/settings.gradle
include 'util'
myProj/build.gradle
subprojects {
apply plugin: 'java'
repositories {
maven {
url "http://mymavenurl"
}
}
sourceSets {
main {
java {
srcDir 'src/java'
}
}
}
}
myProj/util/build.gradle
dependencies {
.
.
.
}
jar {
baseName = 'packageA'
includes = ['com/mycomp/packageA']
}
task packageBJar(type: Jar) {
dependsOn classes
includes = ['com/mycomp/packageB']
baseName = 'packageB'
}
When I try to build my project here is the output:
:util:compileJava
:util:processResources UP-TO-DATE
:util:classes
:util:jar
:util:assemble
:util:compileTestJava UP-TO-DATE
:util:processTestResources UP-TO-DATE
:util:testClasses UP-TO-DATE
:util:test
:util:check
:util:build
I would hope to see :util:packageBJar after classes, but I'm not having any luck.
One way is to declare packageBJar as an artifact of, say, the archives configuration:
artifacts {
archives packageBJar
}
Now gradle assemble, and therefore also gradle build, will produce packageBJar.

Resources