Maven Properties Plugin Download

Update: As of June 6th, 2007, this is now in the Codehaus Sandbox repository.

I get an email once a week asking the whereabouts of the properties plugin for Maven so I thought I’d put it up somewhere.

If you think this is useful, vote in favor of it – Codehaus JIRA MOJO-535.

It has three goals (for now):

  1. read-project-properties: Given a set of property files in name=value format, it reads them and stores them as project properties. This would be nice for those of us that store environment specific information in different property files.
  2. write-project-properties: Writes project properties to a given file. Helpful when some properties need to be available at runtime e.g.: Spring’s PropertyPlaceholderConfigurer)
  3. write-active-profile-properties: Writes the properties of any active profiles to a file.

Here’s some sample usage of the read-project-properties goal which reads property files as project properties:

<plugin>
  <groupId>org.codehaus.mojo</groupId>
  <artifactId>properties-maven-plugin</artifactId>
  <version>1.0-SNAPSHOT</version>
  <executions>
    <execution>
      <phase>initialize</phase>
      <goals>
        <goal>read-project-properties</goal>
      </goals>
      <configuration>
        <files>
          <file>etc/config/dev.properties</file>
        </files>
      </configuration>
    </execution>
  </executions>
</plugin>

The write-project-properties goal writes project properties to a file:

<plugin>
  <groupId>org.codehaus.mojo</groupId>
  <artifactId>properties-maven-plugin</artifactId>
  <version>1.0-SNAPSHOT</version>
  <executions>
    <execution>
    <phase>generate-resources</phase>
    <goals>
      <goal>write-project-properties</goal>
    </goals>
    <configuration>
      <outputFile>
        target/classes/app.properties
      </outputFile>
    </configuration>
    </execution>
  </executions>
</plugin>

The write-active-profile-properties goal writes all properties of active profiles to a file:

<plugin>
  <groupId>org.codehaus.mojo</groupId>
  <artifactId>properties-maven-plugin</artifactId>
  <version>1.0-SNAPSHOT</version>
  <executions>
    <execution>
      <phase>generate-resources</phase>
      <goals>
        <goal>write-active-profile-properties</goal>
      </goals>
      <configuration>
        <outputFile>
          target/classes/app.properties
        </outputFile>
      </configuration>
    </execution>
  </executions>
</plugin>

Hope this helps someone.

Advertisements

