rmannibucau commented on PR #320:
URL: 
https://github.com/apache/maven-compiler-plugin/pull/320#issuecomment-2823653270

   > Which approximation is the best compromise between speed and safety 
depends on the developer's habits (e.g., do they run mvn clean themselves when 
they know that it will be necessary?). Hence the choice left to the developers.
   
   Hmm no, on that part the only valuable default is the safe one, heuristics 
(for speed) are ok but not as defaults and ultimately shouldn't be used in the 
xml (except in a profile) as a good practise IMHO.
   
   > we would need to build a graph of relationships between all *.class files
   
   technically this wouldn't work since you would need to know an annotation 
processor needs all classes (this is even outside the .class of the project 
even the .class of the processor doesn't even have a ref on others so the graph 
doesn't work). Several build systems did enable incremental annotation 
processors and/or toggles to configure that - looks like your new option at 
some extent.
   
   That said it doesn't change that the default should clear by default if any 
doubt and never assume it can do an incremental compilation, as a record idea 
just fixed it partially in a very recent release and it was really blocking the 
development and a hidden gem so hope maven doesnt reach that state for end 
users and keeps a safe default which is optimizable with your option explicitly 
if desired but not the opposite probably.
   
   So a good default would more look like: 
`options,dependencies,sources,any-processor` with `any-processor` being a 
simple "if there is an annotation processor then clean and recompile without 
doing a diff nor managing incremental state" (this last part got proven slower 
than the recompilation on some project when the option got introduced so let's 
skip it when we know we do not need it)
   
   hope it makes sense


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Reply via email to