|
Benjamin, could you provide us a patch? I really should stop commenting on other people's issues... Not sure if I am willing to spend time on this. I will check out its complexity during the weekend and let you know if I go for it or not. Vincent, if there is urgent need to get this done, I can't help. If it can wait a couple of weeks, well, I will try. As a hotfix, annotating the mojo with @execute phase=test-compile to create the test classes by a forked Maven invocation should do. Benjamin, it is not so urgent, I am happy to waiting for it Should be closed by |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Well, why to depend on the compiled classes of the project anyway? Regarding the currently build project, you have something better than just bytecode, the sources! Unlike the class files, the sources carry documentation that javadoc can use to inherit documentation (e.g. for overriden methods). So, instead of
I would rather aim at
However, just including the project main sources on the source path has an unwanted effect: One will likely get Javadoc for production classes if those happen to reside in the same package as some test class (a common scenario for organizing tests). This effect stems from the fact, that the plugin currently specifies which packages to document and javadoc cannot distinguish from main and test sources. But that is easily solved: Instead of listing up packages, the plugin simply needs to scan all test source directories for Java files and put those in an arg file.