desruisseaux commented on PR #11549:
URL: https://github.com/apache/maven/pull/11549#issuecomment-3659729535

   > I don't see in 
https://github.com/apache/maven-jar-plugin/tree/master/src/it
   
   An integration test is provided with the 
https://github.com/apache/maven-jar-plugin/pull/508 pull request, but it 
depends on this PR. For other plugins, the current state is in the link 
provided by Gerd in above comment.
   
   > Is there a common sample modular sources project that is used to test all 
these changes in a common team approach?
   
   In addition to the samples given by Gerd in above comment, I use a [clone of 
the Apache SIS project](https://github.com/Geomatys/sis/tree/maven4) where the 
Gradle build has been replaced by Maven 4. The features tested are:
   
   * Compilation of main code.
   * Compilation of test code with `module-info-patch.maven`.
   * Creation of JAR files (using the above-cited pull request).
   * Some modules targeting different Java version.
   
   The result is much better than what we could achieve by hacking the Gradle 
build. In particular, we had to create some `org.apache.sis.test` modules only 
for adding `module-info` managing the dependencies in a way that we couldn't 
achieve with Gradle configuration. This hack is gone with Maven 4, the build 
has never been so clean.
   
   > from Maven core perspective, does it target Maven 4.1 only, or is it 
expected to be backported to some previous branches?
   
   The work is backported to 4.0.x, but as Guillaume said, the changes that are 
done in Maven core are small adjustments. The biggest changes where done about 
one year ago, with the introduction of `<source>` element and the use of 
`<type>` for controlling the path where to put dependencies. Now, the largest 
works are in plugins.
   
   > we'll need to keep https://github.com/Geomatys/maven/wiki at Maven level
   
   Yes, this is also planed. I already started an updated version of the user 
guide, but I'm not sure where to put it as it is of wider scope than only the 
compiler plugin.
   
   >> 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.
   
   Indeed, a check would be desirable, maybe in a separated pull request. For 
now, the risk is slightly reduced by naming tradition (not a formal 
convention), as Maven artifacts often have a `-` in their name, which is 
illegal in a Java module name.


-- 
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]

Reply via email to