Skip to content

Add module-aware resource handling for modular sources#11700

Open
desruisseaux wants to merge 1 commit intoapache:maven-4.0.xfrom
Geomatys:sources-handling
Open

Add module-aware resource handling for modular sources#11700
desruisseaux wants to merge 1 commit intoapache:maven-4.0.xfrom
Geomatys:sources-handling

Conversation

@desruisseaux
Copy link
Contributor

This is a combination of pull requests #11505 and #11632 on master branch.

Summary: Maven 4.x introduces a unified <sources> element that supports modular project layouts (src/<module>/<scope>/<lang>). However, resource handling did not follow the modular layout - resources were always loaded from the legacy <resources> element which defaults to src/main/resources. This change implements automatic module-aware resource injection.

  • For modular projects without resource configuration in <sources>, automatically inject resource roots following the modular layout: src/<module>/main/resources and src/<module>/test/resources.
  • Resources configured via <sources> take priority over legacy <resources>.
  • Issue warnings (as ModelProblem) when explicit legacy resources are ignored.

This is a combination of pull requests apache#11505 and apache#11632 on master branch.

Summary:
Maven 4.x introduces a unified <sources> element that supports modular
project layouts (src/<module>/<scope>/<lang>). However, resource handling
did not follow the modular layout - resources were always loaded from
the legacy <resources> element which defaults to src/main/resources.
This change implements automatic module-aware resource injection.

- For modular projects without resource configuration in <sources>,
  automatically inject resource roots following the modular layout:
  src/<module>/main/resources and src/<module>/test/resources
- Resources configured via <sources> take priority over legacy <resources>
- Issue warnings (as ModelProblem) when explicit legacy resources are ignored
Copy link
Contributor

@elharo elharo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a little uncomfortable that large fixes like this are getting submitted without corresponding issues.

.map(pomFile -> build(pomFile, recursive))
.flatMap(List::stream)
.collect(Collectors.toList());
.toList();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could be a separate small change

.filter(cr -> cr != r && cr.getEffectiveModel() != null)
.map(cr -> projectIndex.get(cr.getEffectiveModel().getId()))
.collect(Collectors.toList()));
.toList());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ditto; good but not needed in this PR

}
} else {
hasScript |= Language.SCRIPT.equals(language);
var sourceRoot = DefaultSourceRoot.fromModel(session, baseDir, outputDirectory, source);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Personally I dislike var. It prioritizes trivial typing speed over code readability

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Personally I agree with you, but perhaps its more a question of programming style. var is already used in other places of this codebase, e.g., DefaultModelBuilder.java:

  for (var problem : e.getResult().getProblemCollector()...
  for (var transformer : transformers) {

* <li>Case 1: The default legacy directory exists on the filesystem (e.g., src/main/java exists)</li>
* <li>Case 2: An explicit legacy directory is configured that differs from the default</li>
* </ul>
* Legacy directories are unconditionally ignored in modular projects because it is not clear
Copy link
Contributor

@elharo elharo Feb 5, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not comfortable with this. If we can't dispatch, I think we need to hard fail the build rather than simply ignoring the content. Let the user figure out how to rearrange the project to make the build pass. A warning is not enough here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree. If @ascheman also agrees, I guess that we can do this change. But since this pull request is a backport, I would suggest to do the change on master first, then backport here.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bleah. 3.x maintenance and 4.x development is hard enough without trying to develop two 4.x versions simultaneously. In any case, sure, let's do the change on master and then backport here, at least until we come to our senses and finish one 4.x version before starting the next.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds feasible to me. I would think this should be another acceptance criterion (AC8) in the overall concept to document that additional behaviour? It would be consistent with AC6 (where we also fail for mixed modular/classic <sources>).

@desruisseaux
Copy link
Contributor Author

This pull request is a squashed backport of two pull requests from the mater branch, one merged in December 30th and the second one today. The issue describing the second commit on the master branch is #11612, but a more complete description is on the wiki at the link below:

https://cwiki.apache.org/confluence/display/MAVEN/Build+Sources+Validation+-+Discussion+Notes

@elharo
Copy link
Contributor

elharo commented Feb 5, 2026

https://cwiki.apache.org/confluence/display/MAVEN/Build+Sources+Validation+-+Discussion+Notes

Useful, but the wiki is not an issue tracker. We seem to be getting in the habit of submitting major PRs without issues. That's an unexpected and IMHO negative side effect of moving to GitHub issues from JIRA.

@elharo
Copy link
Contributor

elharo commented Feb 5, 2026

#11701

@ascheman
Copy link
Contributor

ascheman commented Feb 5, 2026

I'm a little uncomfortable that large fixes like this are getting submitted without corresponding issues.

As this is a backport (mostly) of #11612: Would it be OK for you if this were explicitly mentioned?

@elharo
Copy link
Contributor

elharo commented Feb 5, 2026

I'm a little uncomfortable that large fixes like this are getting submitted without corresponding issues.

As this is a backport (mostly) of #11612: Would it be OK for you if this were explicitly mentioned?

Only if we don't close the bug until the backports are complete. And even then I'm not sure our release tools are set up to handle single issues that touch multiple versions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants