gnodet commented on PR #11549: URL: https://github.com/apache/maven/pull/11549#issuecomment-3659170535
> thank you @gnodet and @desruisseaux for your explanations: > > * [modular-sources compiler IT](https://github.com/apache/maven-compiler-plugin/tree/master/src/it/modular-sources) also helped me a lot > * I still need to dig into https://github.com/Geomatys/maven/wiki , but it's very valuable, for example https://github.com/Geomatys/maven-compiler-plugin/wiki/User-guide > > I now see the wider picture: at compile, test and jar level, I see that this modular-sources approach improvements have been done or are planned (I suppose there is an equivalent IT in Surefire and in Maven Jar Plugin? I don't see in https://github.com/apache/maven-jar-plugin/tree/master/src/it , I ignore fore now Surefire as its code is too complex for me :) ) I'm not sure about which changes will be required in surefire yet. I don't know that code base well either. > I'm still not yet completely convinced at install/deploy level: I'll try to dig into my feeling to be more actionable whatever I discover when going more in-depth > > no modular sources IT in https://github.com/apache/maven-install-plugin/tree/master/src/it nor https://github.com/apache/maven-deploy-plugin/tree/master/src/it : this is one of my biggest concerns for now This should not require any change at all. Install / deploy just take attached artifacts and delegate to the resolver for installing / deploying. This very PR is exactly about being able to attach those generated artifacts to the project, without being limited to the same artifactId. This is the only required change AFAIK. > I'm working on many plugins that iterate over everything that will be installed/deployed: Maven Artifact Plugin, CycloneDX and SPDX Maven Plugins Typical algorithm in a simple case is https://github.com/apache/maven-artifact-plugin/blob/maven-artifact-plugin-3.6.1/src/main/java/org/apache/maven/plugins/artifact/buildinfo/DescribeBuildOutputMojo.java#L123 = iterate over `MavenProject p : session.getProjects()`, then iterate over: > > * `p.getFile()` for the pom file > * `p.getArtifact().getFile()` for the main artifact file > * `p.getAttachedArtifacts()` for attached "sub-" artifacts > * and there is the trick in Maven 4 between the build pom (`p.getFile()`) and it associated consumer pom (one attached sub-artifact) > > Currently, GAV coordinates from Artifacts are the same as MavenProject from where they come Yes, and all the JAR/POMs for the modules will be available from `p.getAttachedArtifacts()` which returns a list of `Artifact` which will reflect everything. The only problem is if a plugin assumes that the `artifactId` is the same as the project, or something like that. > With one Maven project producing many modular jars based on their modular source structure, now I get that there will be artifactIds deducted from module name in modular sources I hope we'll check that there is no conflict between MavenProjects and attachements to a modular build, as an attachment could be done at both levels Good point. This has to be checked. This would mean we have conflicting module names somehow I suppose. @desruisseaux ? > I won't stay more theoretical, it become too long; I see here that modular sources support requires to change the whole plugins ecosystem and also Maven core, and for now we see each separate change, but not a modular sources project on all his build phases = what I'm trying to imagine and check, particularly at install and deploy levels = where it starts to hit Maven repository format and Maven Central (that is not a must for Gradle, but is for Maven) I really don't expect any change for installation/deployment. The only changes is for plugins that would need to adapt to the JPMS layout. > Is there a common sample modular sources project that is used to test all these changes in a common team approach? Then we can link to all the updates that are needed to the many plugins involved in the build lifecycle > > And last question: from Maven core perspective, does it target Maven 4.1 only, or is it expected to be backported to some previous branches? Maven-core has provided the needed infrastructure with the v4 API in 4.0.x, but most of the work is in the v4 core plugins (resources, compiler, jar...). A project migrated from Maven 3 won't see any change. > one partial conclusion in addition is that we'll need to keep https://github.com/Geomatys/maven/wiki at Maven level, at least partially, because this is really the best design doc I now see (and previously, I did not have/take time, then I overlooked many topics, sorry @desruisseaux if my questions are sometimes redundant with what you already wrote: it's such a whole new world to get in...) -- 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]
