Get Gradle classpath from command line - maven

With Maven, I can print the build classpath with this command:
mvn dependency:build-classpath
Is there a similar command I can use with Gradle from the command line, preferably without having to modify any of the build scripts?

You can list all the dependencies in a configuration from CLI:
gradle dependencies --configuration=runtimeOnly
Or you can do that via a task:
task classPath {
doFirst {
configurations.runtimeOnly.each { println it }
// This should probably work as well:
// sourceSets.main.runtimeClasspath.each { println it}
}
}

Related

How to write maven build script from existing project's gradle build script?

I am currently working on springboot application which is configured using gradle.
We now have to migrate it from gradle to maven.
How to write equivalent maven build script from gradle script?
For example, refer to this piece of gradle script :
task doJacocoOfflineInstrumentation(dependsOn: [classes, project.configurations.jacocoAnt]) {
inputs.files classes.outputs.files
File outputDir = new File(project.buildDir, 'instrumentedClasses')
outputs.dir outputDir
doFirst {
project.delete(outputDir)
if (file(sourceSets[sourceSetName].output.classesDirs[0]).exists()) {
def instrumentedClassedDir = "${outputDir}/${sourceSetName}"
copy {
from sourceSets[sourceSetName].output.classesDirs[0]
into instrumentedClassedDir
}
}
}
How to write equivalent of such scripts in maven?
NOTE : I have already used plugin: "maven-publish" to get all the dependencies from gradle to maven, that is not the issue.

Gradle unable to resolve dynamic version of plugin from mavenLocal, how to get latest version?

I have created a Gradle plugin that creates some extra tasks and am publishing the plugin to MavenLocal with version 0.2.1. I can see the created jar in ~/.m2.
In another Gradle project, I am trying to pull in that plugin within the buildscript section of build.gradle, like this:
buildscript {
repositories {
mavenLocal()
}
dependencies {
classpath 'com.example:myplugin:0.2.+'
}
}
Running gradle tasks (or any other task, for that matter) causes Gradle to fail with the message:
> Plugin with id 'com.example.myplugin' not found.
However, if I change the version from 0.2.+ to 0.2.1 then it works. How do I get the latest version of the plugin into my project?
I just put what I did in here, and hope it helps you.
For example, I install the gradle-tomcat-plugin locally (2.4.1 and 2.4.2).
$ git checkout v2.4.2
$ ./gradlew publishToMavenLocal
$ git checkout v2.4.1
$ ./gradlew publishToMavenLocal
$ ls /Users/ruichen/.m2/repository/com/bmuschko/gradle-tomcat-plugin
2.4.1 maven-metadata-local.xml
2.4.2
And I added a separate task (showClasspath) to build.gradle to show me what is the version got applied:
task showClasspath {
doLast {
buildscript.configurations.classpath.each { println it.name }
}
}
The buildscript block is also pretty much like yours:
buildscript {
repositories {
mavenLocal()
}
dependencies {
classpath "com.bmuschko:gradle-tomcat-plugin:2.4.+"
}
}
The output is expected:
$ ./gradlew showClasspath
> Task :showClasspath
gradle-tomcat-plugin-2.4.2.jar

How do you run a terminal command in a Gradle task?

I have the following task:
task installMavenLocal(type: Upload) {
description "Installs the artifacts to the local Maven repository."
configuration = configurations['archives']
repositories {
mavenDeployer {
repository url: repositories.mavenLocal().url
}
}
}
When I run my Gradle command I do the following gradle installMavenLocal -x:test:packageRelease, is there a way I can add that command to my above task so that developers don't need to add the -x:test:packageRelease and it just runs when I do the task?
You could use :
installMavenLocal.dependsOn.remove(tasks.getByPath(":test:packageRelease"))

How to extend gradle war task with dofirst/dolast

I need to extend the gradle war task with some doFirst and doLast commands to compile my sencha frontend in production state.
I know to extend a task I need to add task.doFirst {} but this is not working with war. I did some tests using other tasks like
clean {
doFirst {
println "test"
}
}
This is working ... but with war it isn't
war {
doFirst {
println "test"
}
}
My main idea was to remove src/main/webapp from the from list and execute sencha-cmd sencha app build -c --destination $war/ production
You should create a separate task for the sencha compilation with it's own inputs/outputs so Gradle can perform up-to-date checking (so it can be skipped if not necessary). You can then wire the task into the gradle DAG via Task.dependsOn(...)
task compileSencha(type:Exec) {
inputs.dir 'src/main/sencha'
outputs.dir "$buildDir/sencha"
commandLine 'sencha', 'app', 'build', file('src/main/sencha').absolutePath, file("$buildDir/sencha").absolutePath
}
war {
from "$buildDir/sencha"
dependsOn compileSencha
}

Create uberJar from cucumber/groovy tests including dependencies using gradle

i have some functional tests in {project_home}/src/test/groovy/
i want to be able to use a gradle task to:
Make a jar file from all the .groovy files under {project_home}/src/test/groovy/ including all of the dependencies
be able to run this jar file as a substitute of running individual groovy files
All the example i came across have a main method , the one i have have no main()
so i tried to use the "Project's" build.gradle and appended
task fatJar(type: Jar) {
baseName = project.name + '-all'
from { configurations.compile.collect { it.isDirectory() ? it : zipTree(it) } }
with jar
}
and ran $gradle clean fatJar
but got compile failure:
:Tests:EndToEndFunctionalTests:fatJar FAILED
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':Tests:EndToEndFunctionalTests:fatJar'.
> archive contains more than 65535 entries.
To build this archive, please enable the zip64 extension.
See: https://docs.gradle.org/2.7/dsl/org.gradle.api.tasks.bundling.Zip.html#org.gradle.api.tasks.bundling.Zip:zip64
i do have the jar file under /build/libs
task uberJar(type: Jar,dependsOn:[':compileGroovy']) {
zip64 true
from files(sourceSets.main.output.classesDir)
from configurations.runtime.asFileTree.files.collect {zipTree(it) }
with jar
}
Solved the issue.

Resources