Javadoc generation failed with vaadin dependency

I have a small project that has vaadin as dependency. The build works fine. Other projects without vaadin as dependeny can create the javadocs.

When i want to create the javadocs task, the following error is given:

src\components\bpmn-utils>gradle javadoc
> Building > :bpmn-utils:compileJava > Resolving dependencies ':bpmn-utils:compi
:bpmn-utils:compileJava UP-TO-DATE
:bpmn-utils:processResources UP-TO-DATE
:bpmn-utils:classes UP-TO-DATE
C:\Documents and Settings\name\.gradle\caches\artifacts-13\filestore\
0.jar(com/vaadin/ui/ error: cannot access Paintable
import com.vaadin.terminal.gwt.client.Paintable;
1 error
  bad source file: C:\Documents and Settings\name\.gradle\caches\arti
    file does not contain class com.vaadin.terminal.gwt.client.Paintable
    Please remove or make sure it appears in the correct subdirectory of the sou
  FAILURE: Build failed with an exception.
  * What went wrong:
Execution failed for task ':bpmn-utils:javadoc'.
> Javadoc generation failed.

Here the dependencis

dependencies {
      // Activiti
    compile group:'org.activiti', name:'activiti-engine', version:'5.9'
              // Vaadin
    compile group:'com.vaadin', name:'vaadin', version:'6.8.0'

Maybe this is a bug in vaadin? Or can i disbable the dependencies for the javadoc task?



did you find a solution to this problem? I am facing it…

Thanks in advance, mvaz

no, sorry. Still no solution known to me.

It’s unclear, at least to me, what is going on here.

You can filter the javadoc classpath by modifying the ‘classpath’ property of the ‘javadoc’ task.

We have this problem also, and have turned off javadoc generation for any projects that use Vaadin.

I notice that the compiled Vaadin JAR (not the source JAR) has both .class and .java files. For example, it has both Paintable.class and I haven’t had a chance to followup on this idea.

Yes, that seems to be the issue. I created a new Vaadin JAR without the .java files and can now generate javadoc.

    classpath -= files('C:/Users/dstine/.gradle/caches/artifacts-8/filestore/com.vaadin/vaadin/6.7.2/jar/35bb20426fa95aca422f842853c51b178dcc33e5/vaadin-6.7.2.jar')
    classpath += files('C:/DES-Temp/builds/vaadin/vaadin-6.7.2-nojava.jar')

Is it a common thing to have the .java files alongside the .class files in a jar? I don’t think I’ve seen it before.

Not in my experience. It seems this is a deliberate choice by the Vaadin team:

It seems this would only be an issue for a library that uses GWT or similar technologies.

It’s not uncommon. I’ve seen it quite a few times before. What’s appealing about this approach is that it’s simple and makes the Jar self-contained. That said, I’ve seen other tools that don’t handle this well, e.g. Intellij IDEA.

Here’s some improved code. :slight_smile:

  configurations {
  dependencies {
    compile "com.vaadin:vaadin:${vaadinVersion}"
    javadocVaadin "com.vaadin:vaadin:${vaadinVersion}:nojava"
    classpath -= files(classpath.find{ == "vaadin-${vaadinVersion}.jar"})
    classpath += configurations.javadocVaadin

Of course, I had to manually create the ‘nojava’ JAR and upload it to our instance of Artifactory.

@Peter: what, if anything, should we do here?

I think we should investigate (e.g. how does the Javadoc command line tool cope with this (although I think Gradle is using it as well)?) and support this if possible. Maybe the solution is as simple as filtering the class path passed to the Javadoc task. Certainly worth an issue.

It appears that this issue would be addressed by Peter’s suggestion to a) default the compilation sourcePath to empty and b) add a sourcePath property.

Any (relatively easy) way to make this happen prior to implementation of that suggestion?

1 Like

Maybe we can use JavaCompile#options#compilerArgs.

We had success with

    options.addStringOption("sourcepath", "")
1 Like

Dan’s workaround worked even for us :slight_smile:

@Luke packaging both java sources and compiled code within a single jar is useful in GWT projects, especially when you have some code shared between servers (running bytecode on the jvm) and clients (browsers’ js engines running the java code, previously translated to javascript).