[ https://issues.apache.org/jira/browse/MSHARED-1285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17794690#comment-17794690 ]
ASF GitHub Bot commented on MSHARED-1285: ----------------------------------------- elharo commented on code in PR #77: URL: https://github.com/apache/maven-filtering/pull/77#discussion_r1420397992 ########## src/main/java/org/apache/maven/shared/filtering/DefaultMavenResourcesFiltering.java: ########## @@ -321,19 +347,20 @@ public void filterResources(MavenResourcesExecution mavenResourcesExecution) thr } /** - * Get the encoding to use when filtering the specified file. Properties files can be configured to use a different - * encoding than regular files. + * Get the encoding to use when filtering the specified file. Properties files + * can be configured to use a different encoding than regular files. * - * @param file The file to check - * @param encoding The encoding to use for regular files + * @param file The file to check Review Comment: Did spotless do that? That's new, i think, and a strike against spotless if so. > DefaultMavenResourcesFiltering uses BuildContext in a way that fails sometimes > ------------------------------------------------------------------------------ > > Key: MSHARED-1285 > URL: https://issues.apache.org/jira/browse/MSHARED-1285 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-filtering > Reporter: Christoph Läubrich > Priority: Major > > The maven resources plugin uses > [https://github.com/apache/maven-filtering/blob/master/src/main/java/org/apache/maven/shared/filtering/DefaultMavenResourcesFiltering.java] > to copy resources, but that component has some subtile flaws reported here: > [https://github.com/eclipse-m2e/m2e-core/discussions/1468] > The problematic part is the usage of BuildContext#newScanner that already > mentions in the javadoc that passing ignoreDelta to neScanner might not > reveal all required items +*for copy-resources*+ form A -> B and instead > BuildContext#isUpTodate should be used. > Just from a quick look I assume that part of code actually wants to use > something like this: > {code:java} > DirectoryScanner ds = new DirectoryScanner() { > @Override > protected boolean isSelected(String name, File file) { > if (file.isFile() && buildContext.isUptodate(getTargetFile(file), file)) > { > return false; > } > return true; > } > }; > ds.setBasedir(basedir); {code} > That way all the code that currently checks for if output directory existed > before can also be removed what is another issue because it leads to a full > resources copy even if source+target are already even if a single class file > is changed while the idea seems more that if the output was not there it > should not try to be incremental! -- This message was sent by Atlassian Jira (v8.20.10#820010)