Showing posts with label maven 2. Show all posts
Showing posts with label maven 2. Show all posts

Saturday, August 08, 2009

Easy license headers with maven

If you are like me you probably hate trying to maintain license headers on your source code files. It has to be done for pretty much all of my projects (since I deal in open source 99% of the time) but it is pure drudgery. I found a great plugin for maven 2 which makes this a piece of cake (very easy). The maven-license-plugin can (optionally) check your source files for headers (you control which ones or just use the defaults) and add in or replace the headers for you. Forget about doing this manually anymore; those days are over. You just specify a license header template like this (i.e. create a file, I use LICENSE_HEADER):

Copyright (C) ${year} ${holder} <${contact}>

This file is part of ${name}.

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.

Then add something like this to your project pom.xml (in the build section under plugins):

<plugin>
<groupId>com.google.code.maven-license-plugin</groupId>
<artifactId>maven-license-plugin</artifactId>
<configuration>
<header>${basedir}/LICENSE_HEADER</header>
<excludes>
<exclude>target/**</exclude>
<exclude>m2-target/**</exclude>
<exclude>**/*.properties</exclude>
</excludes>
<properties>
<name>${project.name}</name>
<year>${project.inceptionYear}</year>
<holder>Aaron Zeckoski</holder>
<contact>azeckoski@gmail.com</contact>
</properties>
<encoding>UTF-8</encoding>
</configuration>
<executions>
<execution>
<goals>
<goal>check</goal>
</goals>
</execution>
</executions>
</plugin>

You need to add in the plugin repo in the pluginRepositories section:

<pluginRepository>
<id>mc-release</id>
<url>http://mc-repo.googlecode.com/svn/maven2/releases</url>
</pluginRepository>

That config will cause the check to run on every build (ignoring properties files is a good idea since the plugin has trouble with them). Files with a missing license header will cause the build to fail ensuring you remember to run the command to format them. The properties you set there will fill in the ${field} vars in the license header template.

Now run the maven command to check for license headers:
mvn license:check
or simply do a build (which will also run the check):
mvn clean install
You should get a report about the files missing license headers.
Run this command and all the license headers will be added or updated to match your template:
mvn license:format
One final note, you can remove all the license headers using "mvn license:remove". Very cool.

Thursday, July 16, 2009

My first week with Groovy and Grails

I spent time over the last week learning about Groovy (a dynamic language for the JVM) and Grails (a code by convention web application framework built on Groovy) so I thought I would write up my impressions and some of the fun things I learned.
So you have a sense of where I am coming from, I am a long time Web applications and Java/PHP/Javascript/Perl developer. I am somewhat newer to Python and Ruby but I prefer Python. I am a REST and Open Source advocate when I am in the right mood.

If you are totally unfamiliar with Groovy then I recommend you take a look at this post as it lays out the reasons why you might want to learn more about it:
http://codetojoy.blogspot.com/2009/06/case-for-groovy.html

If you know you are going to be writing web-apps then just skip Groovy and go straight for Grails. If you are looking to do some JSR-223 (Java Scripting) stuff (with Groovy) then Groovy is the place to focus on. Either way, you will need to get familiar with the basics of Groovy so look at these:
http://groovy.codehaus.org/Quick+Start
http://groovy.codehaus.org/Collections
Feel free to checkout some sample Groovy scripts I made which illustrate many of the key concepts.

The Getting Started Guide for Groovy is huge and not really a very good place to try to get started unfortunately. That said, the Beginners Tutorial is pretty good, especially the section on closures.

If you want to get going with Grails then it is a little bit easier since it mostly builds on Groovy. Grails borrows heavily from Ruby on Rails so if you are familiar with it then things will come to you quickly. This is the best place to start (not surprisingly):
http://www.grails.org/Quick+Start
I really liked the screencasts (which are oddly located here also). They provided a nice introduction to Grails without much effort. When you are ready for a little more the tutorials are a good next step.

