28

Trying to build an alexa (amazon:echo) skills set. At the same time, trying to use this experience as a learning testbed for dependency injection through dagger 2. However, building the package using maven-2 cmd:

mvn assembly:assembly -DdescriptorId=jar-with-dependencies package'.

to generate a zip jar with the complete dependencies produces the following exception trace:

[INFO] ------------------------------------------------------------------------
[INFO] Building Echo Device Client 1.0
[INFO] ------------------------------------------------------------------------
[INFO] 
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ echo-device-client ---
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory /Users/apil.tamang/Dropbox/Git/echo-device-client/src/main/resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.3:compile (default-compile) @ echo-device-client ---
[INFO] Changes detected - recompiling the module!
[WARNING] File encoding has not been set, using platform encoding UTF-8, i.e. build is platform dependent!
[INFO] Compiling 46 source files to /Users/apil.tamang/Dropbox/Git/echo-device-client/target/classes
An exception has occurred in the compiler (1.8.0_60). Please file a bug at the Java Bug Database (http://bugreport.java.com/bugreport/) after checking the database for duplicates. Include your program and the following diagnostic in your report.  Thank you.
java.lang.IllegalStateException: endPosTable already set
        at com.sun.tools.javac.util.DiagnosticSource.setEndPosTable(DiagnosticSource.java:136)
        at com.sun.tools.javac.util.Log.setEndPosTable(Log.java:350)
        at com.sun.tools.javac.main.JavaCompiler.parse(JavaCompiler.java:667)
        at com.sun.tools.javac.main.JavaCompiler.parseFiles(JavaCompiler.java:950)
        at com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.<init>(JavacProcessingEnvironment.java:892)
        at com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.next(JavacProcessingEnvironment.java:921)
        at com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:1187)
        at com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1170)
        at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:856)
        at com.sun.tools.javac.main.Main.compile(Main.java:523)
        at com.sun.tools.javac.api.JavacTaskImpl.doCall(JavacTaskImpl.java:129)
        at com.sun.tools.javac.api.JavacTaskImpl.call(JavacTaskImpl.java:138)

The initial compilation happens fine, and all tests are run and successfully executed. I feel like it is during 'linking' the dependencies that things go south. Please take a look at this file to see the console output during the build.

My question is if it's worth a shot to try generate the dependencies using a different way. I don't know much about maven for that purpose. Is there a patch or something out there that can be used? Do you think it's even possible to come up with a workaround? I would like to be able to continue to use the dagger 2 framework for building this project.

apil.tamang
  • 2,545
  • 7
  • 29
  • 40

6 Answers6

20

The issue is described in the bug report JDK-8067747:

(by Jan Lahoda)

To my knowledge, there are two aspects to this bug:

  1. the javac bug that it crashes with an exception. I am working on this, but please note that javac won't compile the input when this is fixed, it will throw an appropriate exception from the Filer (see below).

  2. what appears to be a maven bug: when the project is compiled with "clean install", an annotation processor will generate a source file into "target/generated-sources/annotations". When the incremental compilation is done, this generated file is passed to javac as an input, and the annotation processor will try to generate it again, which is not allowed.

This implies that when the maven bug is fixed, javac’s bug of reporting the problem with an inappropriate exception becomes irrelevant. However, given the actual date of Maven 2’s end-of-life, I doubt that you can expect to find a fix or patch for it.

Community
  • 1
  • 1
Holger
  • 285,553
  • 42
  • 434
  • 765
  • 1
    From the docs on maven: "Usage of the assembly:assembly, assembly:attached, assembly:directory, and assembly:directory-inline are deprecated, since they wreak havoc with normal build processes and promote non-standard build practices." I have a feeling that a different utility command may resolve the issue I'm having. Will post a resolution if I ever get past it. In the meantime, what are your thoughts? – apil.tamang Apr 05 '16 at 11:07
  • 20
    tl;dr - `mvn clean` – RobEarl Feb 17 '17 at 11:43
  • 2
    I've faced this on Maven 3.6.2. And `mvn clean` had no effect on his. Finally only `false` helped me. – RAM237 Apr 24 '20 at 21:08
  • To add some context to 2): this might not be a bug in maven itself and it might be a bug with a maven plugin you are using. A proprietary project I've been working on uses a maven plugin to do some codegen and that plugin was adding $(builddir)/generated-sources/ as a source root. That was causing the .java files in $(builddir)/generated-sources/annotations, where javac writes code generated via annotation, to be added to the list of source files passed to javac. This in turn causes the "endPosTable already set" exception since javac assumes source files that it generates won't be inputs. – Oliver O'Halloran Jun 07 '22 at 10:23
10

As explained in this issue, a workaround is to disable useIncrementalCompilation:

<plugin>
    <artifactId>maven-compiler-plugin</artifactId>

    <configuration>
        <useIncrementalCompilation>false</useIncrementalCompilation>
    </configuration>
</plugin>
laffuste
  • 16,287
  • 8
  • 84
  • 91
1

I have encountered the same error with a project that was built and tested by Maven and JDK 1.8.0_121. In the original configuration the project was first cleaned via mvn clean, then built using mvn install -projectSpecificParameters and finally tested with a separate mvn install -otherProjectSpecificParameters. This configuration resulted in the error mentioned in the question.

After changing the order of the stages (first testing and then building) and adding a clean goal to the build command to clean up the built state after the tests the error was not reproducible anymore.

zovits
  • 906
  • 16
  • 27
