[ 
https://issues.apache.org/jira/browse/MNG-7740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17721900#comment-17721900
 ] 

ASF GitHub Bot commented on MNG-7740:
-------------------------------------

Giovds commented on code in PR #1105:
URL: https://github.com/apache/maven/pull/1105#discussion_r1191651779


##########
maven-core/src/main/java/org/apache/maven/internal/transformation/ConsumerPomArtifactTransformer.java:
##########
@@ -77,13 +80,34 @@ public void injectTransformedArtifacts(MavenProject 
project, RepositorySystemSes
                 Files.createDirectories(buildDir);
                 generatedFile = Files.createTempFile(buildDir, 
CONSUMER_POM_CLASSIFIER, "pom");
             }
+
+            removeOldConsumerPomFiles(generatedFile);
+
             project.addAttachedArtifact(new ConsumerPomArtifact(project, 
generatedFile, session));
         } else if (project.getModel().isRoot()) {
             throw new IllegalStateException(
                     "The use of the root attribute on the model requires the 
buildconsumer feature to be active");
         }
     }
 
+    private void removeOldConsumerPomFiles(Path generatedFile) throws 
IOException {
+        List<Path> oldConsumerPomFiles;

Review Comment:
   I had a couple of reasons for it. The first reason for me is readability (as 
I'll show down below). 
   
   The second is that I don't think its a good practice to wrap the checked 
exception into a runtime exception (also introducing more code or a wrapper 
'delete' method). Especially since `injectTransformedArtifacts()` already 
throws a checked exception which is probably accounted for somewhere at some 
point.
   
   As far as I know when you rewrite the stream to something like 
`stream.filter(path -> /*filter*/ }).forEach(Files::delete);` you either have 
to wrap the checked exception thrown by `Files.delete(path)` into a runtime 
exception:
   ```java
       private void delete( Path path ) {
           try { Files.delete( path ); }
           catch ( IOException e ) { throw new RuntimeException("", e); }
       }
       
       /* obfuscated*/
       
       stream.filter(path -> /*filter*/ })
              .forEach(this::delete);
   ```
   Or handle it:
   ```java
   stream.filter(path -> /*filter*/ })
              .forEach(path -> {
                   try { Files.delete(path); }
                   catch (IOException ex) { /*handle the exception*/ }
              });
   ```





> Target directory is flooded with consumer*pom files
> ---------------------------------------------------
>
>                 Key: MNG-7740
>                 URL: https://issues.apache.org/jira/browse/MNG-7740
>             Project: Maven
>          Issue Type: Improvement
>          Components: build/consumer, Core
>    Affects Versions: 4.0.0-alpha-4
>         Environment: Apache Maven 4.0.0-alpha-4 
> (009cf4a7213aead8a7946a2397e2396c5927f30f)
> Maven home: /Users/maarten/Tools/apache-maven-4.0.0-alpha-4
> Java version: 17.0.6, vendor: Eclipse Adoptium, runtime: 
> /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home
> Default locale: en_NL, platform encoding: UTF-8
> OS name: "mac os x", version: "13.2.1", arch: "aarch64", family: "mac"
>            Reporter: Maarten Mulders
>            Priority: Minor
>              Labels: up-for-grabs
>
> After invoking Mavens {{validate}} or later lifecycle phase, there is a 
> *consumerXXXpom* file left in the build directory. Here, XXX is a bunch of 
> numbers.
> It is not harmful, but I dislike the fact that for every invocation of Maven, 
> the file gets generated again and again. This can quickly lead to tens of 
> files that are never used again anymore. I feel we should clean those files 
> when we're done using them.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to