[MJAVADOC-815] Aggregate goal misses skipped reactor modules when resuming build

[jira-importer]

Richard Eckart de Castilho opened MJAVADOC-815 and commented

When resuming a build using -rf, then the javadoc:aggregate goal is not injected with the reactor modules that are skipped (are before the module being resumed from).

That means the JavaDoc for those skipped modules is not included in the aggregate.

I can imagine that to happen when I build using -pl to build individual modules, but if I resume, I would expect all the reactor modules that have already been covered and are being resumed over to be part of the reactor modules that are provided to the javadoc plugin.

---

Affects: 3.10.0

[jira-importer]

Michael Osipov commented

I wonder whether this is a plugin issue or rather a Maven Core issue. gnodet, Maarten Mulders, Tamas Cservenak, WDYT?

[jira-importer]

Maarten Mulders commented

I wonder whether this is a plugin issue or rather a Maven Core issue. gnodet, Maarten Mulders, Tamas Cservenak, WDYT?

Try running the plugin with a Maven 4 beta and see if it behaves the same. Given the major overhaul of the Reactor w.r.t. how -rf works, I guess that this is an issue in Core that is resolved in Maven 4.

[jira-importer]

Richard Eckart de Castilho commented

It may be in general a lame excuse, but in the context where I ran into this issue, it seems I can currently not upgrade to Maven 4 because there are plugins in the build that are not yet compatible with it.+

Just mentioning that because I could imagine that more people might be stuck with Maven 3 for a while longer.

[jira-importer]

Maarten Mulders commented

Don't worry, I don't see it as a lame excuse.

If your finding is indeed an issue in Core, not in the Maven Javadoc Plugin - as Michael Osipov and I are thinking - then there is, unfortunately, no way this can be fixed in the Maven Javadoc Plugin.

Would it be possible for you to extract the problem from where you observe it (probably a large, closed-source project?) to a minimal example which illustrates the problem? It might be easier to run that minimal reproducer with Maven 4 and observe if the problem is still there.

[jira-importer]

Richard Eckart de Castilho commented

It is an open source project: https://uima.apache.org - specifically this branch: apache/uima-uimaj#391

I believe it is either Tycho or the p2-resolver-plugin that is causing the problem, although I see neither one on the stack trace when trying to build with Maven 4.0.0-beta-4.

[ERROR] Internal error: java.lang.IllegalArgumentException: Unknown extensible enum value 'xml' -> [Help 1]
org.apache.maven.InternalErrorException: Internal error: java.lang.IllegalArgumentException: Unknown extensible enum value 'xml'
    at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:157)
    at org.apache.maven.cli.MavenCli.execute(MavenCli.java:981)
    at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:291)
    at org.apache.maven.cli.MavenCli.main(MavenCli.java:208)
    at jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
    at java.lang.reflect.Method.invoke(Method.java:580)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:255)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:201)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:361)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:314)
Caused by: java.lang.IllegalArgumentException: Unknown extensible enum value 'xml'
    at org.apache.maven.api.services.ExtensibleEnumRegistry.lambda$require$0(ExtensibleEnumRegistry.java:33)
    at java.util.Optional.orElseThrow(Optional.java:403)
    at org.apache.maven.api.services.ExtensibleEnumRegistry.require(ExtensibleEnumRegistry.java:33)
    at org.apache.maven.internal.impl.DefaultTypeRegistry.lambda$require$1(DefaultTypeRegistry.java:94)
    at java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1708)
    at org.apache.maven.internal.impl.DefaultTypeRegistry.require(DefaultTypeRegistry.java:87)
    at org.apache.maven.internal.impl.DefaultTypeRegistry.lookup(DefaultTypeRegistry.java:80)
    at org.apache.maven.internal.impl.DefaultPackagingRegistry.lookup(DefaultPackagingRegistry.java:88)
    at org.apache.maven.internal.impl.model.DefaultLifecycleBindingsInjector.injectLifecycleBindings(DefaultLifecycleBindingsInjector.java:69)
    at org.apache.maven.internal.impl.model.DefaultModelBuilder.build(DefaultModelBuilder.java:575)
    at org.apache.maven.internal.impl.model.DefaultModelBuilder.build(DefaultModelBuilder.java:198)
    at org.apache.maven.project.DefaultProjectBuilder$BuildSession.doBuild(DefaultProjectBuilder.java:825)
    at org.apache.maven.project.DefaultProjectBuilder$BuildSession.lambda$build$6(DefaultProjectBuilder.java:794)
    at java.util.concurrent.FutureTask.run(FutureTask.java:317)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
    at java.lang.Thread.run(Thread.java:1583)

Sorry for "hijacking" this issue to mention this...

Just for sake of completeness: In order to see the effect, you would run mvn clean install -rf :uimaj in the project root. That will resume the build from the root POM which includes the JavaDoc aggregate.