Hey all I am new to gradle and currently trying to port my maven setup to gradle. I encounter issues using the javadocJar task and would like to ask if you can point me in the right direction?
build.gradle: Plugily Paste
project on github (uses maven): Plugily-Projects/ScoreboardLib at development (github.com)
Basically my question is now:
Can I define the javadoc process to only javadoc classes without dependencies and build the doc jar or are there any other options?
(Removing the causing dependdencies from the code solves the javadoc building… but that would mean I can’t use the dependency anymore which would be bad…)
This is a bug in the JavaDoc tool I’d say.
It does not happen with Maven because it additionally sets the -sourcepath option.
But according to the JavaDoc tool documentation that option should only have an effect if you tell the tool to document a package. Then it should look in the specified path, otherwise in the current path and beneath.
As concrete files to be documented are specified, the JavaDoc tool should not search for packages and thus the option should be irrelevant. And even if packages were given, it seems the tool finds Java files that are in JARs on the classpath, which also does not sound correct per-se. Besides that it is imho a packaging error of that protocol support library, as they package their .java files alongside their .class files.
So I would recommend you report a bug to that library, so they do not package the sources, a second one to the JavaDoc tool, that considers these files, and as a work-around you can set the -sourcepath option for the javdoc task like
Hey, thank you for your answer. The mentioned workaround did not work for me it throws the same issue. Yeah of course I could report it but I don’t think that they are fixing it soon. The project seems to be a bit inactive. May its a issue on jitpack itself as it gets them from jitpack?
JitPack generally is broken by design imho and should be avoided wherever possible, except for short-term testing with specific branches or commits, but not for production releases, but that’s a different topic.
While JitPack manipulates things like artifact coordinates and metadata files (and sometimes fails to do it properly) which files are packed into an artifact should usually not be affected, but a problem of the actual build, but I didn’t inspect that project whether it is the case or not.
Whether it will be fixed in that library and in the JavaDoc tool is a separate topic of course, but nevertheless it should imho be reported, because if it is not reported, it for sure does not get fixed.
But yeah, both projects will probably not fix it short-term, which is why I provided you with the work-around too. I tested it in your project, so it does work, maybe you did not do it correctly? I didn’t give the full code, because I just tested it quickly hackily with addStringOption and the hard-coded local path to the respective directory, but the proper work-around should use addFileOption.
If it does not work how you tried it, maybe provide the build script variant you tried, and also the build/tmp/javadoc/javadoc.options file.
options.addFileOption './src' adds an option named ./src without a value.
You need to add a file option named sourcepath with the directory to the source code as value as I showed in my comment before.
Besides that, you should not add a relative path as value, as there is no guarantee about the current working directory. It is not necessarily the project directory.