Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Auto Closed
-
3.0.5
-
None
-
None
-
Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 08:51:28-0500)
Maven home: C:\apache-maven-3.0.5\bin\..
Java version: 1.6.0_32, vendor: Sun Microsystems Inc.
Java home: C:\Program Files\Java\jdk1.6.0_32\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 08:51:28-0500) Maven home: C:\apache-maven-3.0.5\bin\.. Java version: 1.6.0_32, vendor: Sun Microsystems Inc. Java home: C:\Program Files\Java\jdk1.6.0_32\jre Default locale: en_US, platform encoding: Cp1252 OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
Description
Maven profiles are evaluated one time before running any lifecycle goals. This can lead to different behavior depending on whether the lifecycle goals are part of the same lifecycle model.
Run the attached POM file:
mvn clean compile
The result is that if-file-missing runs, as expected since file.txt does not exist.
Rerun the POM:
mvn clean compile
The result is that if-file-exists runs, but by the time the default lifecycle begins executing, which is after the clean lifecycle finishes, file.txt no longer exists.
Furthermore, if you have performed your rerun of the POM as:
mvn clean
mvn compile
The result would have been to execute if-file-missing, as expected.
This means that Maven builds can have spurious results if the file the profile it is evaluating is located in the project build directory. Having Maven evaluate the necessary profiles at the beginning of each different lifecycle would alleviate this problem. Therefore, if evaluation was per lifecycle, the rerun would execute the clean lifecycle with if-file-exists and the default lifecycle with if-file-missing.
Being able to accurately determine the existence of a file in the project build directory is important. My use case creates a throw-away keystore for signing jars. That keystore should be inside the project build directory because it needs to exist only for the lifetime of the build process and is not something that is intrinsic to the data being processed (ie. not essential to have in version control).