10

I have a maven-based GWT project that includes Guava. I am running into trouble with Maven trying (and failing) to compile the sources that it finds in guava-gwt*.jar:

could not parse error message:   symbol:   static setCountImpl
  location: class
/home/mark/.m2/repository/com/google/guava/guava-gwt/11.0.1/guava-gwt-11.0.1.jar(com/google/common/collect/AbstractMultiset.java):100: error: cannot find symbol
    return setCountImpl(this, element, count);
           ^

I can't figure out why Maven thinks it needs to compile the sources in guava-gwt. Here's what my project looks like:

├── pom.xml
└── src
    ├── main
    │   └── java
    └── test
        └── java
            └── SomeTestFile.java

SomeTestFile.java

import com.google.common.collect.ArrayListMultimap;
import com.google.common.collect.Multimap;
import org.junit.Test;

public class SomeTestFile {
    @Test
    public void testMethod() {
        Multimap<Integer, String> someMap = ArrayListMultimap.create();
        someMap.put(5, "five");
        System.out.println(someMap);
    }

}

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>guava-problem</groupId>
    <artifactId>guava-problem</artifactId>
    <version>1.0</version>

    <dependencies>

        <dependency>
            <groupId>com.google.guava</groupId>
            <artifactId>guava</artifactId>
            <version>11.0.1</version>
        </dependency>

        <dependency>
            <groupId>com.google.guava</groupId>
            <artifactId>guava-gwt</artifactId>
            <version>11.0.1</version>
        </dependency>

        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.8.2</version>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <configuration>
                    <source>1.6</source>
                    <target>1.6</target>
                </configuration>
            </plugin>
        </plugins>
    </build>

</project>

I have already tried the following:

  • Removing the guava dependency (leaving only guava-gwt)
  • Scoping guava-gwt to provided

I'm not sure what else to try. guava-gwt includes sources because GWT will compile it into equivalent Javascript. But I don't want Maven to try to compile these sources.

Edit

