Gradle not compiles with solder-tooling.jar

I spent 2 days for find a problem. After command ./gradlew build folder “build/classes/main” is always empty(try with gradle 1.9, 1.11 and 1.12).

I have next dependencies: … compile files(’…/lib/seam/solder-api.jar’) compile files(’…/lib/seam/solder-impl.jar’) compile files(’…/lib/seam/solder-logging.jar’) compile files(’…/lib/seam/solder-tooling.jar’) … if i remove this dependency

compile files(’…/lib/seam/solder-tooling.jar’)

then, folder “build/classes/main” contains class files and everythings ok. Why? What problem with solder-tooling.jar???

Try to turn on ‘–info’ or ‘–debug’ logging to get more information. What’s the purpose of ‘solder-tooling’? A quick Google search indicates that it contains an annotation processor (i.e. a Java compiler plugin), so maybe that’s where things go wrong.

solder-tooling.jar is part our old project with Jboss Seam 3. Now, Seam 3 moved to Apache DeltaSpike, but our project still works with Seam3. I just amazing, how one lib, can destroy Gradle compilation(other build tools works fine). I turn on --info, but my project is part of multi-project with 18 sub-projects. So --info generates many rows. I found interesting rows:

:keeper-admin:compileJava Executing task ‘:keeper-admin:compileJava’ (up-to-date check took 0.209 secs) due to:

Output file /Users/alexey/work/idea_projects/keeper/keeper-2.0/trunk/keeper-admin/build/classes/main has changed.

Output file /Users/alexey/work/idea_projects/keeper/keeper-2.0/trunk/keeper-admin/build/dependency-cache has changed.

Output file /Users/alexey/work/idea_projects/keeper/keeper-2.0/trunk/keeper-admin/build/classes/main/ru/softlogic/keeper/admin/bean/system/CashSourceBean.class has been removed. Compiling with JDK Java compiler API. :keeper-admin:compileJava (Thread[main,5,main]) completed. Took 1.871 secs.

How i can do successful compile?

If you can provide a minimal and self-contained example that demonstrates the problem, we’ll have a look. If you don’t know what the purpose of ‘solder-tooling’ is, perhaps you don’t even need it on the compile class path.

Let’s see my simple example(project structure):

solder-gradle
|---src
    |---main
        |---java
            |---tmp
                 |---HelloWorld.java
|---build.gradle
|---gradlew
|---gradlew.bat

This is my HelloWorld.java:

package tmp;
  import java.io.*;
public class HelloWorld {
   public static void main(String args[]) {
  System.out.println("Hello world");
 }
 }

This is my build.gradle:

apply plugin: 'java'
  group = "org.group"
  repositories {
    mavenCentral()
    mavenRepo url: 'http://repository.jboss.org/nexus/content/groups/public'
}
  task wrapper(type: Wrapper) {
    gradleVersion = '1.11'
}
  dependencies {
 //compile 'org.jboss.solder:solder-tooling:3.1.0.Final@jar'
}

After execute

./gradlew build

everithings ok, and file build/classes/main/tmp/HelloWorld.class exists.

But if i uncomment line

compile 'org.jboss.solder:solder-tooling:3.1.0.Final@jar'

and execute

./gradlew clean build --info

than, build/classes/main is empty. In info messages i see:

------------------------------------------------------------------------------------------------ … Executing task ‘:compileJava’ (up-to-date check took 0.228 secs) due to: Output file /Users/alexey/tmp/solder-gradle/build/dependency-cache has changed. Output file /Users/alexey/tmp/solder-gradle/build/classes/main has changed. Output file /Users/alexey/tmp/solder-gradle/build/classes/main/tmp/HelloWorld.class has been removed. Compiling with JDK Java compiler API. :compileJava (Thread[main,5,main]) completed. Took 0.597 secs. … ------------------------------------------------------------------------------------------------

So, HelloWorld.class is removed(and all other java classes if they should be).

How i can successful compile with solder-tooling.jar???

I guess, if we add dependency

compile 'org.jboss.solder:solder-tooling:3.1.0.Final@jar'

in any project, than folder build/classes/main will be empty always!!!

That wouldn’t be surprising, since most likely it’s a problem related to the annotation processor contained in that Jar (see my earlier answer).

It’s expected that class files are removed before recompiling.

