Teaching Mavenized Grails to Survive mvn release:prepare release:perform with Hudson

Posted on February 10th, 2010 by Reiner.
Categories: Maven, Grails, English.

A mavenized Grails project has 2 competing sources stating the version of the application

  1. <version> within pom.xml
  2. app.version within application.properties

If 2. does not match 1. the grails-maven-plugin will abort the build, urging you to manually fix the version mismatch. Although somewhat clumsy, the release will still succeed if you edit application.properties and re-start the failing mvn release:prepare. However, you’re somewhat stuck, if the release is to be performed from within a continous integration server (e.g. Hudson).

Thus I devised a work-around, that will compare both versions and update the version within application.properties if required. My work-around is far from perfect, as I was unable to integrate it within the Maven lifecycle defined by the grails-maven-plugin. This lifecycle will always and unconditionally bind its own code to the validate phase first (aborting on version mismatches). Therefore I resorted to binding my repair action to the clean phase and changed the goals of the maven-release-plugin to perform a clean before invoking the deploy. Note that this will produce a consistent war (both pom and application.properties set to the release version), but will not resolve the discrepancy within the tagged sources (i.e. application.properties will still state the snapshot version).

Here’s my code. It uses a profile, which is only activated, if the file application.properties is actually present. Thus the code can be included within a parent pom.xml that might be used with non-Grails projects as well:

<profiles>
 <profile>
  <id>enable-reset.application.properties</id>
  <activation>
   <activeByDefault>false</activeByDefault>
   <file>
    <exists>application.properties</exists>
   </file>
  </activation>
  <build>
   <pluginManagement>
    <plugins>
     <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-release-plugin</artifactId>
      <configuration>
       <!-- invoke clean first - see below -->
       <goals>clean deploy</goals>
      </configuration>
     </plugin>
    </plugins>
   </pluginManagement>

   <plugins>
    <!--
     Allow release:prepare/perform to succeed with Grails
     app. Reset application.properties.app.version to
     project.version Sorta hack on clean, as
     grails-maven-plugin:validate ALWAYS runs first and
     connot be preceeded by any other execution
    -->
    <plugin>
     <artifactId>maven-antrun-plugin</artifactId>
     <version>1.3</version>
     <executions>
      <execution>
       <id>reset.application.properties</id>
       <phase>clean</phase>
       <goals>
        <goal>run</goal>
       </goals>
       <configuration>
        <tasks>
         <taskdef resource="net/sf/antcontrib/antlib.xml"
          classpathref="maven.plugin.classpath" />
         <if>
          <available file="application.properties" />
          <then>
           <property file="application.properties"
            prefix="application.properties" />
           <if>
            <not>
             <equals arg1="${project.version}"
              arg2="${application.properties.app.version}" />
            </not>
            <then>
             <propertyfile file="application.properties"
              comment="Grails Metadata file">
              <entry operation="=" type="string" key="app.version"
               value="${project.version}" />
             </propertyfile>
            </then>
           </if>
          </then>
         </if>
        </tasks>
       </configuration>
      </execution>
     </executions>

     <dependencies>
      <dependency>
       <groupId>org.apache.ant</groupId>
       <artifactId>ant</artifactId>
       <version>1.7.1</version>
      </dependency>
      <dependency>
       <groupId>org.apache.ant</groupId>
       <artifactId>ant-nodeps</artifactId>
       <version>1.7.1</version>
      </dependency>
      <dependency>
       <groupId>ant-contrib</groupId>
       <artifactId>ant-contrib</artifactId>
       <version>1.0b3</version>
       <exclusions>
        <exclusion>
         <groupId>ant</groupId>
         <artifactId>ant</artifactId>
        </exclusion>
       </exclusions>
      </dependency>
     </dependencies>
    </plugin>
   </plugins>
  </build>
 </profile>
</profiles>

Links:

2 comments.

Maven - Never Say Never in an updatePolicy

Posted on February 7th, 2010 by Reiner.
Categories: Maven, English.

I want to share a misconception that caused Maven to fail when looking for artifacts. Im my example I was upgrading from Grails 1.2.0 to 1.2.1 and including a dependency to grails.org:grails-core:[1.2.1,1.2.1]. Maven would just complain with Couldn’t find a version in …, although I verified that this particular version is indeed available at the remote repository.

My misconception was, that when declaring a remote release repository <updatePolicy>never</updatePolicy> would only apply to existing artifacts, which - of course - need not be checked for remote changes (release artifacts must not change once they are released).

However, updatePolicy also applies to Maven meta data, i.e. which versions are available (and which one is the most current one). Thus, if there are any artifact versions already present in your local Maven repository, Maven will never download any version that is not yet present in your local repository :-(

See also Maven does not always download artifacts from specified repos.

With release repositories, the default value for updatePolicy is <updatePolicy>daily</updatePolicy>, which should be appropriate for most external Maven release repositories.

As we’re using a local Nexus for both hosting our own company repositories and for proxying external repositories as well, updatePolicy daily is too slow to avoid confusion when accessing internal releases from the Public Repositories group. So I chose to use <updatePolicy>always</updatePolicy> instead and let Nexus settings determine the interval at which it refreshes external repository artifacts:

<repository>
 <!-- Use our local Nexus Public Repositories Group -->
 <id>public</id>
 <name>Public Repositories</name>
 <url>http://ournexus.mycompany.com:8081/nexus/content/groups/public</url>
 <releases>
  <enabled>true</enabled>
  <updatePolicy>always</updatePolicy>
  </releases>
 <snapshots>
  <enabled>false</enabled>
 </snapshots>
</repository>

0 comments.