Search code examples
grailsdeploymentggtsgrails-2.4

WAR name based on Environment in BuildConfig.groovy

I want to name my WAR files automatically depending on appName, appVersion and the short name of Environment.current. I have the following option setup in BuildConfig.groovy:

String currentEnvShortName = Environment.envNameMappings.find{it.value == Environment.current.name}.key

def f = new File("grails-app/conf/config.properties")
f.text = ""
f << "Current Env: ${currentEnvShortName}"

grails.project.war.file = "target/war/${appName}-${appVersion.toString().replaceAll(/\./,' ').split().join("-")}${currentEnvShortName}.war"

I write the environment to a file so that I don't have to wait for the war command to execute. EDIT: USING GGTS COMMAND LINE. First, I thought everything works as expected. My usual deployment process is as follows:

  1. run grails clean
  2. run war command for the desired environment
  3. deploy WAR on application server

After clean, however, and possibly also after other grails commands, the value of Environment.current changes in a way I do not understand. It is always dev the first time I run the war command. After this first time, the environment name is retrieved correctly again. So what I do as a workaround is:

  1. run grails clean
  2. run war command for the desired environment, but break right after starting it
  3. run war command for the desired environment
  4. deploy WAR on application server

Am I doing anything wrong or is this a bug?

Environment to reproduce:

GGTS 3.6.4 RELEASE

Grails 2.4.2

Groovy 2.3.10

JDK 1.6.0_07

EDIT: I could not reproduce using Grails from regular command line. This behaviour only occurs with Groovy Grails Tool Suite's built in command line. The Environment seems to be switching randomly.

EDIT 2: OS: Windows 7

Solution

  • The issue only occurs with the built in command line of Groovy Grails Tool Suite on Windows. If the war command is executed from Windows CMD, then the environment is used correctly.

    However, when executing from Windows CMD, encoding breaks for me. I have addressed this specific issue in another question.