Upgrade to beta-5

[gnodet]

@desruisseaux this PR fails with a bunch of unit tests failing ...
Do you have a more up-to-date branch ?

[desruisseaux]

I will check tomorrow (Wednesday).

[desruisseaux]

I'm investigating the integration test failures. But in the meantime, I think that we will need in any cases:

• A release of maven-plugin-tools beta 2 with Maven 4.0.0 beta 4 dependency replaced by beta 5. It seems to be the only change needed.
• A release of maven-plugin-testing beta 2. No change needed apparently.

[desruisseaux]

Tested the integration tests of both this upgrade-beta-5 branch and the JPMS branch. The following are tests failing in upgrade-beta-5 which were already fixed in the JPMS branch.

• MCOMPILER-203-processorpath/pom.xml
• MCOMPILER-272/pom.xml
• MCOMPILER-391-processorpath-dep-mgmt/pom.xml
• MCOMPILER-395-processorpath-exclude-deps/pom.xml
• MCOMPILER-503-processorpath-duplicated-deps/pom.xml
• MCOMPILER-522-unresolvable-dependency/pom.xml

The following are tests that are failing in both this upgrade-beta-5 branch and the JPMS branch (they were previously passing in the JPMS branch):

• jdk16-annotation/pom.xml
• MCOMPILER-346/pom.xml

The cause of the later is (reformatted for readability):

org.eclipse.aether.resolution.ArtifactResolutionException:
        The following artifacts could not be resolved:
        org.jenkins-ci.main:remoting:jar:3.2 (present, but unavailable):
        Could not find artifact org.jenkins-ci.main:remoting:jar:3.2
        in central (https://repo.maven.apache.org/maven2)
    at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:424)
    (...snip....)
