1

I'm trying to track down an issue with a multi-project build. I've reduced my issue to a pretty straightforward setup.


Gradle Info

------------------------------------------------------------
Gradle 3.2.1
------------------------------------------------------------

Build time:   2016-11-22 15:19:54 UTC
Revision:     83b485b914fd4f335ad0e66af9d14aad458d2cc5

Groovy:       2.4.7
Ant:          Apache Ant(TM) version 1.9.6 compiled on June 29 2015
JVM:          1.7.0_40 (Oracle Corporation 24.0-b56)
OS:           Linux 2.6.32-642.11.1.el6.i686 i386

Directory Structure

  • root/
    • HelloWorld/
      • src/
        • com.dishbreak.testlab
          • HelloWorld.java
    • settings.gradle
    • build.gradle

Note I'm not using the Maven SDL, because the legacy project I'm trying to do doesn't.


HelloWorld.java

package com.dishbreak.testlab;

public class HelloWorld {

    public static void main(String[] args) {
        System.out.println("Hello world!");

    }

}

settings.gradle

include ":HelloWorld"

build.gradle

subprojects {
    apply plugin: "java"
    sourceSets {
        main {
            java {
                srcDirs = ['src/']
            }
        }
    }
    compileJava {
        options.verbose = true
    }
}

Command Output

[admin@box Plugins]$ gradle build
:HelloWorld:compileJava FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':HelloWorld:compileJava'.
> Cannot find javac resource bundle for locale en_US

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

BUILD FAILED

Total time: 0.87 secs

For the record, trying with the --info flag gives me the following relevant output?

20:26:07.077 [INFO] [org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter] Executing task ':HelloWorld:compileJava' (up-to-date check took 0.002 secs) due to:
  No history is available.
20:26:07.077 [DEBUG] [org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter] Executing actions for task ':HelloWorld:compileJava'.
20:26:07.077 [INFO] [org.gradle.api.internal.changedetection.changes.RebuildIncrementalTaskInputs] All input files are considered out-of-date for incremental task ':HelloWorld:compileJava'.
20:26:07.077 [DEBUG] [org.gradle.api.internal.tasks.compile.NormalizingJavaCompiler] Compiler arguments: -source 1.7 -target 1.7 -d /redacted/root/HelloWorld/build/classes/main -verbose -g /redacted/root/HelloWorld/src/com/dishbreak/testlab/HelloWorld.java -XDuseUnsharedTable=true
20:26:07.078 [INFO] [org.gradle.api.internal.tasks.compile.JdkJavaCompiler] Compiling with JDK Java compiler API.
20:26:07.078 [DEBUG] [org.gradle.api.internal.tasks.execution.ResolveTaskArtifactStateTaskExecuter] Removed task artifact state for {} from context.
20:26:07.078 [DEBUG] [org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter] Finished executing task ':HelloWorld:compileJava'
20:26:07.079 [LIFECYCLE] [class org.gradle.internal.buildevents.TaskExecutionLogger] :HelloWorld:compileJava FAILED

For the sake of curiosity, I tried running the javac command directly, and it does produce a class file that runs!

