Consider such a situation: there's a big project, which takes tremendous time to compile and I'm having it's resulting artifacts as separate files (jar).
I want to run the unit tests on this project without compiling and jar-ing project itself, so I need to remove dependency on compileJava task, but this task is not in the dependsOn list of test task.
dependsOn property of test task contains only some [file collection] and if I'm printing this FileCollection.files, I'm getting the list of files and directories, which include .../build/classes/main. I think, after removing this entry, I'll get success in removing dependency on compileJava (as I understood, .../build/classes/main is just the result of running compileJava and that's why compileJava appeared). But I just don't understand, how to remove this entry.
By the way, in this case there's no problem of adding this jar to classpath, so that's not an issue.
I'm using Gradle 1.8.
Thanks.
compileJava will be up-to-date if nothing has changed, and jar isn't depended upon by test. If you nevertheless want to add the ability to run tests against a downloaded Jar, declare another Test task. (Reconfiguring test.classpath should work as well, but seems less desirable.)
Related
What is the difference between "gradle build" and "gradle bootJar"? Why would I use bootJar if I can still create the artifact using build?
build is a lifecycle task contributed by the Base Plugin. It is
Intended to build everything, including running all tests, producing the production artifacts and generating documentation. You will probably rarely attach concrete tasks directly to build as assemble and check are typically more appropriate.
bootJar on the other hand is a specific task added by Spring Boot Gradle plugin that, when the java plugin is present, attaches itself to the assemble lifecycle task.
The assemble task is automatically configured to depend upon the bootJar task so running assemble (or build) will also run the bootJar task.
(Packaging Executable Jars)
You want to use bootJar if you're only interested in building the executable jar and not interested in executing tests, code coverage, static code analysis or whatever is attached to the check lifecycle task.
I want to compile one subproject, then have those classes on the classpath while building the other subproject. (A custom tass would use classes created by the first one).
Currently I'm trying:
buildscript {
dependencies {
classpath project(':MyOtherProject')
}
}
... with the following result:
Cannot use project dependencies in a script classpath definition.
You cannot build something to be used to build the something. (something being the multi-project build here)
You either need to make the MyOtherProject a complete separate build, that you either install to some repository and then depend on it per coordinates or trigger that separate build during configuration phase or your build, then depending on its outcomes.
The other alternative is, that you put it into buildSrc project. This is a full multi-project build contained in your root project that is built and added to the classpath of the main build scripts automatically by Gradle and is meant for Plugins and Custom tasks that you do not want to use in other builds also and thus do not make them a separate build.
what is the difference between assemble and jar task of java plugin in gradle?
I tried executing them with a sample Hello world project they both seems to do the same job.
Since jar is a single task, which assembles a jar-archive for current project, assemble is, according to documentation:
assemble All archive tasks in the project, including jar. Some plugins add additional archive tasks to the project. Task Assembles all the archives in the project.
It is build-cycle task, which execute all the task of this build-cycle phase. Like a check task, which runs all test and verification task, assemble Runs all task, which essemble some artifacts. And the 'jar' could be not the only such a task in the project, some plugins could add them too.
We are new to Gradle and dependency resolution. I am in the process of creating pom.xml files for all our internally-generated artifacts and want to set up a job in our Jenkins server to verify the dependencies are properly defined and not conflicting (i.e. LibA requires x-1.0.jar, LibB requires x-1.1.jar, and AppY requires both LibA and LibB).
As such, I've set up a dummy project in SVN that simply includes a bunch of our internal artifacts as dependencies. Following TTD, I intentionally included some errors in the declarations (i.e. group and name, but not version). Sure enough, those dependencies can't be found.
But when I run this build with gradle (i.e. gradle dependencies) it includes all the failure messages but still says the build succeeded! Not good!
How can I, using Gradle/Jenkins, set up an automated job that will verify all dependencies are found?
There is no built-in task that resolves all dependencies and fails if a dependency isn't found. (IDE tasks are graceful in case of missing dependencies.) But you can easily write your own:
task resolveDependencies {
doLast {
configurations.all { it.resolve() }
}
}
gradle dependencies by design displays Gradle project dependencies reporting (if applicable) if given dependency cannot be resolved (a red text FAILED next to an unresolved dependency). To get an error use some task that depends on resolving dependencies for given configuration(s) like gradle check.
Updated. Gradle is smart in determining if given tasks are required to be executed. Therefor in case there is no source files to compile (compilation requires dependent classes/JARs to be resolved) gradle check can notice that executing compileJava/compileTestJava tasks is not needed (tasks are skipped as up-to-date). You can force it by adding any Java source file into src/main/test (tests requires also production dependencies (from compile configuration)).
This is just a workaround, there is probably a better way to do that (and I hope someone else will present it here).
Short version of question:
Is there a way of telling gradle not to resolve dependencies? I know I can skip single task with -x switch but resolving dependencies isn't performed though some task I guess, to I don't know how to do it.
Long version:
Right now I can run tests from gradle with simple 'gradle test' which performs gathering dependencies, building and running tests..
But I'd also like to run tests using gradle on some other machine which can't download dependencies from maven. I thought that I could just perform some packaging which would download all dependencies to some lib folder, and I could expand tests classpath (in that task) to this folder. The problem is, that gradle still tries to contact maven when I run 'gradle myTests'. Is there a way of preventing resolving dependencies for this single task?
There's the --offline flag. Alternatively, you can declare a flatDir rather than a maven repository whenever the build should be run with "local" dependencies.
For my use case, my internet is restricted so I would setup dependencies while I can still have full access. And when I'm restricted, go to Preferences, search for Gradle, and check "Offline work".
Of course I'll have to turn it back on whenever new dependencies are added.