kriegaex
commented
10 months ago @mp911de, @odrotbohm: Mentioning you, just in case you want to watch this issue. My focus will shift, after I contributed to Spring Data JPA once, triggered by an AspectJ question, stumbling across the ANTLR issue when trying to address what was falsely perceived as a Maven Compiler or AspectJ Maven problem.
blueboz
jimidle
The Maven plugin always recreates the generated sources, even if nothing has changed in the input data. Most Maven plugins are a bit smarter and have a simple mechanism to avoid that: They write a list of input files into a list file in the output directory. During the next run, the compare the list file's timestamp (modified date) to each input file's. If and only if one of the input files is more recent than the list file or there are new input files not listed in the list file, a plugin actually does any work in a build without previous
mvn clean. Examples for plugins working like that are Maven Compiler, AspectJ Maven or what have you.The problem is, that the ANTLR plugin recreating generated sources also defeats the aforementioned plugins' ability to compile incrementally, because those plugins (e.g. Maven Compiler) see changed source files due to ANTLR. I.e., running
mvn compilemultiple times always recreates all ANTLR-generated sources and therefore also recompiles potentially big projects, even though that might be completely unnecessary. It gets even worse, if in a multi-module project other modules depend on the module using the ANTLR plugin, because then those dependent modules are also unnecessarily recompiled. You get the picture.For a real-world example, just look at the dirty tricks I had to play in Maven in https://github.com/spring-projects/spring-data-jpa/pull/3282/files to stop the ANTLR plugin from doing that and finally achieve quick rebuilds. Instead of such workarounds, it would be much better to improve the ANTLR4 Maven plugin.