hboutemy commented on PR #11549: URL: https://github.com/apache/maven/pull/11549#issuecomment-3658931231
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 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 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 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 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) Is there a common sample modular sources project that is used to test all these changes in a common tam 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? 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 time, then I overlooked many topics, sorry @desruisseaux if my questions seem sometimes redundant with what you already write: 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]
