Add module-aware resource handling for modular sources

[ascheman]

Summary

• Automatically inject module-aware resource roots for projects using modular <sources> layout
• Resources are picked up from src/<module>/main/resources and src/<module>/test/resources
• Issue warnings when explicit legacy <resources> configuration is ignored in favor of modular defaults

Problem

Projects using Maven 4.x modular sources (<source><module>org.foo.bar</module></source>) had to manually configure maven-resources-plugin for each module. Resources from the modular layout paths were not automatically discovered.

Solution

When a project defines at least one module in <sources>:

1. Modular resource roots are automatically injected for each module
2. Legacy <resources> from Super POM defaults are silently replaced
3. Explicit legacy <resources> configuration triggers a ModelProblem warning

Test plan

• testModularSourcesInjectResourceRoots - verifies resource injection for multi-module projects
• testModularSourcesWithExplicitResourcesIssuesWarning - verifies warnings are issued when legacy resources are ignored

[ascheman]

Hi @desruisseaux,

I'd be happy to get some feedback from you (cf. my mail to the dev mailing list as of today), before making this an official PR.
It affects the handling of resources as we recently as issue on my Java Modules examples.

Thanks
Gerd

addressed

[ascheman]

Could someone please add the backport-to-4.0.x label as it would be great to have this change one of the next RCs?

[gnodet]

I think we should reject any project that mixes <resource> and <source> elements, I don't see that as a valid use case.

[gnodet]

I think we should reject any project that mixes <resource> and <source> elements, I don't see that as a valid use case.

I think this should even be done in org.apache.maven.impl.model.DefaultModelValidator.

[ascheman]

I think we should reject any project that mixes <resource> and <source> elements, I don't see that as a valid use case.

I think this should even be done in org.apache.maven.impl.model.DefaultModelValidator.

Thanks for the feedback, @gnodet.
Personally, I am with you, cf. my lengthy discussion about the topic in Confluence. I was proposing two approaches (warnings/lenient vs. errors/strict).
How could we get a stronger vote about it (with more opinions than just yours and mine)?

Having said that, this PR is just about the first part of the problem (make Maven Core handle resources at all). Perhaps we can focus here on that feature?

[desruisseaux]

I would also suggest to reject any project that mixes <resource> and <source> elements. Since <source> is new in Maven 4, we are not yet breaking any existing project. If this policy is too strict, we can relax later. The opposite is much more difficult to do.

[desruisseaux]

Thanks! I will wait a little bit in case there is some comment, and if none I propose to merge this weekend.

[github-actions]

@desruisseaux Please assign appropriate label to PR according to the type of change.

[ascheman]

Thanks a lot for merging, @desruisseaux.
I still hope for the backport-to-4.0.x label to ensure the change becomes part of the next Maven 4.0.0 RC.

[desruisseaux]

Yes I thought about that. But as you mentioned on the slack channel, the work done in this pull request could be generalized. I thought that what this PR does for resources, the same thing could be done for tests. I'm thinking to refactor the ResourceHandler class in something that does not handle resources in a special way, but instead does the same thing in a uniform way for all combinations of <lang> and <scope>. If agreed, I would propose to merge on 4.0.x the generalized version.

[ascheman]

Yes I thought about that. But as you mentioned on the slack channel, the work done in this pull request could be generalized.

Yes, I have a Phase 2 implementation in my mind which would be more general.

Nevertheless, the feature would already be helpful (and I'd be eager to get it in the next Release Candidate for Maven 4.0).

I thought that what this PR does for resources, the same thing could be done for tests. I'm thinking to refactor the ResourceHandler class in something that does not handle resources in a special way, but instead does the same thing in a uniform way for all combinations of <lang> and <scope>. If agreed, I would propose to merge on 4.0.x the generalized version.

Sounds good, perhaps we can join forces in the next weeks to get a combined implementation?

[desruisseaux]

Maybe you can go ahead with phase 2 when you have time. Looking on the wiki page, I suggest the following changes:

• Instead of record ModuleConfig(boolean hasMain, boolean hasTest, boolean hasMainResources, boolean hasTestResources), handle any combination of <lang> and <scope> with something like Map<Something, Boolean>. The mapping to legacy <resources>, <testResources>, etc. would still special cases, but the rest (e.g., generate automatically a Source object) can be handled by a universal code.
• Remove rule R3, i.e., accept duplicated source for scope='X', lang='Y', module='Z'. The compiler plugin 4 already accepts that, the need for multi-source directories in Maven 3 was strong enough to justify an external plugin, and Maven 3 already accepts that for resources if I remember right.

[ascheman]

I have raised a new issue (#11612) for further discussion.