mitigate through maven-replacer-plugin phase issue

Hi, Happy Friday!

We often want to change certain application properties in Maven build process. A very common one is the build timestamp. A nice plugin we can use is the maven-replacer-plugin. Unfortunately, setting the <phase> tag in this plugin is not always straightforward, especially when you deal with different kind of packaging such as bundle for Felix, instead of jar files. Often the replacer runs too early (when the file being replaced has not been moved into the target folder) or too late (when the actual package has already been built).

I found a way to mitigate through the situation, a method may not be so orthodox but works every time.

Assume your file myapp.properties has items to be replaced on contains this line:

build.timestamp=@2017.0324.1420@

And the pom.xml can have this property and the replacer plugin config:

 <properties>
 <timestamp>${maven.build.timestamp}</timestamp>
 <maven.build.timestamp.format>yyyy.MMdd.HHmm</maven.build.timestamp.format>
 </properties>

....

<plugin>
 <groupId>com.google.code.maven-replacer-plugin</groupId>
 <artifactId>replacer</artifactId>
 <version>1.5.3</version>
 <executions>
 <execution>
 <phase>clean</phase>
 <goals>
 <goal>replace</goal>
 </goals>
 </execution>
 </executions>
 <configuration>
 <file>${project.basedir}/src/main/resources/myapp.properties</file>
 <replacements>
 <replacement>
 <token>@[\d]{4}\.[\d]{4}\.[\d]{4}@</token>
 <value>@${timestamp}@</value>
 </replacement>
 </replacements>
 </configuration>
 </plugin>

Then each time the plugin is run at clean phase, it will look for the regex pattern, in this case:

@[\d]{4}\.[\d]{4}\.[\d]{4}@

and replace it with the a current timestamp so the resulted line becomes:

build.timestamp=@2017.0324.1428@

This way, each time the build timestamp can be replaced correctly at the earliest phase of the build. When use this property in application, simply remove the pattern holder, in this case the two @’s before using it.

Again it is not super elegant or orthodox. But I have dealt with the phase issue with this replacer plugin and felt the time spent on it is totally not worth it. The above mitigating solution gives me expected result every time Maven runs.

Cheers!

-TY

Integrate Git into ANT targets

Hi, There:

For some of our projects, we still use ANT instead of Maven. And we have the need to build project directly out of GIT using ANT targets to ensure consistency for production deployment. If you don’t use Jenkins, then running ANT from Eclipse or Command Line is the option to have. The integration of ANT and Git is not all that straightforward. From the web, there are some good examples of how to do this, and this one works for us:

<target name="git.get.source">
 <delete dir="${LOCAL_PATH}"/>
 <mkdir dir="${LOCAL_PATH}"/>
 <git command = "clone">
 <args>
 <arg value = "--progress" />
 <arg value = "--verbose" />
 <arg value = "${GIT_URL}" />
 <arg value = "${LOCAL_PATH}" />
 </args>
 </git> 
 </target>

<!-- git macro utils setup -->
 <macrodef name = "git">
 <attribute name = "command" />
 <attribute name = "dir" default = "" />
 <element name = "args" optional = "true" />
 <sequential>
 <echo message = "git @{command}" />
 <exec executable = "${GIT_EXE_PATH}" dir = "@{dir}">
 <arg value = "@{command}" />
 <args/>
 </exec>
 </sequential>
 </macrodef>

The above ANT scripts assumes that you have installed Git client and ${GIT_EXE_PATH} is where the git.exe resides. After the source code project is cloned into ${LOCAL_PATH}, building project is simply to run typical ANT targets such as compile and jar.

There is one error I have encountered, however, if the ${LOCAL_PATH} is synchronized into any Eclipse project,  this annoying error would occur the next time you run the git.get.source:

Unable to delete ..
.git\objects\pack\pack-b38c095fff6a391435a492ccf49985ed82dfd245.pack

It turns out that Eclipse is keeping an eye on the Git status as well and have a file lock on this pack file. It is not really a bug per se, just multiple processes are working on the Git Status of the clone.

The only way to get around this issue if you want to run ANT script within Eclipse is to use a folder for ${LOCAL_PATH} that is not under the control of Eclipse project. For example, use c:\temp\myproject\ for ${LOCAL_PATH} would work just fine. Since we don’t plan to modify the codes from GIT in Eclipse but simply want to build the project out of Git sources, this trick is good to use.

Cheers!

-Tony