Things I learned in no particular order:
  • Maven and Grails do not get along - There is some really weak maven integration available but it does not work very well. The structure of grails (e.g. src/groovy) does not match the maven standard structure (e.g. src/main/groovy). Mostly maven just allows you to run the grails build commands which is easier to do with grails itself. I struggled with this for awhile before just giving up on using maven. The Grails team recommends using Ivy if you want to add dependency management (or Grails plugins which are preferred if they are available).
    The grails and groovy artifacts are available in maven repositories which is nice.
  • Grails and Eclipse don't easily integrate - The Groovy plugin is pretty good (not great) but the build integration is pretty poor and requires you to jump through hoops. It seems like the integration with IDEA is a lot better and recommended by the Grails team.
  • Groovy supports closures - The closure support in groovy is great and very easy to use. I found myself writing closures like crazy (even more than in Javascript) and it made the code very clean.
    NOTE: I ran across one weird bug where passing in a String[] to a closure causes it to be misinterpreted as a collection of separate arguments for each array entry. There are hacks to get around this but be aware that it may bite you.
  • Grails has a great plugin system - Grails has a pretty powerful plugin system which allows easy extension of a grails app. The plugins seems to be very easy to install and fairly easy to write. There is a complete guide if you are interested in developing your own plugins.
  • Grails app creation puts in too much stuff - The structure generated by grails create-app has a lot of stuff in it which you will probably want to cleanup (like the hibernate plugin by default for example). There is no uninstall for plugins so just remove the dir of the plugin to get rid of it. Be careful to not leave in a lot of things you are not going to use and clean out the sample stuff under web-app as well.
  • Grails convention is not very flexible - Grails prides itself on "code by convention" and "convention over configuration" and it does a good job of establishing a lot of conventions. It takes a little while to get used to them but if you follow them then things are pretty easy. Unfortunately, this implies that it is possible to override the convention using configuration if needed and in many cases it is not. I have been bitten a few times already when I tried to do things that are not "on the rail".
  • Grails uses prototype.js by default - The built in javascript engine in Grails is the portal/multi-framework unfriendly prototype.js. I can't use it so I am playing around with using jQuery instead (so far this is proving to be manageable). There is a jQuery plugin which helps make this easier.
I am still getitng used to things but I am not sure what Groovy/Grails gains me over using Jython/. It seems like Jython does everything Groovy does plus it has the massive Python community for support.
As far as scripting languages go I think I prefer PHP, Javascript, Python, and Perl (in that order) over Groovy but this may just due to a lack of familiarity on my part.

Friday, December 12, 2008

Workaround for mvn release:prepare failures

If you are using subversion 1.5.1+ like me you are likely to be frustrated by constant failures while attempting to use the Maven Release Plugin to prepare and perform releases.
There is a simple workaround for this which works like so:
  1. Run mvn release:prepare
  2. After if fails run svn update
  3. Run mvn release:prepare again
  4. Success!
The errror here appears to be caused by changes in subversion 1.5.1 so hopefully that will be fixed in the future.

Sunday, May 11, 2008

Fun with Maven 2 dependencies

I learned some new Maven 2 tricks this weekend while experimenting with things. In general it can be a real pain when you are developing a piece of framework code which a few projects depend on and you find a minor issue which requires a new release. Typically you have to go around updating lots of POMs. Well, no longer! In maven 2 you can now specify version ranges which can save you a lot of updating when newer versions of packages come out.
Normal maven 2 depedencies look like this:


<dependency>
<groupId>org.sakaiproject.entitybroker</groupId>
<artifactId>entitybroker-api</artifactId>
<version>1.3.3</version>
<scope>provided</scope>
</dependency>


Unfortunately, if a bug fix is released for this which is 1.3.4 then I will not pick up on the new version and would have to explicitly put it in. However, if I want to pick up any minor version updates for a project and I want the minimum version to be 1.3.3 (but less than 1.4.0) I can do this:


<dependency>
<groupId>org.sakaiproject.entitybroker</groupId>
<artifactId>entitybroker-api</artifactId>
<version>[1.3.3,1.4.0)</version>
<scope>provided</scope>
</dependency>

A word of warning though, if the packages you are using do not adhere to standards of versioning you can really get in trouble if a new version comes out with an incompatible interface. Of course, if that happens you simply adjust the version range in the POM.

More info here: http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution