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
:bpmn-utils:javadoc
C:\Documents and Settings\name\.gradle\caches\artifacts-13\filestore\
com.vaadin\vaadin.8.0\jar\a8565de65480c3fde69468774792f97d4214c678\vaadin-6.8.
0.jar(com/vaadin/ui/ClientWidget.java):26: error: cannot access Paintable
import com.vaadin.terminal.gwt.client.Paintable;
^
1 error
bad source file: C:\Documents and Settings\name\.gradle\caches\arti
facts-13\filestore\com.vaadin\vaadin.8.0\jar\a8565de65480c3fde69468774792f97d4
214c678\vaadin-6.8.0.jar(com/vaadin/terminal/gwt/client/Paintable.java)
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
rcepath.
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':bpmn-utils:javadoc'.
> Javadoc generation failed.
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 Paintable.java. I haven’t had a chance to followup on this idea.
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.
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.
@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).