1

In my case this happened while generating JPA metadata files with the maven-processor-plugin plug-in. I produced the files only once with a special Maven profile and added them to the source folder.

As noted in the bug report this happens when an existing file should compiled again. The solution is the delete the compiled files before the maven-processor-plugin execution. E.g.:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-clean-plugin</artifactId>
    <executions>
        <execution>
            <id>clean-jpa-model</id>
            <phase>generate-sources</phase>
            <goals>
                <goal>clean</goal>
            </goals>
            <configuration>
                <filesets>
                    <fileset>
                        <directory>
                            ${project.basedir}/src/main/java
                        </directory>
                        <includes>
                            <include>**/model/*_.java</include>
                        </includes>
                    </fileset>
                </filesets>
                <excludeDefaultDirectories>true</excludeDefaultDirectories>
            </configuration>
        </execution>
    </executions>
</plugin>
<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>3.8.0</version>
    <executions>
        <!--precompilation to find annotations and classed needed by the maven processor plugin for hibernate-jpamodelgen-->
        <execution>
            <id>compile-maven-processor</id>
            <goals>
                <goal>compile</goal>
            </goals>
            <phase>process-sources</phase>
            <configuration>
                <showDeprecation>false</showDeprecation>
                <showWarnings>false</showWarnings>
                <includes>
                    <include>**/model/*.java</include>
                </includes>
            </configuration>
        </execution>
    </executions>
</plugin>
<plugin>
    <groupId>org.bsc.maven</groupId>
    <artifactId>maven-processor-plugin</artifactId>
    <version>3.3.3</version>
    <executions>
        <execution>
            <id>generate-jpa-model</id>
            <goals>
                <goal>process</goal>
            </goals>
            <phase>generate-sources</phase>
            <configuration>
                <includes>
                    <include>**/model/*.java</include>
                </includes>
                <processors> 
                    <processor>org.hibernate.jpamodelgen.JPAMetaModelEntityProcessor</processor>
                </processors>
                    <outputDirectory>${project.basedir}/src/main/java</outputDirectory>
            </configuration>
        </execution>
    </executions>
    <dependencies>
        <dependency>
            <groupId>org.hibernate</groupId>
            <artifactId>hibernate-jpamodelgen</artifactId>
            <version>${hibernate.version}</version>
            <scope>runtime</scope>
        </dependency>
    </dependencies>
</plugin>
k_o_
  • 5,143
  • 1
  • 34
  • 43
0

I'm not sure if this can help. For my case, I had the same problem with open-jdk 8u91, I installed oracle-jdk and I could run the project after mvn clean compile. The problem was I must switched between JDKs for each run and building it once again with maven.

EDIT: after struggling about two days with it I found it is a result of mismatch between maven and jdk. My IDE used maven 3.0.5 as bundled maven.

Solution: In your IDE you should change your maven home directory from bundled maven to your current version for example /usr/share/maven. ( for me current version was 3.3.9)

Community
  • 1
  • 1
Oxobo
  • 513
  • 1
  • 5
  • 13
0

This error can happen with annotation processors as well as during compilation. I ran into this a couple of times with maven-processor-plugin:3.3.3 / Maven 3.8.x.

Holger's answer and Lahoda's analysis are correct, however turning off incremental builds isn't a silver bullet for when this error is observed, and won't work if the problem is related to the annotation processing.

When org.bsc.maven:maven-processor-plugin::process runs (assuming generate-sources phase), it looks for sources in configured source roots, and writes generated sources into another configured source root (outputDirectory configuration element). The problems happen when the annotation processor re-reads the generated files as input source files.

With the default configuration

  • generated sources are written into target/generated-sources/apt
  • only main project sources are considered (src/main/java)

So things tend to work fine, because generated sources are not re-ingested for processing.

In cases when we also need to generate sources from files generated by other plugins, we need to include those in the annotation processing as well. Default configuration won't support that, as you would typically generate into something under target/generated-sources (e.g., target/generated-sources/db). The obvious answer to adding the generated sources is to set addCompileSourceRoots to true. However, this is exactly when you going to be slapped with endPosTable already set, as this option will include the source root created by the annotation processor as an input to itself.

The easiest solution I found for this is to keep addCompileSourceRoots to false, and list all additional source roots explicitly. For example, this is for generating meta-model classes for OpenJPA:

<plugin>
    <groupId>org.bsc.maven</groupId>
    <artifactId>maven-processor-plugin</artifactId>
    <version>${bsc.maven.version}</version>
    <executions>
        <execution>
            <id>process</id>
            <goals>
                <goal>process</goal>
            </goals>
            <phase>generate-sources</phase>
            <configuration>
                <additionalSourceDirectories>target/generated-sources/db</additionalSourceDirectories>
                <addCompileSourceRoots>false</addCompileSourceRoots> <!-- not really needed as that's the default -->
                <compilerArguments>-Aopenjpa.source=7 -Aopenjpa.metamodel=true</compilerArguments>
                <processors>
                    <processor>org.apache.openjpa.persistence.meta.AnnotationProcessor6</processor>
                </processors>
            </configuration>
        </execution>
    </executions>
    <dependencies>
        <dependency>
            <groupId>org.apache.openjpa</groupId>
            <artifactId>openjpa</artifactId>
            <version>${openjpa.version}</version>
        </dependency>
    </dependencies>
</plugin>
Pawel Veselov
  • 3,996
  • 7
  • 44
  • 62