Caused by: org.eclipse.aether.transfer.ArtifactNotFoundException:
        Could not find artifact org.jenkins-ci.main:remoting:jar:3.2
        in central (https://repo.maven.apache.org/maven2)

The pom.xml of that test has the following:

 <repositories>
    <repository>
      <id>repo.jenkins-ci.org</id>
      <url>https://repo.jenkins-ci.org/public/</url>
    </repository>
  </repositories>

The JAR that the test is looking for does not exist on Maven Central and exists only on the Jenkins repository. But it seems that Maven 4.0.0 beta 5 does not search in that repository despite the <repository> declaration.

[desruisseaux]

The test failure in jdk16-annotation is due to a change in Java rather than Maven: since Java 21, the annotation processor is no longer executed by default. Instead, users must set the proc:full option explicitly. This has been fixed in the JPMS branch by updating the pom.xml of the test case.

The only remaining test failure in the JPMS branch is Maven apparently not searching for org.jenkins-ci.main:remoting in the Jenkins repository (see above comment). This is apparently independent of JPMS, since the same test also fails on the upgrade-beta-5 branch.

We have a choice:

• Either backport the integration test fixes from the JPMS branch to this upgrade-beta-5 branch.
• Or start moving to the new compiler plugin now, keeping in mind that this is a major change and regressions should be expected (but will be fixed as much as possible).

Currently there is one known regression in the latter option: module-info.java can no longer be duplicated in both main and test. But this has been discussed on the mailing list and a workaround will be done for the next beta.

[gnodet]

I'm investigating the integration test failures. But in the meantime, I think that we will need in any cases:

• A release of maven-plugin-tools beta 2 with Maven 4.0.0 beta 4 dependency replaced by beta 5. It seems to be the only change needed.

I don't really understand why this upgrade/release would be required. I've upgrade other plugins (clean, resource, jar, install, deploy) without upgrading this dependency and it seems to work nicely. I'll create a PR to upgrade to beta-5, but just curious why it's needed. Or maybe not...

• A release of maven-plugin-testing beta 2. No change needed apparently.

Yes, I upgraded to beta-5.

[gnodet]

The test failure in jdk16-annotation is due to a change in Java rather than Maven: since Java 21, the annotation processor is no longer executed by default. Instead, users must set the proc:full option explicitly. This has been fixed in the JPMS branch by updating the pom.xml of the test case.

The only remaining test failure in the JPMS branch is Maven apparently not searching for org.jenkins-ci.main:remoting in the Jenkins repository (see above comment). This is apparently independent of JPMS, since the same test also fails on the upgrade-beta-5 branch.

We have a choice:

• Either backport the integration test fixes from the JPMS branch to this upgrade-beta-5 branch.
• Or start moving to the new compiler plugin now, keeping in mind that this is a major change and regressions should be expected (but will be fixed as much as possible).

Currently there is one known regression in the latter option: module-info.java can no longer be duplicated in both main and test. But this has been discussed on the mailing list and a workaround will be done for the next beta.

I'd be in favour of porting the JPMS work. This is a beta, and the sooner we switch, the more feedback we'll have.

[desruisseaux]

I don't really understand why this upgrade/release would be required. I've upgrade other plugins (clean, resource, jar, install, deploy) without upgrading this dependency and it seems to work nicely.

Just tested with beta-1, and indeed it seems to work. I though that me may have some version conflict, but it does not seem to be an issue. So we can ignore that one.

[desruisseaux]

I'd be in favour of porting the JPMS work. This is a beta, and the sooner we switch, the more feedback we'll have.

I would prefer that too. Maybe we should post on the mailing list for seeing what other peoples think? We will also need a page describing the differences compared the previous plugin. Do we do that as a new APT file in src/apt/site/?

[desruisseaux]

Reintroduced MCOMPILER-542 (the use of ASM for rewriting module-info for reproducible builds), executed only when the JDK is older than Java 22. Now working on the case of module-info.java duplicated in main and test.

[desruisseaux]

Added support for overwriting module-info.java in the tests, as did the previous compiler plugin. However, the way to support that is quite different than what Maven 3 did. I think it should be a deprecated practice.

With this change and the one in the previous comment, the main concerns expressed on the mailing list should be addressed, except <source>/<target> versus <release>. The latter would be easy to change, but I propose to see if it happens often that <source> and <release> are defined together, and if yes, identify if they are inherited from the pom that we can fix.

[desruisseaux]

Note: we still have the following a failure in src/it/MCOMPILER-346, but it seems unrelated to JPMS (I have the same test failure with the pre-JPMS compiler plugin):

Unable to resolve artifact: The following artifacts could not be resolved: org.jenkins-ci.main:remoting:jar:3.2 (present, but unavailable): Could not find artifact org.jenkins-ci.main:remoting:jar:3.2 in central (https://repo.maven.apache.org/maven2)
org.apache.maven.api.services.ArtifactResolverException: Unable to resolve artifact: The following artifacts could not be resolved: org.jenkins-ci.main:remoting:jar:3.2 (present, but unavailable): Could not find artifact org.jenkins-ci.main:remoting:jar:3.2 in central (https://repo.maven.apache.org/maven2)
    at org.apache.maven.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:85)
    at org.apache.maven.api.services.ArtifactResolver.resolve(ArtifactResolver.java:76)
    at org.apache.maven.internal.impl.DefaultDependencyResolver.resolve(DefaultDependencyResolver.java:194)
    at org.apache.maven.plugin.compiler.AbstractCompilerMojo.resolveDependencies(AbstractCompilerMojo.java:1556)
    (…snip…)
Caused by: org.eclipse.aether.resolution.ArtifactResolutionException: The following artifacts could not be resolved: org.jenkins-ci.main:remoting:jar:3.2 (present, but unavailable): Could not find artifact org.jenkins-ci.main:remoting:jar:3.2 in central (https://repo.maven.apache.org/maven2)
    at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:424)
    at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:201)
    at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifacts(DefaultRepositorySystem.java:223)
    at org.apache.maven.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:76)
    at org.apache.maven.api.services.ArtifactResolver.resolve(ArtifactResolver.java:76)
    at org.apache.maven.internal.impl.DefaultDependencyResolver.resolve(DefaultDependencyResolver.java:194)
    at org.apache.maven.plugin.compiler.AbstractCompilerMojo.resolveDependencies(AbstractCompilerMojo.java:1556)
    (…snip…)
Caused by: org.eclipse.aether.transfer.ArtifactNotFoundException: Could not find artifact org.jenkins-ci.main:remoting:jar:3.2 in central (https://repo.maven.apache.org/maven2)
    at org.eclipse.aether.connector.basic.ArtifactTransportListener.transferFailed(ArtifactTransportListener.java:42)
    at org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:456)
    at org.eclipse.aether.util.concurrency.RunnableErrorForwarder.lambda$wrap$0(RunnableErrorForwarder.java:66)
    (…snip…)

[desruisseaux]

Other strange behaviour observed with Maven 4: in the it/jdk16-annotation test, the test-compile phase is executed twice. I added a workaround in the compiler plugin for ignoring the second invocation when the project ID is the same (for avoiding issues with the annotation processor being executed twice, which was causing it/jdk16-annotation to fail).

EDIT: it appears to be an error in the test, which was declaring an <execution> with the wrong <id>.

[gnodet]

Could you create a PR from your fork, i think we can close this one in favor of the new one.

[desruisseaux]

Done: #271