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
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.
I've split the slf4j package into subpackages.
The api, simple and nop submodules were left in the main package, in order not to break many packages
that depend on slf4j.
Submodules that were moved into subpackages:
If some of your packages require one of those, please change your BuildRequires accordingly.
Most of the packages shouldn't be affected. If your package needs just api, nop or simple
submodules or you use mvn() style BuildRequires, no changes should be necessary.
Is there any projects we can propose for this year Google Summer of Code
programme. I have noticed there are no any single project idea proposed in
Java for Fedora (but there are few from last year)
It may be great chance to get new contributors for Java SIG.
I think it is well past time to have retired maven-ant-tasks. I just
doesn't support maven 3 and upstream appears to be dead - no scm commits
for 10 months. I'm planning on retiring by Friday unless someone else
wants to flog this dead horse.
# repoquery --whatrequires maven-ant-tasks
but I don't know about BuildRequires.
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
is available 4.7.0
please consider upgrading
>Data: 04/03/2014 17.00
>Ogg: [fedora-java] Lucene major update to 4.6.1
>I'm updating lucene from version 3.6.2 to 4.6.1.
>This update will break some packages due to API changes.
>Packages that may be affected, but FTBFS regardless of lucene version:
>The rest of dependent packages built fine.
>Please try to update to the new API, it would be better if we didn't have to
>a compat package.
>java-devel mailing list
I'm updating lucene from version 3.6.2 to 4.6.1.
This update will break some packages due to API changes.
Packages that may be affected, but FTBFS regardless of lucene version:
The rest of dependent packages built fine.
Please try to update to the new API, it would be better if we didn't have to create
a compat package.