On Mon, 05 Aug 2019 22:14:41 +0200, Christopher <[email protected]>
wrote:
Hi,
In spite of the specific title, I actually have several questions
(note, I'm not currently subscribed to list, so feel free to CC me
directly on any responses):
1. What's the timeline for the maven-apache-parent 22? It seems a bit
overdue, especially given all the plugins that have been updated since
21 was released.
I'm hoping https://github.com/apache/maven-apache-parent/pull/1 gets
merged in. Can somebody merge that before 22 is released? Two people
reviewed and approved it 10 months ago.
This is one of the about 90 subproject of the ASF Maven Project, I guess
this one simply lost attention.
It requires someone from the the team to have a look at it again, see if
everything is up to date and do the release.
On the other hand, this parent is the parent for the Maven project,
shouldn't you be using the apache parent?
2. I had another idea for adding something like the following to
satisfy the use case for cross-compilation using newer JDKs without
specifying `-bootstrapclasspath`. Would this be worth a pull request
(or a committer could just add it if they think it's a good idea).
<properties>
<compilerCompliance>8</compilerCompliance>
</properties>
<profile>
<id>jdk-release-flag</id>
<activation>
<jdk>[9,)</jdk>
</activation>
<properties>
<maven.compiler.release>${compilerCompliance}</maven.compiler.release>
</properties>
</profile>
It is indeed true that with JDK 9+ it is better to use the release flag,
but this proposal might not work when working with toolchains. I'd prefer
to leave it up to the project itself.
3. And finally... I noticed that JDK 11's javadoc is not getting the
backports of the JDK 12 upstream patches... even though 11 is supposed
to be an LTS version. This causes javadocs generated with
maven-javadoc-plugin to be broken for projects which aren't using
modules. Specifically, the following bug appears to not be patched in
11 that affect all users of maven-javadoc-plugin. Some plugin goals
output (such as javadoc:aggregate) can be patched after building, but
others (javadoc:jar) can't easily be patched, because the broken
javadoc jar would have to be disassembled to patch and reconstructed.
Is there a workaround for these planned by the maven-javadoc-plugin
developers, or is the hope that upstream will fix it eventually?
https://bugs.openjdk.java.net/browse/JDK-8215291 (severe loss of
functionality when building non-modular code... which is most java
code today... using JDK 11)
https://bugs.openjdk.java.net/browse/JDK-8227487 (a minor regression
also not patched in 11)
https://bugs.openjdk.java.net/browse/JDK-8214856 (another bug, not
sure how serious, also not patched in 11)
So here's the misunderstanding and confusion regarding LTS. There's only
LTS on the vendor ($$$ or €€€) specific JDK 11 releases.
OpenJDK 11 was never marked as LTS. Once OpenJDK 12 was released, there
would be no further development on OpenJDK 11.... unless one of the
vendors would port back their changes on OpenJDK 11 and would release it.
As far as I know only Redhat did that.
AdoptOpenJDK tries to fix that by backporting to their OpenJDK 11 fork.
So it becomes much more important to know with which JDK verisons you are
working.
That said: the maven-javadoc-plugin has quite some integration tests
trying to cover all kind of combinations. If the JDK itself is broken,
then there's probably not much we can do. If you see an issue that's not
yet covered by an integration test, please provide a minimal project.
We've discovered that javac tool was quite stable since Java 9, but the
javadoc tool comes with new surprises. It seems like it had less
attention, also from its users (probably most were waiting for 11 and
hoped everything would still work, so they missed a lot of feedback).
Robert
Thanks,
Christopher
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