[admin@box HelloWorld]$ javac -source 1.7 -target 1.7 -d /redacted/root/HelloWorld/build/classes/main -verbose -g /redacted/root/HelloWorld/src/com/dishbreak/testlab/HelloWorld.java -XDuseUnsharedTable=true
[parsing started RegularFileObject[/redacted/root/HelloWorld/src/com/dishbreak/testlab/HelloWorld.java]]
[parsing completed 14ms]
[search path for source files: .]
[search path for class files: /opt/java/jdk1.7.0_40/jre/lib/resources.jar,/opt/java/jdk1.7.0_40/jre/lib/rt.jar,/opt/java/jdk1.7.0_40/jre/lib/sunrsasign.jar,/opt/java/jdk1.7.0_40/jre/lib/jsse.jar,/opt/java/jdk1.7.0_40/jre/lib/jce.jar,/opt/java/jdk1.7.0_40/jre/lib/charsets.jar,/opt/java/jdk1.7.0_40/jre/lib/jfr.jar,/opt/java/jdk1.7.0_40/jre/classes,/opt/java/jdk1.7.0_40/jre/lib/ext/sunjce_provider.jar,/opt/java/jdk1.7.0_40/jre/lib/ext/sunpkcs11.jar,/opt/java/jdk1.7.0_40/jre/lib/ext/localedata.jar,/opt/java/jdk1.7.0_40/jre/lib/ext/zipfs.jar,/opt/java/jdk1.7.0_40/jre/lib/ext/sunec.jar,/opt/java/jdk1.7.0_40/jre/lib/ext/dnsns.jar,.]
[loading ZipFileIndexFileObject[/opt/java/jdk1.7.0_40/lib/ct.sym(META-INF/sym/rt.jar/java/lang/Object.class)]]
[loading ZipFileIndexFileObject[/opt/java/jdk1.7.0_40/lib/ct.sym(META-INF/sym/rt.jar/java/lang/String.class)]]
[checking com.dishbreak.testlab.HelloWorld]
[loading ZipFileIndexFileObject[/opt/java/jdk1.7.0_40/lib/ct.sym(META-INF/sym/rt.jar/java/lang/AutoCloseable.class)]]
[loading ZipFileIndexFileObject[/opt/java/jdk1.7.0_40/lib/ct.sym(META-INF/sym/rt.jar/java/lang/System.class)]]
[loading ZipFileIndexFileObject[/opt/java/jdk1.7.0_40/lib/ct.sym(META-INF/sym/rt.jar/java/io/PrintStream.class)]]
[loading ZipFileIndexFileObject[/opt/java/jdk1.7.0_40/lib/ct.sym(META-INF/sym/rt.jar/java/io/FilterOutputStream.class)]]
[loading ZipFileIndexFileObject[/opt/java/jdk1.7.0_40/lib/ct.sym(META-INF/sym/rt.jar/java/io/OutputStream.class)]]
[wrote RegularFileObject[/redacted/root/HelloWorld/build/classes/main/com/dishbreak/testlab/HelloWorld.class]]

And when I try running the class file that I compiled automatically?

[admin@box root]$ java -cp HelloWorld/build/classes/main/ com.dishbreak.testlab.HelloWorld
Hello world!

A few questions...

  • Why is the verbose output on the compile task not giving me anything in Gradle?
  • Why is Gradle asking for a resource bundle when my code doesn't use one?
  • Why does the javac command work when I type it out directly?
  • Is there anything else I need to do since I'm not using the Maven SDL?
Vishal Kotcherlakota
  • 1,134
  • 4
  • 13
  • 36
  • unless you have a really really good reason, please stick to the very sensible gradle (and maven) directory conventions. `src/main/java` for java `src/main/resources` for resources (also `src/test/java`, `src/test/resrouces`) – lance-java Jan 24 '17 at 09:46
  • I agree! In my case, the reason is that reshuffling the 20+ projects involved would break the existing Ant build tasks, which my Gradle files depend on. :) I picked Gradle over Maven specifically because I understood that Gradle was more flexible on the directory structure. I get that moving away from the standard structure opens me up to more work, but moving a legacy project to a new directory structure because the build tool thinks it's sensible just doesn't make a whole lot of sense to me. – Vishal Kotcherlakota Jan 24 '17 at 20:11
  • That's a good enough reason and gradle can certainly adapt to your needs. Where do you keep your resources then? (eg xml files). Are they muddled together with your java sources? – lance-java Jan 24 '17 at 21:12
  • What's confusing me is that the specific project doesn't have any resources--it's more or less a wrapper for some WSDL-generated code. Does gradle consider the WSDLs resources? – Vishal Kotcherlakota Jan 25 '17 at 01:36

1 Answers1

0

You can add this as a sibling to java script block

resources {
    filter {
        return it.exists()
    }
}
Trash Can
  • 6,608
  • 5
  • 24
  • 38
  • Interesting. How does that help? – Vishal Kotcherlakota Jan 24 '17 at 05:43
  • It filters out anything that isn't there – Trash Can Jan 24 '17 at 05:45
  • I understand that. :-) I should be more specific. I don't understand why I'd need that when every other project I've done hasn't needed a resources block like that. Not trying to be difficult, just trying to understand the why. – Vishal Kotcherlakota Jan 24 '17 at 05:59
  • It is just gradle. It assumes your project structure to follow maven project structure convention `src/main/java` for soure code and `src/main/resources` for non-java resources. You have to be explicit if you want a different structure – Trash Can Jan 24 '17 at 06:33