You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I looked at the current incremental compilation code. After we analyze the compiled class, do we also need to compile other classes related to it? I feel that the code of version 3.x is already good enough. We just need to add it and find the dependencies. I have looked at the gradle code. They have this logic. The parameters of 4.x are too complicated. Users should not be aware of so many scopes. There are some other small issues, how can we discuss them together
The parameters of version 4.x are for making possible to reproduce the behaviour of 3.x when requested, while having a slightly different behaviour by default.
Indeed, ideally we should scan the byte-code of each class and list all project's classes that it references. Maybe we could use ASM for that, but it tends to break Maven every time that a new Java version is released (see for example #960 and #961). We should use ClassFile API instead as suggested in #969, but it requires Java 24. We could make this scan an optional feature available only when Maven is running on Java 24, but we would need to make Maven Compiler Plugin a multi-release JAR file. It is possible in the current project, but would be easier with the compiler plugin 4.0.0-beta-3 and also requires an evolution of the Surefire plugin as mentioned in this comment.
In summary, this is of course desirable, but for now the easiest approach would be to do this work on a branch of the Maven Compiler Plugin which would require Java 24. For integrating that work on the master branch which currently needs to be executable on Java 17, we depend on other work not yet completed.
A depends on B, and A is not recompiled when the methods or classes in B change and if configured like this <incrementalCompilation>options,dependencies,sources</incrementalCompilation>, when one of the two modules changes, the other module is also fully compiled (if I am wrong, please tell me). I am now implementing it in gradle to see if there is a good implementation.
Activity
desruisseaux commentedon Sep 23, 2025
The parameters of version 4.x are for making possible to reproduce the behaviour of 3.x when requested, while having a slightly different behaviour by default.
Indeed, ideally we should scan the byte-code of each class and list all project's classes that it references. Maybe we could use ASM for that, but it tends to break Maven every time that a new Java version is released (see for example #960 and #961). We should use ClassFile API instead as suggested in #969, but it requires Java 24. We could make this scan an optional feature available only when Maven is running on Java 24, but we would need to make Maven Compiler Plugin a multi-release JAR file. It is possible in the current project, but would be easier with the compiler plugin 4.0.0-beta-3 and also requires an evolution of the Surefire plugin as mentioned in this comment.
In summary, this is of course desirable, but for now the easiest approach would be to do this work on a branch of the Maven Compiler Plugin which would require Java 24. For integrating that work on the master branch which currently needs to be executable on Java 17, we depend on other work not yet completed.
zhaoyunxing92 commentedon Sep 23, 2025
A depends on B, and A is not recompiled when the methods or classes in B change and if configured like this
<incrementalCompilation>options,dependencies,sources</incrementalCompilation>, when one of the two modules changes, the other module is also fully compiled (if I am wrong, please tell me). I am now implementing it in gradle to see if there is a good implementation.