47 thoughts on “Maven Properties Plugin Download

  1. Eric Schwarzenbach

    Thanks much! And I hate to be ungrateful, but maybe you’ll appreciate this as free QA. :^)

    I’m not having any luck getting it to work. I’m just trying to read a
    property out of a file. I’ve got

    org.codehaus.mojo
    properties-maven-plugin
    1.0-SNAPSHOT

    initialize

    read-project-properties

    test.props

    I believe it is executing because maven reports:

    [INFO] [properties:read-project-properties {execution: default}]

    test.props contains only the line
    db.type=postgresql

    However my filter which attempts to use it fails

    ${basedir}/../database/src/main/scripts/${db.type}/tokens.properties

    if I define db.type inside a properties statement, it works. However
    replacing that with your plug-in reading my test.props I get

    [ERROR] BUILD ERROR
    [INFO]
    ————————————————————————
    [INFO] Error loading property file
    ‘C:\work\code\wrycan\xms\core/../database/src
    /main/scripts/${db.type}/tokens.properties’

    Embedded error:
    C:\work\code\wrycan\xms\core\..\database\src\main\scripts\${db.t
    ype}\tokens.properties

    Any ideas?

    Thanks,

    Eric

    Reply
  2. Eric Schwarzenbach

    I don’t think that’s it. The other property (basedir) in the same line is working when that db.type one fails, and it works fine when I define this property by other means (such as a profile or a direct properties section).

    My is within within and is a sibling of the containing your (if that matters).

    Reply
  3. Eric Schwarzenbach

    Ack, this thing doesn’t like XML tags. Let me try that last line again.

    My <filter> is within <filters> within <build>, and <filters> is a sibling of the <plugins> which contains your <plugin>.

    Reply
  4. arsenalist

    Sorry but all one can do is load the properties into the MavenProject using the MavenProject.getProperties() method (which is what is being done) and hope that Maven can figure the rest out.

    Reply
  5. Eric Schwarzenbach

    So what is the upshot of that? Are you saying there seems to be some bug or limitation with the functionality which causes maven not to make such loaded properties available as one might expect? Is there another part of the pom where this is known to work that I could try as a test to see if it is a matter of maven recognizing the loaded property in some contexts and not others?

    Reply
  6. arsenalist

    Try putting the filters element directly inside the build element like this:

    <build>
    <filters>
    <filter>src/main/filters/${config}.properties</filter>
    </filters>
    . . . .
    </build>

    Reply
  7. arsenalist

    I think this is an execution order issue. What phase are you running the properties-maven-plugin in? Try using it as early as possible so that any future executions have your properties available to them. It’s possible that the properties are being used before they are actually read. Try loading your properties inside the validate phase which is the first phase according to the docs.

    http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html

    If that doesn’t work, loading them in a parent pom and using them in a child pom might do the trick since the parent executes first.

    Reply
  8. Eric Schwarzenbach

    I had the phase set to intialize as in your example. I just tried making it validate, but that didn’t help. Tried putting it in the parent pom but it seems to execute both there and from the sub projects so the folder path is wrong for one or the other.

    But copying my file to both places I see it doesn’t fix the problem anyway.

    I do see the
    [INFO] [properties:read-project-properties {execution: default}]
    line before the error when trying to use the property, and it never gets to that error if the plugin encounters an error loading the file, so I don’t think execution order is the problem.

    Reply
  9. arsenalist

    This is odd behavior. The properties read can be used inside other Maven plugins like maven-antrun-plugin but for some reason the filters element refuses to recognize them. In the following example, the myvar property was printed fine by the antrun plugin but the property wasn’t resolved in the filters element:

    <build>
      <plugins>
        <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>properties-maven-plugin</artifactId>
        <version>1.0-SNAPSHOT</version>
        <executions>
          <execution>
          <phase>initialize</phase>
          <goals>
            <goal>read-project-properties</goal>
          </goals>
          <configuration>
            <files>
            <file>etc/config/props.properties</file>
            </files>
          </configuration>
          </execution>
        </executions>
        </plugin>      
        <plugin>
          <artifactId>maven-antrun-plugin</artifactId>
          <executions>
            <execution>
              <id>spring</id>
              <phase>generate-sources</phase>
              <configuration>
                <tasks>
                  <echo>${myvar}</echo>
                </tasks>
              </configuration>
              <goals>
                <goal>run</goal>
              </goals>
            </execution>
          </executions>
        </plugin>    
      </plugins>
      <filters>
        <filter>${myvar}.properties</filter>
      </filters>
    </build>

    props.properties just had:

    myvar=myvalue

    I’ll look into this more if I have time but it appears that the the filters element has access to properties other than those in MavenProject.

    Reply
  10. Eric Schwarzenbach

    Oh well. I appreciate your having spent the time looking into it.

    Ever get the feeling that the complexity of dealing with maven exceeds the complexity of managing dependencies that it is supposed to be saving us from?

    Reply
  11. Eric Schwarzenbach

    The architecture of maven (and I’m not even talking architecture of how it’s implemented just the architecture of what is presented to the user) feels like such a mess. It seems like a bunch of functionality glommed together like tinker toys. What seems to be missing is a coherent domain model. Maybe I haven’t spent enough time trying to understand their “model” but there’s no intuitive connection between what one wants to do and what one has to do in maven to make that happen. Instead of their model following the actual domain, it seems like they’ve constructed an artificial one based on functional needs.

    Reply
  12. Charles Greer

    This plugin rocks. I spent all day today trying to glom ant and maven together to get a deployment scenario together because I couldn’t wrap my head around how to create deployment-specific files for Spring’s PropertyPlaceholderConfigurer. 10 minutes with this plugin and I’m all ready to go. I appreciate your work.

    The discussion above is interesting though — in general although I agree with your take on Maven… the docs are getting a lot better of late and once you’ve nailed something with Maven it just works so damn well…

    Reply
  13. Pingback: properties-maven-plugin

  14. Andrea

    Hi,
    thanks for the plug-in. I was just looking for smomething like this.
    I got a little problem on usinng it, maybe you can help

    I’ve created a foo.properties file, whit
    my.foo.ver=13

    Than in my pom, I’ve something like:
    ……………..

    org.codehaus.mojo
    properties-maven-plugin
    1.0-SNAPSHOT

    validate

    read-project-properties

    foo.properties


    myprojectdir_${std.ver}

    ..\${myfoo.project.dir}

    ……………..

    I’m tryng to run my pom, but i receive this error:

    [DEBUG] Trace
    org.apache.maven.reactor.MavenExecutionException: Could not find the model file ‘C:\Apps\Eclipse_Works
    pace\foo-build\..\myprojectdir_${std.ver}\pom.xml’.

    It seem that my std.ver propeties in not resolved from the foo.properties file.

    Any idea ??

    Regards
    Andrea

    Reply
  15. Dan

    Any chance you can make this plugin Java 1.4 compatible? Its simply a matter of replacing the use of String.contains(String) in ReadPropertiesMojo.java with usage of String.indexOf(String) != -1

    Reply
  16. Nishant

    I am using the script to refer to a properties file.I have included the above steps in the POM of my project . When i run mvn clean , all it says is Try downloading the file manually from the project website.

    Then, install it using the command:
    mvn install:install-file -DgroupId=org.codehaus.mojo -DartifactId=properties
    -maven-plugin \
    -Dversion=1.0-SNAPSHOT -Dpackaging=maven-plugin -Dfile=/path/to/file
    when i downloaded from http://snapshots.repository.codehaus.org/org/codehaus/mojo/properties-maven-plugin/1.0-SNAPSHOT/ properties-maven-plugin-1.0-20070614.192016-1.jar, it doesnt install. already i’ve tried for http://www.kashmir.ca/properties-maven-plugin.zip, its contains sourece code , can any one tell me how to install and use this plugin ?

    Reply
  17. Sam

    Thanks I’ve been searching far and wide for this. you’ve got a typo in the last example above:

    maven-properties-plugin

    should be

    properties-maven-plugin

    Thanks!

    Sam

    Reply
  18. Richard Goodwin

    A Question:

    But, first, this plugin is great. Extremely useful. It should be in the default distribution.

    I actually got curious and looked at the code. How do these properties get made available to other plugins? (IE: the rest of the pom and execution). I see you define a new Properties() object. But, I don’t see it where it gets “injected” (using maven terms here) into the execution context; and therefore made available to the rest of the project.

    Is that the reason you have defined: private MavenProject project?

    Note, I am viewing code from the codehaus sandbox (trunk branch).

    Again, work much appreciated.

    Richard

    Reply
  19. Richard Goodwin

    Ok,

    Does plexus then automatically associate new properties objects with the MavenProject. In the source I a looking at I don’t see that call directly .

    In your code I see:

    Properties projectProperties = new Properties();


    projectProperties.load( stream );

    I see that there is a definition of a mojo/plugin annotated prop at the top of the code:

    MavenProject project;

    earlier.

    Just by defining this there is an implicit connection between the properties and the project.

    Hope this is not too much. I am just trying to understand the Dark Art of Maven plugins (and I guess to some degree maven in general).

    Thanks, Richard

    Reply
  20. arsenalist

    I see what you’re saying, the call to “new Properties()” isn’t needed since this line happens soon after killing the reference:

    projectProperties = project.getProperties();

    followed by:

    projectProperties.load(stream);

    The “project” is injected by Maven automatically and I just use it’s getProperties() method to shove more properties in there.

    Reply
  21. Colin Rogers

    I can’t see what I’m doing wrong. I’ve a very simple setup;

    pom.xml;

    org.codehaus.mojo
    properties-maven-plugin
    1.0-SNAPSHOT

    initialize

    read-project-properties

    src/main/resources/app.versions.properties
    src/main/resources/app.default.properties
    src/main/resources/app.my.properties

    In app.versions.properties;


    selenium-version=0.9.0
    spring-version=2.0.7
    wicket-version=1.3.0-beta4

    (Note: hard coding these versions was fine. Using these same name/values as normal pom.xml properties was fine.)

    An example of how my dependancies are setup are as;

    org.springframework
    spring-hibernate3
    ${spring-version}

    etc etc.

    Yet on install I get;


    [exec] Downloading: http://maven.openqa.org/org/springframework/spring-hibernate3/${spring-version}/spring-hibernate3-${spring-version}.pom
    [exec] Downloading: http://repo1.maven.org/maven2/org/springframework/spring-hibernate3/${spring-version}/spring-hibernate3-${spring-version}.pom

    I’ve put in rubbish for the file names and it reports FileNotFound, so I know it’s running when I put the read files in. I’ve tried taking out the “-” from the varible names, taken out all comments… dunno what else to try!

    It really is quite exasperating! This is about as simple as it gets and it doesn’t work! I must be doing something stupid or obvious, or stupid *and* obvious – I just can’t work it out!

    Any help would be appreciated!

    Reply
  22. Colin Rogers

    Okay – it’s still mashed – if you could reply directly, if you can’t be bothered to sort out my post!! šŸ™‚

    Reply
  23. arsenalist

    Colin, this is a known bug with Maven. See the discussion with Eric Schwarzenbach in the comments of this post. You might have to manually specify the version numbers in the pom.xml because the first thing Maven does is resolve dependencies (not read property files) so we’ll always be losing the race.

    Reply
  24. Colin Rogers

    I’ve a new problem now!

    I’ve got the properties working, and I’m holding the location of tomcat in the varible “tomcat-home”. My cargo plugin uses that variable, happily, through the build cycle. I’ve had to set a second execution tag for running properties plugin during the site phase.

    But now I’ve the problem where I want to run “cargo:deploy” or “cargo:start” and neither ever run the properties plugin whatever phase I specify, and hence “tomcat-home” is never specified.

    Is there a;

    please-run-this-before-anything-else-whatever-target-I-bloody-run-thankyou

    Or would that be too easy for Maven? šŸ™‚

    Reply
  25. ddd

    I have a multi project with root POM setting:

    org.codehaus.mojo
    properties-maven-plugin
    1.0-SNAPSHOT
    false

    initialize

    read-project-properties

    src/main/properties/app.properties

    In root project when I echo property from file the value is OK but in child projects it echoes ${var}. Is there any way to make parent properties from app.properties available in child projects too. I added configuration false becouse I dont nead any properties files in child projects.

    Reply
  26. ddd

    In previous reply I ment: I added configuration inherited == false for properties-maven-plugin, becouse I dont nead any properties files in child projects.

    Reply
  27. Sree

    Sorry to mess up the config..Let me try to post the config properly.
    ERROR:

    [ERROR] BUILD ERROR
    [INFO] One or more required plugin parameters are invalid/missing for 'properties:write-project-properties'
    [0] Inside the definition for plugin 'properties-maven-plugin' specify the following:

    ...
    VALUE
    .

    My config

    org.codehaus.mojo
    properties-maven-plugin
    1.0-SNAPSHOT

    generate-resources

    /path/to/app.properties

    write-project-properties

    Any help would be greatly appreciated.

    Thanks,
    Sreekant

    Reply
  28. Sree

    <code> tag didn’t seem to work… here is another try.
    My Config:
    <plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>properties-maven-plugin</artifactId>
    <version>1.0-SNAPSHOT</version>
    <executions>
    <execution>
    <phase>generate-resources</phase>
    <configuration>
    <outputFile>//path/to/app.properties</outputFile>
    </configuration>
    <goals>
    <goal>write-project-properties</goal>
    </goals>
    </execution>
    </executions>
    </plugin>

    Here is the error I am getting:
    [INFO] ————————————————————————
    [ERROR] BUILD ERROR
    [INFO] ————————————————————————
    [INFO] One or more required plugin parameters are invalid/missing for ‘properties:write-project-properties’
    [0] Inside the definition for plugin ‘properties-maven-plugin’ specify the following:
    <configuration>

    <outputFile>VALUE</outputFile>
    </configuration>.

    Thanks,
    Sreekant

    Reply
  29. Sree

    I hard coded the path to an existing empty file. Still get the same error. “read-project-properties” works fine with similar path.

    On the different node, what is the difference between “read-project-properties” and the maven filters? I noticed that the filter would replace the tokens in the resource files copied to classes where as this plugin doesn’t. I am new to maven… please forgive my ignorance but how is this supposed to work when I deploy the generated war file to app server?

    Thanks,
    Sreekant

    Reply
  30. Gunnar Hillert

    Can it be that the loaded property-variables are not available for plugin configurations? (Similar to the case that I cannot use them for dependencies either?) If that is the case that would really stink. Or do I maybe miss something here?

    I am loading the properties successfully and it works fine e.g. for:

    ${property.name}

    But it does not work for:

    org.codehaus.mojo
    dbunit-maven-plugin
    1.0-beta-1

    ${propery.dataType
    ${property.jdbc.driverClassName}
    ${property.username} …

    Reply
  31. kkrugler

    I’m getting the same problem as Sree, using 1.0-alpha-1 and alpha2. I’ve tried hard-coded paths, same problem. This occurs for both reading and writing properties. In all cases I get a build error that says:

    [INFO] One or more required plugin parameters are invalid/missing for ‘properties:read-project-properties’

    [0] Inside the definition for plugin ‘properties-maven-plugin’ specify the following:

    <configuration>

    <files>VALUE</files>
    </configuration>

    Any more thoughts on this, or a solution?

    Thanks,

    — Ken

    Reply
  32. Ashesh

    @Sree and @kkrugler : If you are trying to run the goal directly like “mvn properties:write-project-properties” it will fail because your outputFile config is tied to only a phase execution. If you want it to work directly, put the configuration outside of executions, e.g.: plugins >> plugin >> configuration >> outputFile

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s