As soon as I comment in solder-tooling, I get the following compile errror: “error: Bad service configuration file, or exception thrown while constructing Processor object: javax.annotation.processing.Processor: Provider org.jboss.logging.generator.apt.LoggingToolsProcessor not found”.

Peter, can you show me example, how i can add artifact ‘org.jboss.solder:solder-tooling:3.1.0.Final@jar’ to WEB-INF/lib in war file?

No I can’t. You’ll have to figure out what the problem is with the annotation processor in that Jar.

Thanks, Peter. I added jboss-logging-generator.jar to dependencies and classes compiled.

Peter, tell me, please, how you find a problem? I mean message:

“error: Bad service configuration file, or exception thrown while constructing Processor object: javax.annotation.processing.Processor: Provider org.jboss.logging.generator.apt.LoggingToolsProcessor not found”.

In short, if you use an annotation processor, you need to be aware of that. The error message comes from javac, not from Gradle. At the end of the day, this whole topic is about javac and annotation processors, not about Gradle.

Gradle is doing something nasty here. I’m seeing a similar problem with my annotation processor.

  1. Building from gradle produces:

11:54:51.628 [DEBUG] [org.gradle.api.internal.tasks.compile.NormalizingJavaCompiler] Compiler arguments: -d /home/rich/Moozvine/src/api/build/classes/main -g -classpath /home/rich/Moozvine/src/tools/build/libs/tools.jar:…

11:54:51.633 [INFO] [org.gradle.api.internal.tasks.compile.jdk6.Jdk6JavaCompiler] Compiling with JDK Java compiler API.

11:54:51.639 [ERROR] [system.err] error: Bad service configuration file, or exception thrown while constructing Processor object: javax.annotation.processing.Processor: Error reading configuration file

11:54:51.643 [DEBUG] [org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter] Finished executing task ‘:api:compileJava’

11:54:51.644 [LIFECYCLE] [class org.gradle.TaskExecutionLogger] :api:compileJava FAILED

  1. If I take the exact same javac command line that Gradle has logged (everything after the -d) and just run javac -d /home/rich/Moozvine/src/api/build/classes/main -g -classpath /home/rich/Moozvine/src/tools/build/libs/tools.jar:… then it builds and processes the annoatations just fine.

The org.gradle.api.internal.tasks.compile.jdk6.Jdk6JavaCompiler seems to be doing something different than the standard command line javac.

I’ve been banging my head against this wall for a day now. It’s getting to the point that I’m going to have to use an Exec task that invokes javac. :frowning:

The Java compiler API doesn’t always behave exactly the same as ‘javac’. Perhaps that contributes to your problem.

Perhaps… but it doesn’t help me fix it. :frowning:

As an end-user, the experience is simply that something builds from the command line but doesn’t build from Gradle; even though I’m using the same parameters that Gradle reports that it is using.

Whether that difference is due to wrinkles in javac, wrinkles in the compiler API or wrinkles in the way Gradle is invoking that API is opaque to me. As a user, I just need the tool to log the information that will help me fix the problem so I can move on.

If you can provide a self-contained reproducible example, I’m happy to file an issue for this. We also appreciate any contributions.

Well I have spent the last 2 hours trying to create a minimal reproducible example. In doing that I eventually ended up with two identical source trees, one of which compiled fine, the other gave the " Bad service configuration file, or exception thrown while constructing Processor object: javax.annotation.processing.Processor: Error reading configuration file" error.

The only difference between the two trees was now the .gradle directory. I rm -rf’ed that from the directory tree that wasn’t working and ran the build again. Now it works!

Somehow, something under .gradle (in the top-level project) was breaking the annotation processing. Unfortunately, I deleted it; otherwise I’d tar it up and send it to you.

The only clue I have is that shortly before it broke, I changed the package name of my annotation processor (and, therefore, the full classname that is referred to in the javax.annotation.processing.Processor file which is presumably the file the Gradle log is complaining about). My guess is that Gradle is caching some data about annotation processing and then screwing up when the classname of the processor changes.

Summary for others with similar problems:

  • Deleting the .gradle directory (and gradle --stop) fixed the problem. * The problem seemed to be caused by a rename of the annotation processor’s package.

Hard to say what’s going on here. Gradle’s Java plugin doesn’t have any annotation processing related code. One thing you can try is ‘tasks.withType(JavaCompile) { options.fork = true }’, which is a good idea anyway.