[
https://issues.apache.org/jira/browse/MNG-5469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-5469.
-------------------------------
Resolution: Auto Closed
This issue has been auto closed because it has been inactive for a long period
of time. If you think this issue still applies, retest your problem with the
most recent version of Maven and the affected component, reopen and post your
results.
> Maven should evaluate profiles per lifecycle
> --------------------------------------------
>
> Key: MNG-5469
> URL: https://issues.apache.org/jira/browse/MNG-5469
> Project: Maven
> Issue Type: Bug
> Components: Profiles
> Affects Versions: 3.0.5
> Environment: 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"
> Reporter: Karl Schaefer
> Priority: Major
> Attachments: pom.xml
>
>
> 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).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
