由于StringIndexOutOfBoundsException导致maven-javadoc-plugin失败

Question

I always got StringIndexOutOfBoundsException issue when running mvn javadoc:javadoc . Anyone know about this error? Below is the full stack trace:

[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building Java Tool 0.2
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] >>> maven-javadoc-plugin:2.9:javadoc (default-cli) @ osgl-tool >>>
[INFO]
[INFO] --- maven-enforcer-plugin:1.0:enforce (enforce-maven) @ osgl-tool ---
[INFO]
[INFO] <<< maven-javadoc-plugin:2.9:javadoc (default-cli) @ osgl-tool <<<
[INFO]
[INFO] --- maven-javadoc-plugin:2.9:javadoc (default-cli) @ osgl-tool ---
[INFO]
Loading source files for package org.osgl.exception...
Loading source files for package org.osgl.util.algo...
Loading source files for package org.osgl.util...
Loading source files for package org.osgl.web.util...
Loading source files for package org.osgl...
Constructing Javadoc information...
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 3.890s
[INFO] Finished at: Tue Feb 18 21:05:48 EST 2014
[INFO] Final Memory: 10M/242M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-javadoc-plugin:2.9:javadoc (default-cli) on project osgl-tool: An error has occurred in JavaDocs report generation:
[ERROR] Exit code: 1 - java.lang.StringIndexOutOfBoundsException: String index out of range: -22
[ERROR] at java.lang.String.substring(String.java:1937)
[ERROR] at java.lang.String.substring(String.java:1904)
[ERROR] at com.sun.tools.javac.jvm.ClassReader.simpleBinaryName(ClassReader.java:958)
[ERROR] at com.sun.tools.javac.jvm.ClassReader.readEnclosingMethodAttr(ClassReader.java:930)
[ERROR] at com.sun.tools.javac.jvm.ClassReader.readMemberAttr(ClassReader.java:909)
[ERROR] at com.sun.tools.javac.jvm.ClassReader.readClassAttr(ClassReader.java:1053)
[ERROR] at com.sun.tools.javac.jvm.ClassReader.readClassAttrs(ClassReader.java:1067)
[ERROR] at com.sun.tools.javac.jvm.ClassReader.readClass(ClassReader.java:1560)
[ERROR] at com.sun.tools.javac.jvm.ClassReader.readClassFile(ClassReader.java:1658)
[ERROR] at com.sun.tools.javac.jvm.ClassReader.fillIn(ClassReader.java:1845)
[ERROR] at com.sun.tools.javac.jvm.ClassReader.complete(ClassReader.java:1777)
[ERROR] at com.sun.tools.javac.code.Symbol.complete(Symbol.java:384)
[ERROR] at com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:766)
[ERROR] at com.sun.tools.javac.code.Symbol$ClassSymbol.flags(Symbol.java:698)
[ERROR] at com.sun.tools.javadoc.ClassDocImpl.getFlags(ClassDocImpl.java:103)
[ERROR] at com.sun.tools.javadoc.ClassDocImpl.isAnnotationType(ClassDocImpl.java:114)
[ERROR] at com.sun.tools.javadoc.DocEnv.isAnnotationType(DocEnv.java:572)
[ERROR] at com.sun.tools.javadoc.DocEnv.getClassDoc(DocEnv.java:544)
[ERROR] at com.sun.tools.javadoc.PackageDocImpl.getClasses(PackageDocImpl.java:154)
[ERROR] at com.sun.tools.javadoc.PackageDocImpl.addAllClassesTo(PackageDocImpl.java:170)
[ERROR] at com.sun.tools.javadoc.RootDocImpl.classes(RootDocImpl.java:178)
[ERROR] at com.sun.tools.doclets.internal.toolkit.AbstractDoclet.startGeneration(AbstractDoclet.java:96)
[ERROR] at com.sun.tools.doclets.internal.toolkit.AbstractDoclet.start(AbstractDoclet.java:64)
[ERROR] at com.sun.tools.doclets.formats.html.HtmlDoclet.start(HtmlDoclet.java:42)
[ERROR] at com.sun.tools.doclets.standard.Standard.start(Standard.java:23)
[ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[ERROR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[ERROR] at java.lang.reflect.Method.invoke(Method.java:597)
[ERROR] at com.sun.tools.javadoc.DocletInvoker.invoke(DocletInvoker.java:269)
[ERROR] at com.sun.tools.javadoc.DocletInvoker.start(DocletInvoker.java:143)
[ERROR] at com.sun.tools.javadoc.Start.parseAndExecute(Start.java:340)
[ERROR] at com.sun.tools.javadoc.Start.begin(Start.java:128)
[ERROR] at com.sun.tools.javadoc.Main.execute(Main.java:41)
[ERROR] at com.sun.tools.javadoc.Main.main(Main.java:31)
[ERROR]
[ERROR] Command line was: R:\jdk\jre\..\bin\javadoc.exe @options @packages
[ERROR]
[ERROR] Refer to the generated Javadoc files in 'c:\p\java-tool\target\site\apidocs' dir.
[ERROR] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException

Notes

1. Yes, I am using eclipse compiler
2. The answers to question Using Eclipse compiler instead of javac results in javadoc crash don't help out
3. Now I switched to java compiler, but it still doesn't work
4. Here is a single java file (which is okay to compile) that will fail when running javadoc on it: https://github.com/greenlaw110/java-tool/blob/master/src/main/java/org/osgl/_.java
5. pom.xml issue with cycling dependencies is NOT relevant to this issue. Removing the cyclic dependencies following Aleksandr's answer does make the project able to build and even able to build with 'mvn package -Pdist', but it doesn't solve the javadoc issue. The reason you can build and generate the javadoc is I've removed the issue packages with <excludePackageNames>org.osgl:org.osgl.util</excludePackageNames> . Try to take that line out of the pom.xml and run mvn clean package -Pdist again to reproduce the javadoc issue
6. I choose _ as the class name following the underscore.js project. It is used to aggregate some common utilities into a meta-alike namespace. For people who doesn't like, just use Osgl to replace _ as they alias each other
7. It's really weird that after I cloned the project in my linux box on digital ocean and it does built success. Something must be wrong with my windows dev machine!
8. Issue resolved! Removing the cyclic dependency does solve the issue. My guess is that cyclic dependency brings back old osgl-tool pom.xml version which use eclipse to compile the code and conflict with javadoc

Answer 1

Your problem is in your pom.xml file. You are declaring the org.osgl:osgl-storage dependency which has dependency on org.osgl:osgl-tool - the same project that you are trying to build, but with different version. Exclude this transitive dependency and it is should work.

<dependency>
    <groupId>org.osgl</groupId>
    <artifactId>osgl-storage</artifactId>
    <version>0.3-SNAPSHOT</version>
    <scope>provided</scope>
    <exclusions>
        <exclusion>
            <groupId>org.osgl</groupId>
            <artifactId>osgl-tool</artifactId>
        </exclusion>
    </exclusions>
</dependency> 

Answer 2

If you do mvn dependency:tree you'll see that org.osgl:osgl-storage:jar:0.3-SNAPSHOT is bringing org.osgl:osgl-tool:jar:0.3-SNAPSHOT as a dependency too, which will conflict with you own version of this same artifact.

[INFO] org.osgl:osgl-tool:jar:0.4.1-SNAPSHOT
[INFO] +- junit:junit:jar:4.10:test
[INFO] |  \- org.hamcrest:hamcrest-core:jar:1.1:test
[INFO] +- commons-codec:commons-codec:jar:1.8:compile
[INFO] +- com.carrotsearch:junit-benchmarks:jar:0.7.2:test
[INFO] \- org.osgl:osgl-storage:jar:0.3-SNAPSHOT:provided
[INFO]    +- org.osgl:osgl-tool:jar:0.3-SNAPSHOT:provided
[INFO]    \- org.osgl:osgl-logging:jar:0.2:provided

All you need to do is tell Maven to exclude this transitive dependency:

<dependency>
  <groupId>org.osgl</groupId>
  <artifactId>osgl-storage</artifactId>
  <version>0.3-SNAPSHOT</version>
  <scope>provided</scope>
  <exclusions>
    <exclusion>
      <groupId>org.osgl</groupId>
      <artifactId>osgl-tool</artifactId>
    </exclusion>
  </exclusions>
</dependency>

What happened is you had two versions of the same artifact together (your 0.4.1-SNAPSHOT and the other 0.3-SNAPSHOT version). The solution above excludes the 0.3-SNAPSHOT version brought transitively by org.osgl:osgl-storage:jar:0.3-SNAPSHOT.

---

You also created a cyclic dependency by making your org.osgl:osgl-tool depend on org.osgl:osgl-storage, since org.osgl:osgl-storage originally depends on org.osgl:osgl-tool.

org.osgl:osgl-storage <──┐ ... you added this dependency
     │                   │
     └──> org.osgl:osgl-tool

Your org.osgl.util.IO class is the one that depends on org.osgl.storage.ISObject and org.osgl.storage.impl.SObject . You should avoid cyclic dependencies if you don't want further issues.

---

EDIT: Regarding the _ class, it has a valid name. But if such name is being used to avoid repeating a long class name, like in your example:

void foo(_.Func2<Integer, String> f) {
    F2<Integer, String> newF = _.f2(f);
    ...
}

then you should consider renaming the class and using static imports :

import static org.osgl.Osgl.*; // Osgl instead of _

void foo(Func2<Integer, String> f) { // Func2 statically imported
    F2<Integer, String> newF = f2(f); // f2 statically imported
    ...
}