1

Here's my scenario:

  • Maven 2.0.9 is our build system
  • We install code to multiple environments
  • All of our environment-specific properties are contained in property files, one for each environment
    • We currently read these properties into maven using the properties-maven-plugin; this sub-bullet is not a requirement, just our current solution

Goal:

  • Perform certain parts of the build (ie. plugin executions) only for certain environments
  • Control which parts are run by setting values in the environment-specific property files

What I've tried so far:

  • Maven allows plugins executions to be put inside pom profiles, which can be activated by properties; unfortunately these must be system properties - ie. from settings.xml or the command-line, not from properties loaded by the properties-maven-plugin

If possible, we'd like to keep everything encapsulated within the build workspace, which looks something like this:

project
    pom.xml
    src
       ...
    conf
       dev.properties
       test.properties
       prod.properties
    build-scripts
       build.groovy <-- the script that wraps maven to do the build
       install.groovy <-- ... wraps maven to do the install

Running a build looks like:

cd build-scripts
./build.groovy
./install.groovy -e prod

Is there any possible way to accomplish these goals with the version of maven we are using? If not, is it possible with a newer version of maven?

Community
  • 1
  • 1
GreenGiant
  • 4,930
  • 1
  • 46
  • 76
  • "accomplish these goals with the version of maven we are using" is it a requirement that you can't upgrade maven? – Daniel Kaplan Jan 17 '13 at 18:46
  • @Daniel yes - we're not planning on upgrading any time in the foreseeable future, and we certainly wouldn't upgrade just to accomplish this goal – GreenGiant Jan 17 '13 at 21:19
  • @Daniel if you have a good solution that is possible with a newer version of maven, feel free to provide it; this might be an additional impetus for us to upgrade - I'll modify my question – GreenGiant Jan 17 '13 at 21:27
  • I don't, but that detail stood out to me so I wanted to get clarification. New Subject: I don't know if you can see my deleted answer, but the reason I deleted it is because I tried it and it didn't work. – Daniel Kaplan Jan 17 '13 at 21:33
  • what's wrong with -Pprod to activate the environment specific profile? – kldavis4 Jan 17 '13 at 21:39
  • that might work. how would I set it up so that (for eg.) both test and prod share a given set of steps that aren't run for dev? – GreenGiant Jan 17 '13 at 21:41
  • it depends on what each profile does. You might need to duplicate configuration in different profiles to accomplish what you need. If you what more fine grain control you will need to something like I suggest in my answer. Note, though, that if you are modifying configuration of the same thing (reports, plugins, etc) your different profiles can step on each other. – kldavis4 Jan 17 '13 at 22:20
  • The other thing is, since you are launching the maven build from groovy, you should be able to just modify the groovy script to set the system properties prior to launching maven – kldavis4 Jan 17 '13 at 22:31
  • @kl that's actually what I've ended up doing; if you make that an answer, I'll mark it as accepted – GreenGiant Jan 18 '13 at 16:31

1 Answers1

2

This isn't possible using just Maven. (See also How to activate profile by means of maven property?) The reason is that profiles are the first thing evaluated before anything else to determine the effective POM.

My suggestion is to write some preprocessor that parses your environment specific property files and converts them to the required system properties before launching Maven. This script can be included in your ~/.mavenrc so that it runs automatically before Maven is launched. Here is an example script that that assumes the properties file is in a fixed location:

properties=`cat /etc/build-env.properties`
while read line; do
   MAVEN_OPTS="$MAVEN_OPTS -D$line"
done <<< "$properties"

If the properties file is not fixed, you'll just need to add something to the script to discover the location (assuming it is discoverable).

Community
  • 1
  • 1
kldavis4
  • 2,177
  • 1
  • 22
  • 33
  • Interesting... in our case, we want to keep everything encapsulated within the build workspace, so that it can be easily version-controlled. – GreenGiant Jan 17 '13 at 21:24
  • You probably will have some items that are not in the build workspace (like ~/.m2/settings.xml) and that are not versioned-controlled, so I wouldn't get to hung up on that aspect of things. I assume your properties files are going to not be in the build workspace, right? – kldavis4 Jan 17 '13 at 21:29
  • The property files are in the build workspace. I'll add some more info to the question. – GreenGiant Jan 17 '13 at 21:30
  • Well, in that case, what are you using to determine which property file is used in which environment? – kldavis4 Jan 17 '13 at 21:32