[
https://issues.apache.org/jira/browse/MCOMPILER-474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Kozlov updated MCOMPILER-474:
-----------------------------------
Description:
Suppose we have a project with two modules: "Lib" and "App", App depends on
Lib. And we ran {{mvn clean install}} earlier. Then we changed something in Lib
sources. Now consider these two scenarios:
* If we run {{mvn compile}}: Lib gets recompiled, then App gets recompiled -
all good.
* If we run {{mvn package}}: Lib gets recompiled, but App doesn't ("Nothing to
compile - all classes are up to date") - a bug.
The problem here is that if the current build requests packaging a jar then Lib
is added to App's {{compilePath}} as {{.../lib/target/lib-x.y.z.jar}} (instead
of {{.../lib/target/classes}} in case of "compile" goal). And the
{{isDependencyChanged()}} function in AbstractCompilerMojo only checks class
files, not jars.
This can be reproduced using the existing integration test
https://github.com/apache/maven-compiler-plugin/tree/master/src/it/MCOMPILER-349_dependencyChanged,
you'll just need to replace "compile" with "package" in the invoker.properties
file.
was:
Suppose we have a project with two modules: "Lib" and "App", App depends on
Lib. And we ran {{mvn clean install}} earlier. Then we changed something in Lib
sources. Now consider these two scenarios:
* If we run {{mvn compile}}: Lib gets recompiled, then App gets recompiled -
all good.
* If we run {{mvn package}}: Lib gets recompiled, but App doesn't ("Nothing to
compile - all classes are up to date") - a bug.
The problem here is that if the current build requests packaging a jar then Lib
is added to App's {{compilePath}} as {{.../lib/target/lib-x.y.z.jar}} (instead
of {{.../lib/target/classes}} in case of "compile" goal). And the staleness
logic in AbstractCompilerMojo only checks class files, not jars.
This can be reproduced using the existing integration test
https://github.com/apache/maven-compiler-plugin/tree/master/src/it/MCOMPILER-349_dependencyChanged,
you'll just need to replace "compile" with "package" in the invoker.properties
file.
> Dependent modules are not recompiled if we run the "package" goal
> -----------------------------------------------------------------
>
> Key: MCOMPILER-474
> URL: https://issues.apache.org/jira/browse/MCOMPILER-474
> Project: Maven Compiler Plugin
> Issue Type: Bug
> Affects Versions: 3.8.1
> Reporter: Roman Kozlov
> Priority: Major
>
> Suppose we have a project with two modules: "Lib" and "App", App depends on
> Lib. And we ran {{mvn clean install}} earlier. Then we changed something in
> Lib sources. Now consider these two scenarios:
> * If we run {{mvn compile}}: Lib gets recompiled, then App gets recompiled -
> all good.
> * If we run {{mvn package}}: Lib gets recompiled, but App doesn't ("Nothing
> to compile - all classes are up to date") - a bug.
> The problem here is that if the current build requests packaging a jar then
> Lib is added to App's {{compilePath}} as {{.../lib/target/lib-x.y.z.jar}}
> (instead of {{.../lib/target/classes}} in case of "compile" goal). And the
> {{isDependencyChanged()}} function in AbstractCompilerMojo only checks class
> files, not jars.
> This can be reproduced using the existing integration test
> https://github.com/apache/maven-compiler-plugin/tree/master/src/it/MCOMPILER-349_dependencyChanged,
> you'll just need to replace "compile" with "package" in the
> invoker.properties file.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
