Javadoc packages
by Mikolaj Izdebski
We'll have to move to Java 8 in Fedora sooner or later. I did some
testing of Maven and Ant stacks regards that and most of things seem
to be working well, except for javadoc.
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.
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.
--
Mikolaj Izdebski
9 years, 2 months
eclipse 4.3.2 plans?
by Orion Poplawski
Any schedule for an update to eclipse 4.3.2?
Thanks,
Orion
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 http://www.nwra.com
9 years, 3 months
Question about servlet apis tomcat/jboss
by Orion Poplawski
I maintain olfs which has been compiling fine against tomcat-servlet-3.0-api.
Latest version however fails. Apparently upstream uses servlet 2.5.
I see we have a jboss-servlet-2.5-api package now, and it compiles fine
against that. What would be the implications switching to that? Does it then
need to be run in jboss, or could it still be used in tomcat?
Sorry, I don't know much about this area....
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 http://www.nwra.com
9 years, 3 months
Maven update in rawhide
by Mikolaj Izdebski
I've just updated Maven in rawhide to next upstream version -- 3.2.1.
Please let me know if you encounter any issues.
--
Mikolaj Izdebski
IRC: mizdebsk
9 years, 3 months
maven-wagon split
by Mikolaj Izdebski
Package maven-wagon has been split into multiple subpackages in rawhide.
Wagon has several modules, which have different dependencies and are not
strongly connected with other. Splitting maven-wagon package was aimed
at optimizing dependencies.
For now maven-wagon has requires on all subpackages, so packages can
still require maven-wagon main package for now, but it is highly
recommended to migrate them to require one or more of wagon subpackages
to reduce the number of unneeded dependencies. In future all packages
will have to require modules they use.
Packages that use mvn(*)-style requires and build-requires will
immediately benefit from the split, without any change to them.
Packages which currently require or build-require maven-wagon and
therefore are possibly affected by this change:
aether
aether-connector-okhttp
antlr-maven-plugin
apache-commons-jci
apache-rat
eclipse-m2e-core
maven
maven2
maven-eclipse-plugin
maven-idea-plugin
maven-indexer
maven-javadoc-plugin
maven-jxr
maven-plugin-bundle
maven-project-info-reports-plugin
maven-remote-resources-plugin
maven-repository-builder
maven-shared-io
maven-site-plugin
maven-wagon-ahc
mercury
shrinkwrap-resolver
--
Mikolaj Izdebski
IRC: mizdebsk
9 years, 3 months
Why no Class-Path manifest attribute?
by Florian Weimer
It seems that a significant number of JAR files under /usr/share/java do
not declare their dependencies using the Class-Path manifest attribute.
As a result, the dependencies need to be collected manually and included
with the final link (typically, in the -classpath argument to
/usr/bin/java). This is mightily inconvenient and leaks implementation
details across Java RPM package boundaries. (I don't think
%jpackage_script does recursive linking, unlike the JVM.)
rpmlint flags usage of the Class-Path attribute:
http://fedoraproject.org/wiki/Packaging:Java#class-path-in-manifest
But why?
--
Florian Weimer / Red Hat Product Security Team
9 years, 4 months
