Skip to content

[MNG-8686] Add SourceRoot.matcher(boolean) method #2236

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 9 commits into
base: master
Choose a base branch
from

Conversation

desruisseaux
Copy link
Contributor

Following the revert of includes/excludes filters from PathMatcher to String in #2232, this pull request adds a new SourceRoot.matcher(boolean) method which provides the PathMatcher. Contrarily to the previous methods, this new method provides a single matcher combining the work of all includes and all excludes. The default implementation is ported from apache/maven-clean-plugin#243.

gnodet and others added 3 commits April 4, 2025 08:40
The matcher returned by that method combines the effects of all includes and excludes.
@@ -144,13 +143,15 @@ public DefaultSourceRoot(final ProjectScope scope, final Language language, fina
* @param scope scope of source code (main or test)
* @param language language of the source code
* @param directory directory of the source code
* @param includes list of patterns for the files to include, or {@code null} if unspecified
Copy link
Contributor

Choose a reason for hiding this comment

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

unspecified or nothing to include?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Unspecified. The default is plugin-dependent. For example, the compiler plugin will default to the *.java includes. Other plugins may have different default.

Copy link
Contributor

Choose a reason for hiding this comment

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

Effective Java suggests returning empty lists instead of nulls as a general practice.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Actually this "null or empty" (will update the documentation). This is a parameter rather than a return value, accepting both for convenience.

*/
@Override
public String toString() {
var buffer = new StringBuilder();
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. Not sure if there's a project setting on this

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 do not know if there is a Maven policy. Personally, I use it when it is redundant with what we can read on the same line with no possibility of different result (e.g., the result of new), but generally avoid it for the return value of a method call for example, as it is not obvious by reading the line.

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.

Does this have/need a JIRA issue?

@@ -144,13 +143,15 @@ public DefaultSourceRoot(final ProjectScope scope, final Language language, fina
* @param scope scope of source code (main or test)
* @param language language of the source code
* @param directory directory of the source code
* @param includes list of patterns for the files to include, or {@code null} if unspecified
Copy link
Contributor

Choose a reason for hiding this comment

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

Effective Java suggests returning empty lists instead of nulls as a general practice.

*
* @param path the path to test
*/
private void assertContains(String path) {
Copy link
Contributor

Choose a reason for hiding this comment

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

I think this method would be clearer inlined. It's just one line.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That line has some degrees of freedom (the collection, the base directory, the message in case of failure), even if I agree that there is not much (yet) real freedom because there is only one collection and one directory. A purpose of using a method is that, when many calls to assertContains are repeated, we know that those things are the same for every lines without having to paid a closer look to the lines.

I will rename as assertFilteredFilesContains for more clarity.

by `PathMatcher matcher(Collection, boolean)`.
…more because of the introduction or more argument to the `matcher` method in previous commit.
…before to delegate to the glob syntax.

Optimization: omit excludes that are unnecessary because they will never match a file accepted by includes.
This is especially useful when the default excludes are added, because there is a lot of them.
@desruisseaux
Copy link
Contributor Author

JIRA issue created: https://issues.apache.org/jira/browse/MNG-8686

@desruisseaux desruisseaux changed the title Add SourceRoot.matcher(boolean) method [MNG-8686] Add SourceRoot.matcher(boolean) method Apr 12, 2025
@gnodet
Copy link
Contributor

gnodet commented Apr 13, 2025

Following the revert of includes/excludes filters from PathMatcher to String in #2232, this pull request adds a new SourceRoot.matcher(boolean) method which provides the PathMatcher. Contrarily to the previous methods, this new method provides a single matcher combining the work of all includes and all excludes. The default implementation is ported from apache/maven-clean-plugin#243.

We'd need to carefully review the maven-resources-plugins various options and see if they can fit this API. IIRC, there are options such as symlinks following, but there may be others.

@desruisseaux
Copy link
Contributor Author

We'd need to carefully review the maven-resources-plugins various options and see if they can fit this API. IIRC, there are options such as symlinks following, but there may be others.

Yes. This is another aspect replaced by standard Java now, with java.nio.file.FileVisitOption.FOLLOW_LINKS. One issue is that it behaves differently than the current Maven for one kind of link specific to the Windows platform: NTFS "junction links". This is handled by a special case in apache/maven-clean-plugin#243. Thankfully, the maven-cleaner-plugin has a quite extensive test suite that covers this case among others.

Symbolic links are not handled by the PathSelector class proposed in this pull request. They need to be handled later, in our use of java.nio.file.FileVisitor, which is not part of this PR. I was thinking to address FileVisitor in a separated PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants