Gradle : sourceSets.test.classes not found - gradle

I am trying to get my one of my projects (ProjectA) to generate a jar file containing all the test classes so that it can be used in ProjectB.
I did a bit of research and found this as possible solution: Create test jar artifact in gradle. That says that the following code snippet should do the trick.
apply plugin: 'java'
task testJar(type: Jar) {
classifier = 'tests'
from sourceSets.test.classes
}
However, when I add the above to my build.gradle, I get the following error message:
What went wrong:
A problem occurred evaluating root project 'gradle_project'.
Could not find property 'sourceSets' on task ':testJar'.
I have searched on both Google and the Gradle documentation for more information but either it has been removed without documenting it anywhere that I could find or I am using it wrong. I am suspecting the latter, just don't know what I am doing wrong.
I have tried the same code snippet inside mysubprojects{} section but then I got the following error message:
What went wrong:
A problem occurred evaluating root project 'gradle_project'.
Cannot get the value of write-only property 'classes' on source set test.

Solved it with the steps below:
Step 1: Move the code snippet inside the subprojects{} section
Step 2: sourceSets.test.classes has been removed. sourceSets.test.output seems to do the trick. Found this: Creating a Jar of test binaries - Gradle

Related

Could not get unknown property 'a.b.c' for root project

I got some source code and was asked to build it. It was a Gradle project. So I changed to the project directory and ran:
$ gradle clean assemble
and the following error came up:
...
* What went wrong:
A problem occurred evaluating root project 'pcase'.
> Could not get unknown property 'postgresql.jdbc' for root project 'pcase' of type org.gradle.api.Project.
...
There is a settings.gradle file in the project folder too. It contains:
rootProject.name = 'pcase'
I took a look at build.gradle and found lots of occurrences like
${project['x']}
For example:
buildscript {
dependencies {
...
// FlywayDB, JOOQ.
classpath "org.postgresql:postgresql:${project['postgresql.jdbc']}"
classpath "org.flywaydb:flyway-gradle-plugin:${project['flywaydb.plugin.version']}"
classpath "nu.studer:gradle-jooq-plugin:${project['jooq.plugin.version']}"
...
What could be ${project['x']}? Looks like associative array in bash and the build script tries to get the value of the key 'x'.
But I didn't find the place in code where this array would be declared and initialized.
The question is: Is the project buildable or is it better to consult the company that worked at it before me?
From the information provided, the project is perfectly buildable, to some certain extend. First of all, project['a.b.c'] is Groovy syntax to access properties from the project object. They're referred to as project properties.
They can be set via
Project properties via command line: gradle -Ppostgresql.jdbc=x.y.z
System properties via command line: gradle -Dorg.gradle.project.postgresql.jdbc=x.y.z
System properties via gradle.properties: org.gradle.project.postgresql.jdbc=x.y.z
All 3 properties (postgresql.jdbc, flywaydb.plugin.version, jooq.plugin.version) denote the version numbers of the particular build script dependencies. However, which versions to use best is beyond my knowledge. I would certainly consult the respective project websites, Maven artifact search or simply ask the company.
org.postgresql:postgresql is the database JDBC driver and certainly depends on the database version.
org.flywaydb:flyway-gradle-plugin is for database migrations. Try with the latest version.
I wasn't able to find gradle-jooq-plugin on Maven central. It's most likely available on the Gradle Plugin Portal.

Project with path ':projectA' could not be found in root project 'gradle-tutorial'

I'm new to Gradle and am following this Gradle tutorial, and it gives the following example, which I copied/pasted in my ~/gradle-tutorial/build.gradle file
project(':projectA') {
task hello
}
task hello
println tasks.getByPath('hello').path
println tasks.getByPath(':hello').path
println tasks.getByPath('projectA:hello').path
println tasks.getByPath(':projectA:hello').path
When I run
$ gradle -q hello
I get
FAILURE: Build failed with an exception.
* Where:
Build file '/Users/myuser/gradle-tutorial/build.gradle' line: 1
* What went wrong:
A problem occurred evaluating root project 'gradle-tutorial'.
> Project with path ':projectA' could not be found in root project 'gradle-tutorial'.
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.
I did create a ~/gradle-tutorial/projectA/build.gradle file, but still got the same error.
What am I missing?
Note I did find Project with path ':mypath' could not be found in root project 'myproject' but can't figure how to make that answer work for my simple one-file/one-directory case.
This error indicates that your settings.gradle file is missing or invalid. Inside it, you need to put a reference to the directories of the subprojects that you want to include in your build, like so:
include 'projectA'
For the build.gradle file inside your projectA subdirectory, you don't need to have any content since your root build.gradle file is already adding tasks specifically for the subproject by including the project(':projectA'){ } block. If you'd like to move the contents of that block to your subproject's build.gradle, the functionality would be equivalent.

Gradle ant.importBuild fails while importing and renaming ant target name

I am new to Gradle. I have an ANT build project that I am importing to Gradle using ant.importBuild in build.gradle.
This is a simple ant build.xml that I am using -
<project>
<target name="hello">
<echo>Hello, from Ant</echo>
</target>
</project>
A plain import works fine and I can run the hello target. Here is the contents of my build.gradle (that works) -
ant.importBuild('build.xml')
But, while importing, I want to rename the targets so they don't collide with the other tasks in my Gradle project. So, when I import the build.xml like this -
ant.importBuild('build.xml') { antTargetName ->
'a' + antTargetName
}
it fails with this error -
FAILURE: Build failed with an exception.
* Where:
Build file 'C:\Git\appsec\archutil\gradle_migration\build.gradle' line: 1
* What went wrong:
A problem occurred evaluating root project 'gradle_migration'.
> Problem: failed to create task or type importBuild
Cause: The name is undefined.
Action: Check the spelling.
Action: Check that any custom tasks/types have been declared.
Action: Check that any <presetdef>/<macrodef> declarations have taken place.
I must be doing something silly wrong. What is it? Thanks !!
Try a newer Gradle. I could repro with 2.0 but not 2.4. I think the ability to override ant target names may have been added in Gradle 2.2.

"Pseudo" subproject without code and just dependencies fails when signing is required because of the missing jar

I'd like to create a subproject that acts as sole anchor for dependencies, ie. it includes no source code. Users can simply depend on the artifact created by the subproject in order to get all the required dependencies. So i've created foo-bar/build.gradle:
dependencies {
compile project(":foo-barz")
compile project(":foo-batz")
}
jar {
enabled = false
}
That seems to work as expected, until signing comes into the build process. I've then get an error message
:foo-bar:signArchives FAILED
What went wrong: Execution failed for task ':foo-bar:signArchives' >
java.io.FileNotFoundException:
/data/flo/code/foo/foo-bar/build/libs/foo-bar-4.0.1.jar (No such file
or directory)
How can I tell the signing plugin that it needs to sign just the pom file for this subproject?
I'd say either do not apply the java plugin, then you also don't need to disable the jar task, or also disable the signArchives task like you disabled the jar task.
I've came up with just creating an empty file with
foo-bar/src/main/java/org/foo/bar/FooBarDummy.java
so that all tasks are happy and an empty jar is created, signed and deployed. Thaks to Peter Niederwieser, Vampire and Daryl Teo for their input. I've found no elegant an easy solution to avoid that Dummy.java workaround.
This question was based on implementing smack-java7

OSGi bundle build issue in Gradle

I have a simple use case of building an OSGi bundle using Gradle build tool. The build is successful if there are java files present in the build path, but it fails otherwise.
I am using 'osgi' plugin inside the gradle script and trying to build without any java files. The build always fails with following error:
Could not copy MANIFEST.MF to
I am sure there must be some way to do it in Gradle but not able to fine. Any idea what can be done to resolve this depending on your experience.
I ran into this today as well, and #Peter's fix didn't work for me (I hadn't applied the java plugin in the first place...). However, after hours of Googling I did find this thread, which helped me find the problem.
Basically, it seems that the error occurs (as Peter stated) when no class files are found in the jar - my guess is because the plugin then cannot scan the classes for package names on which to base all the Import and Export information.
My solution was to add the following to the manifest specification:
classesDir = theSourceSet.output.classesDir
classpath = theSourceSet.runtimeClasspath
In my actual build code, I loop over all source sets to create jar tasks for them, so then it looks like this:
sourceSets.each { ss ->
assemble.dependsOn task("jar${ss.name.capitalize()}", type: Jar, dependsOn: ss.getCompileTaskName('Java')) {
from ss.output
into 'classes'
manifest = osgiManifest {
classesDir = ss.output.classesDir
classpath = ss.runtimeClasspath
// Other properties, like name and symbolicName, also set based on
// the name of the source set
}
baseName = ss.name
}
}
Running with --stacktrace indicates that the osgi plugin doesn't deal correctly with the case where both the osgi and the java plugins are applied, but no Java code is present. Removing the java plugin should solve the problem.
I had the same issue also when java code was present.
Adding these two lines to the osgiManifest closure fixed the problem:
classesDir = sourceSets.main.output.classesDir
classpath = sourceSets.main.runtimeClasspath
-- erik

Resources