Just a note...the test files themselves have no real need for guava-gwt over guava since they are compiled and run as Java code (they don't go through the GWT compile step). I don't need guava-gwt specifically for these tests but it needs to be available for my actual GWT client code.

Full Maven Output

mark@mark-peters:~/devel/guava-problem$ mvn -V clean test-compile
Apache Maven 2.2.1 (rdebian-1)
Java version: 1.7.0
Java home: /usr/lib/jvm/jdk1.7.0/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux" version: "2.6.32-38-generic" arch: "amd64" Family: "unix"
[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[INFO] Building Unnamed - guava-problem:guava-problem:jar:1.0
[INFO]    task-segment: [clean, test-compile]
[INFO] ------------------------------------------------------------------------
[INFO] [clean:clean {execution: default-clean}]
[INFO] Deleting file set: /home/mark/devel/guava-problem/target (included: [**], excluded: [])
[INFO] [resources:resources {execution: default-resources}]
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory /home/mark/devel/guava-problem/src/main/resources
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Nothing to compile - all classes are up to date
[INFO] [resources:testResources {execution: default-testResources}]
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory /home/mark/devel/guava-problem/src/test/resources
[INFO] [compiler:testCompile {execution: default-testCompile}]
[INFO] Compiling 1 source file to /home/mark/devel/guava-problem/target/test-classes
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Compilation failure

/home/mark/.m2/repository/com/google/guava/guava-gwt/11.0.1/guava-gwt-11.0.1.jar(com/google/common/collect/AbstractMultiset.java):[19,0] error: cannot find symbol

could not parse error message:   symbol:   static setCountImpl
  location: class
/home/mark/.m2/repository/com/google/guava/guava-gwt/11.0.1/guava-gwt-11.0.1.jar(com/google/common/collect/AbstractMultiset.java):100: error: cannot find symbol
    return setCountImpl(this, element, count);
           ^

could not parse error message:   symbol:   method setCountImpl(AbstractMultiset<E>,E,int)
  location: class AbstractMultiset<E>
  where E is a type-variable:
    E extends Object declared in class AbstractMultiset
/home/mark/.m2/repository/com/google/guava/guava-gwt/11.0.1/guava-gwt-11.0.1.jar(com/google/common/collect/AbstractMultiset.java):105: error: cannot find symbol
    return setCountImpl(this, element, oldCount, newCount);
           ^


[INFO] ------------------------------------------------------------------------
[INFO] For more information, run Maven with the -e switch
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 2 seconds
[INFO] Finished at: Tue Feb 21 12:49:42 EST 2012
[INFO] Final Memory: 18M/212M
[INFO] ------------------------------------------------------------------------

Edit (again)

Having found that the source of the problem has nothing to do with Guava but rather the Maven version (see my answer), I've updated the title and question to try to be a lot more helpful to future users.

Community
  • 1
  • 1
Mark Peters
  • 80,126
  • 17
  • 159
  • 190
  • In the first place why do you want guava-gwt source ? you can use the jar without the source in maven ? – Sajan Chandran Feb 15 '12 at 17:40
  • 2
    Have you checked to compile/run on command line via mvn clean package ? Or are you using this in Eclipse/Netbeans ? – khmarbaise Feb 15 '12 at 17:43
  • @Sajan: The sources are included in the normal Jar because GWT compiles Java source into Javascript. I am not pulling the source jar from Maven, this is just the standard `guava-gwt` jar. – Mark Peters Feb 15 '12 at 17:43
  • 1
    @khmarbaise: I am having this problem *only* when compiling from the command line (in my case, `mvn clean test-compile`) at this point. I use IntelliJ which seems to be able to build without issue. Thanks, I've clarified this in the question. – Mark Peters Feb 15 '12 at 17:44
  • 1
    The exact pom file along with the test class above compiles fine on my Windows box with maven 3.0.4. What is the maven version? Does the pom have other goals which may be relevant? – Raghuram Feb 20 '12 at 17:08
  • @Raghuram: Interesting, I was able to reproduce with exactly the project structure I describe above. I'm going to see what Maven version I'm using. – Mark Peters Feb 20 '12 at 20:26
  • @Raghuram: Aha! I indeed don't have the problem with Maven 3, but do with the latest version of Maven 2. I'm going to try to see if I can find a bugfix listing for this issue to add for posterity, but if you are inclined to post your comment as an answer that would be the one I'd inclined to award the bounty to. – Mark Peters Feb 20 '12 at 20:50

5 Answers5

22

tl;dr

Maven 2 and JDK 7 are incompatible, as Maven tries to parse javac output which has changed in JDK 7.

Full explanation

Raghuram's note that this worked for him in Maven 3+ took me down the road of exploring this not as a config problem but as an actual Maven problem. I started doing more testing and found that this problem:

  • Occurs with Java 7 and Maven 2.2.1
  • Does not occur with Java 7 and Maven 3+
  • Does not occur with Java 6 and Maven 2.2.1

So at that point it became clear to me that the "could not parse error message" errors were relevant, and the problem probably had less to do with the guava-gwt compilation occurring and more to do with Maven not knowing how to handle the errors properly.

To test this I created a separate Maven project that has nothing to do with Guava:

├── pom.xml
└── src
    └── main
        └── java
            └── ClassWithWarnings.java

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>maven-problem</groupId>
    <artifactId>maven-problem</artifactId>
    <version>1.0</version>

    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <configuration>
                    <compilerArgument>-Xlint:all</compilerArgument>
                    <showWarnings>true</showWarnings>
                    <showDeprecation>true</showDeprecation>
                </configuration>
            </plugin>
        </plugins>
    </build>
</project>

ClassWithWarnings.java

public class ClassWithWarnings implements java.io.Serializable {}

Lo and behold, Maven tanks on this project as well when using Java 7:

mark@mark-peters:~/devel/maven-problem$ mvn -V compile
Apache Maven 2.2.1 (rdebian-1)
Java version: 1.7.0
Java home: /usr/lib/jvm/jdk1.7.0/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux" version: "2.6.32-38-generic" arch: "amd64" Family: "unix"
[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[INFO] Building Unnamed - maven-problem:maven-problem:jar:1.0
[INFO]    task-segment: [compile]
[INFO] ------------------------------------------------------------------------
[INFO] [resources:resources {execution: default-resources}]
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory /home/mark/devel/maven-problem/src/main/resources
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Compiling 1 source file to /home/mark/devel/maven-problem/target/classes
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Compilation failure
could not parse error message: warning: [options] bootstrap class path not set in conjunction with -source 1.3
/home/mark/devel/maven-problem/src/main/java/ClassWithWarnings.java:1: warning: [serial] serializable class ClassWithWarnings has no definition of serialVersionUID
public class ClassWithWarnings implements java.io.Serializable {}
       ^


[INFO] ------------------------------------------------------------------------
[INFO] For more information, run Maven with the -e switch
[INFO] ------------------------------------------------------------------------
[INFO] Total time: < 1 second
[INFO] Finished at: Tue Feb 21 13:10:47 EST 2012
[INFO] Final Memory: 14M/150M
[INFO] ------------------------------------------------------------------------

With Java 6, it still reports the warnings, but can parse the Javac output and so doesn't tank:

Apache Maven 2.2.1 (rdebian-1)
Java version: 1.6.0_20
Java home: /usr/lib/jvm/java-6-openjdk/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux" version: "2.6.32-38-generic" arch: "amd64" Family: "unix"
[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[INFO] Building Unnamed - maven-problem:maven-problem:jar:1.0
[INFO]    task-segment: [compile]
[INFO] ------------------------------------------------------------------------
[INFO] [resources:resources {execution: default-resources}]
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory /home/mark/devel/maven-problem/src/main/resources
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Compiling 1 source file to /home/mark/devel/maven-problem/target/classes
[WARNING] /home/mark/devel/maven-problem/src/main/java/ClassWithWarnings.java:[1,7] [serial] serializable class ClassWithWarnings has no definition of serialVersionUID

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: < 1 second
[INFO] Finished at: Tue Feb 21 13:18:39 EST 2012
[INFO] Final Memory: 9M/150M
[INFO] ------------------------------------------------------------------------

So it seems as if the problem was that the latest Maven 2 release doesn't know how to parse error messages from Java 7+ javac. Maven 3 does. I still haven't found documentation of this and am a little surprised that Maven doesn't give a warning when it tries to compile against a JDK version that it doesn't know how to support properly.

Mark Peters
  • 80,126
  • 17
  • 159
  • 190
2

For a similar problem I upgraded maven-compiler-plugin to a later version.

wolfc
  • 2,159
  • 1
  • 15
  • 7
2

Happened to us, that we received the exact same failure, but with gradle instead of maven. After switching from ArrayListMultimap to LinkedListMultimap to error is gone. So it seems, that in version 11.0.2 at least the ArrayListMultimap is broken.

Nemrael
  • 21
  • 1
2

Converting my comment to an answer...

The exact pom file along with the test class above compiles fine on my Windows box with maven 3.0.4.

The problem could be with the maven version that you are using. Or there could be other maven goals in the actual pom, which may be causing an issue.

Raghuram
  • 51,854
  • 11
  • 110
  • 122
1

It appears that it's not trying to compile the Guava libraries, but without the full maven build log we can't tell.

Judging by the information you've posted so far, it would appear instead that you have two incompatible versions of a class or library on your classpath during compilation.

I'm going to try your test project and see if I can give you more information.

EDIT:

So I've found a couple of interesting things. First, I was able to get your project to work without a whole lot of fanfare :(

I changed your pom to:

    <dependency>
        <groupId>com.google.guava</groupId>
        <artifactId>guava</artifactId>
        <version>11.0.1</version>
        <scope>compile</scope>
    </dependency>
    <dependency>
        <groupId>com.google.guava</groupId>
        <artifactId>guava-gwt</artifactId>
        <version>11.0.1</version>
        <scope>runtime</scope>
    </dependency>
    <dependency>
        <groupId>junit</groupId>
        <artifactId>junit</artifactId>
        <version>4.8.2</version>
        <scope>test</scope>
    </dependency>

By default though, your test file will not run. I refactored it so it was is now named SomeTestFileTest which will actually run the test.

I'm running Maven v2.2.1 on OSX. I also cleaned out my ~/.m2/repository before starting. I suggest you try the same: nuke your local repository folder and retry your build. If that doesn't work, let me know what version of maven you're running.

Jonathan S. Fisher
  • 8,189
  • 6
  • 46
  • 84
  • Thank you for the answer. First let me apologize for the weird test file name; it wasn't important to the question that the test actually run since the failure was in compilation so I didn't think about giving it a good name. Now, regarding your change to use `runtime` instead of `provided`. I'm pretty new to integrating GWT and Maven, but my undestanding is that if I have GWT code that needs `guava-gwt` (or any other library) then it needs to be marked as `provided` so that the GWT compiler can compile against it. If it's marked as `runtime` I don't think my GWT code can reference it. – Mark Peters Feb 20 '12 at 20:31
  • You mention that it doesn't appear that it's trying to compile Guava, and that instead it looks like incompatible files. Can you expand on that? The error posted is a compile error when trying to compile `AbstractMultiset.java` from the `guava-gwt` jar, so I'm not sure if I agree with your first point. I'll try to post more of the Maven output. – Mark Peters Feb 20 '12 at 20:32
  • Provided means "provided by the container at runtime, but we will add it to the compile classpath temporarily." Runtime means "included in my war/ear at runtime, but not available to the compiler." If the guava-gwt jar is in your server's lib directory, the proper scope is provided. If the guava-gwt jar is required to compile your code, it needs to be set compile scope. If it's not need to compile, and not provided by the sever, but is required to run the app, the proper scope is runtime. – Jonathan S. Fisher Feb 20 '12 at 21:49
  • btw, did you try erasing your local repository? – Jonathan S. Fisher Feb 20 '12 at 21:52
  • With GWT it's more complicated. GWT compiles Java source into Javascript, and does so during the maven build. The Javascript it produces is self-sufficient and client side, having nothing to do with the container. It needs certain jars (specifically containing source files) at compilation time so that it can convert it into Javascript. To do so it piggy-backs on the maven scopes but none are a perfect match. Provided is the closest because it will do no good to have `guava-gwt` available to the server code. – Mark Peters Feb 20 '12 at 22:32
  • I gave cleaning the local repo a shot; I got the same result unfortunately! Thanks for your attention so far (if you haven't seen the question comments yet, it seems that the problem doesn't occur in Maven 3+) – Mark Peters Feb 20 '12 at 22:34
  • Can you post your entire maven build output from start to finish? – Jonathan S. Fisher Feb 21 '12 at 16:47
  • Looking again at the full maven output really helped me reach the conclusions that I just added as an answer. Thanks a lot for your help, sorry for taking so long to get the full output to you (long weekend). – Mark Peters Feb 21 '12 at 18:28