efegokdemir commented on issue #861: URL: https://github.com/apache/maven-shade-plugin/issues/861#issuecomment-6045349705
I traced the Maven 3.6.0 execution path. `MojoExecutor.ensureDependenciesAreResolved` resolves dependencies for every project in the session when configuring an aggregating mojo, and `LifecycleDependencyResolver` writes the result back through `MavenProject.setResolvedArtifacts`; MavenProject also exposes the filtered result through mutable cached state. That overlaps with Shade reading `project.getArtifacts()` and matches the reported zero-artifact symptom. This is covered by the still-open Maven Core issue [MNG-5960](https://github.com/apache/maven/issues/7730) (the source path is visible in [Maven 3.6.0 MojoExecutor](https://github.com/apache/maven/blob/maven-3.6.0/maven-core/src/main/java/org/apache/maven/lifecycle/internal/MojoExecutor.java#L254-L280) and [LifecycleDependencyResolver](https://github.com/apache/maven/blob/maven-3.6.0/maven-core/src/main/java/org/apache/maven/lifecycle/internal/LifecycleDependencyResolver.java#L180-L184)). I do not see a safe Shade-only workaro und: independently rebuilding the dependency set would risk changing Maven scope/conflict-resolution semantics, while serializing Shade executions would not prevent another aggregator mojo from mutating the project. I’m releasing this issue rather than proposing an ineffective plugin-side patch; the reproducer should be addressed in Maven Core or coordinated with that fix. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
