Re: maven-apache-parent 22 ETA?

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Re: maven-apache-parent 22 ETA?

rfscholte
On Mon, 05 Aug 2019 22:14:41 +0200, Christopher <[hidden email]>  
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: [hidden email]
> For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]