On 02/20/2014 07:09 PM, Mikolaj Izdebski wrote:
Java 8 has a very strict parser for javadocs, and any error or nuisance
causes build failure -- almost all packages fail to build with Java 8
due to various errors in javadocs.
In some cases we can probably fix javadoc problems and forward patches
upstream, but we have many legacy packages for which we can't push any
patches upstream. I don't see how in reality we can fix all packages
we have. The only good solution I can think of is disabling javadocs.
+1
I agree that making javadocs optional is a good thing and way to go.
I did some testing with Java 8 and maven-javadoc-plugin and it seems
like disabling doclint (-Dadditionalparam=-Xdoclint:none) can solve the
problem for people who wants to keep javadoc subpackages as they are now
and don't want to spend time fixing them.
Michal
My proposal is making javadoc subpackages optional, which means that
for some Java packages they could be disabled depending on maintainer
decision. Legacy packages with dead upstreams would be able to
disable javadocs (no one should try to develop anything depending on
such packages, so that's perfectly OK IMO). For packages which have
active upstreams we can fix javadocs and forward patches, or disable
javadoc packages, report the problem upstream and wait for them to fix
it.
The main reasons for making javadoc optional are:
1. Java 8 problems, as explained above.
2. Storage. I took a typical set of 265 Java source packages. When
all binary RPMs were installed they took about 1.5 GB of storage.
Javadocs themselves take 1.3 GB, everything else is just around 250 MB.
3. Build time. Javadoc generation usually takes more time than
compilation. Javadoc tool needs a lot of memory, an can be very slow,
especially on ARM or POWER where there is no JIT. There are cases
where javadoc generation accounts for more than 90 % of build time.
I am looking to hear your opinion on this matter (positive or negative)
and if there is some positive feedback then I would like to submit this
proposal as a system-wide change for Fedora 21.
--
java-devel mailing list
java-devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/java-devel
