Robert Savage

I recently joined as a contributor to the open source “google-api-translate-java-maven-plugin”  project.  This project provides a Maven Mojo/Plug-in that will perform automated language translations for your Java resource property files using the Google Translation API.

To aid the development process, it is helpful to see your application running in other languages so that you can see where resource string may have been missed and where text positioning, sizing, and alignment issues show up.   I personally feel that it is helpful to have this early on in the project development cycle long before the resource property files are ready to be sent out of house for proper translation.   So how can I get my property files translated and add that as an automated step in my lifecycle management or build process?   … Enter “google-api-translate-java-maven-plugin“.  This Maven plugin can be pointed at a source language file and can be configured for all the desired languages to generate, as long as it is a supported language by the Google Language API.

While this plugin certainly worked to meet my needs out of the box, there were a few features that I wanted to expose to provide greater flexibility and control over the translation process.    I added the following features as Version 1.3:

• console progress display to show the current translation cycle status
• overriding source properties file name
• output file encoding options
• exclusion list of named properties to exclude from generated output files
• comment header for generated output files
• smart-sync feature to limit translation effort to only added and changed properties
• pass-thru list of named properties to include in the generated output files, but not translate

For a complete detailed listing of these features and their configuration properties, please visit this Wiki article on the project’s Google Code site:  New_Features_Version_1_3

Here is an example of a Maven project POM file configured to use these options:  UTF-8 Sample Project POM

The feature that I am most proud of is the Smart Sync feature.  Rather than performing translations on all property values for all generated output property files in all languages, I wanted a way to only perform the translation work on property values that have been added or updated and remove any properties form the output files that were removed from the source language property file.  This feature greatly reduces the amount of time it take to run this plugin since it is really only calling out to the Google API for additions and updates.  Before this feature it was taking in excess of 30-45 minutes to run through and perform the automated translations, and this length of time made it prohibitive to include this step in the regular build process.   With this feature enabled, it can take as little as 5 seconds

One other notable feature is the support for saving the output generated property files with alternate file encodings such as UTF-8 and the option to include byte-order-mark (BOM) bytes at the beginning of the file.   While the default Java Properties reader and writer cannot make use of this,  there are other property file  implementation such as the one in the Spring Framework that can make use of UTF-8 or UTF-16 encoded files.  With the files encoded in UTF-8, we can see Japanese, Chinese, Russian, and Arabic character sets in the property file editor and all of the bytes that make of these characters do not have to be escaped making for an unreadable property file.

For more information an examples on how to use this Maven plugin, please visit the project Google Code site:  “google-api-translate-java-maven-plugin“

Well, I have started my first open source project. It is called “maven-external-dependency-plugin“ and is hosted over on the Google Code site. I started using Maven about a year ago in a large project at work and have really gown to love all that it offers and its immense extensibility. We use Maven for Java and Adobe Flex based projects and it works very well for us. However, one of the really frustrating things for me is to come across dependencies that are not hosted in a public Maven repository. On the Java side, this is a bit of a more rare occurrence, but with Flex, a large portion of that community is not Maven-minded. This means that I have to mange those dependencies by adding them to my local M2 repository and then manually deploy them to a group repository so that all team members can access these artifacts. Keeping them up to date becomes a pain mainly because of the manual effort involved and because it is not part of the standard workflow. I have been using batch files for managing these one-offs but that leaved me as the sole person responsible for maintaining these dependencies.

So … there has to be a better way … Right?

Well, I have thought for a long time … wouldn’t it be helpful to have a Maven plugin that could automatically download a file from a URL and install it to my local repository and them maybe also deploy it to my group’s Maven repository?    I has looked around at several Maven plugins out there trying to piece together a solution to perform this task.  But I did not find an out of the box solution that could be easily implemented and be robust and straight-forward.   So why not created my own mojo and contribute to the community?   How difficult could it be?

My first experience with Maven plugin development was working on a custom modified version of the Israfil Flex plugin to compile our Flex-based projects about a year ago.  Out of the box it got me to 90% of what I needed to accomplish, but there were something it could not do when compiling Flex modules, I don’t remember the specifics now but I think it had something to do with compiling multiple Flex modules and generating multiple module artifacts in a single project.  I abandoned this effort long ago in favor of the much more capable and powerful  “flex-mojos“.  So I jumped into the Java code for this plugin and made the necessary tweaks to meet my needs.

I remembered how simple it was to extend and how easy it was to create a Maven plugin so this weekend I created the “maven-external-dependency-plugin“.  This Maven (mojo) plugin is used to aid in managing external Maven artifacts that are not published public Maven repositories.

The goal of this project is to allow you to define a configuration for external (not hosted in M2 repo) artifacts that will automatically download the artifact, install to you local M2 repository and optionally deploy to your team/company M2 repository.

Granted there is still a bit of manual effort involved for updating the POM configuration information for these external dependencies when new versions are available, but this should eliminate the manual effort of having to install and deploy these types of files by hand.

Here is an example of an artifact configured to download from an external URL and install to the local Maven repository

   <!-- THIS JAR IS HOSTED ON GOOGLE CODE,
        BUT IS NOT AVAILABLE IN A MAVEN REPO -->
   <artifactItem>
       <groupId>com.google.code</groupId>
       <artifactId>google-api-translate-java</artifactId>
       <version>0.92</version>
       <packaging>jar</packaging>
       <downloadUrl>
          http://google-api-translate-java.googlecode.com/files/google-api-translate-java-{version}.jar
       </downloadUrl>
       <install>true</install>
       <force>false</force>
   </artifactItem>

Please visit this link for a complete example of a POM file configured to this this plugin: http://code.google.com/p/maven-external-dependency-plugin/source/browse/trunk/maven-external-dependency-plugin-test/pom.xml

Please visit the “maven-external-dependency-plugin” project site on Google Code for more information.