maven groovy compiler plugin

    <build>
        <plugins>
            <plugin>
                <groupid>org.codehaus.gmaven</groupId>
                <artifactid>gmaven-plugin</artifactId>
                <version>1.3</version>
                <configuration>
                    <debug>true</debug>
                    <verbose>true</verbose>
                    <stacktrace>true</stacktrace>
                </configuration>
                <executions>
                    <execution>
                        <goals>
                            <goal>generateStubs</goal>
                            <goal>compile</goal>
                            <goal>generateTestStubs</goal>
                            <goal>testCompile</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>
    
    <dependencies>
        <dependency>
            <groupid>org.codehaus.gmaven.runtime</groupId>
            <artifactid>gmaven-runtime-1.7</artifactId>
            <version>1.3</version>
        </dependency>
    </dependencies>

Integration test coverage of WAR using cobertura

I've made a fork of codehaus cobertura-maven-plugin which enable the so long waited integration test coverage feature MCOBERTURA-86 until they commit something cool.

http://code.google.com/p/cobertura-it-maven-plugin/

Disable Jetty 7 URL rewriting sessionid param

With Jetty 7, the documentation (http://wiki.eclipse.org/Jetty/Howto/SessionIds) said to use this configuration, but it does not work :( (EDIT : I've updated it :D)

<context-param>
    <param-name>org.mortbay.jetty.servlet.SessionURL</param-name>
    <param-value>none</param-value>
  </context-param>

So, I browse the source code and found the org.eclipse.jetty.server.SessionManager class which define the param name. The right configuration is this one :

<context-param>
    <param-name>org.eclipse.jetty.servlet.SessionIdPathParameterName</param-name>
    <param-value>none</param-value>
  </context-param>

Hope this help !

References :

http://groups.google.com/group/liftweb/browse_thread/thread/267bcda70fdde149/a32df23704edd5cf?lnk=raot

http://www.mail-archive.com/liftweb@googlegroups.com/msg11348.html

Dear Oracle, can we have our nice javadoc URLs back?

source : http://grep.codeconsult.ch/2010/07/21/dear-oracle-can-we-have-our-nice-javadoc-urls-back/

Dear Oracle,

A while ago you bought Sun, and IIRC promised to do good things for Java. Or at least indicated you would. Or something like that.

Now, a bad thing happened a few days ago. Not a bad bad bad thing, just a tiny annoying change in the cool URLs that Sun used to publish the JDK’s javadocs. Not annoying annoying annoying but not nice.

Even Google remembers: today if I search forIndexOutOfBoundsException on Google it returns the following URL:

http://java.sun.com/j2se/1.5.0/docs/api/java/lang/IndexOutOfBoundsException.html

Which is a cool URL that shouldn’t change.

Now, requesting this URL today causes a redirect to:
http://download.oracle.com/docs/cd/E17476_01/javase/1.5.0/docs/api/java/lang/IndexOutOfBoundsException.html

Which is also somewhat cool, but not as much. Factor 10 down in coolness. It makes me assume that you’re serving javadocs from a CD, and that CD’s identifier is E17476_01. That’s useful info if you’re the filesystem driver who’s reading the CD, but I doubt filesystem drivers are searching for javadocs on Google. Also, I’m not looking at downloading anything. Just browsing, okay?

Cool URLs shouldn’t change.

Can we have the old one back? Ok, maybe with java.oracle.com instead of java.sun.com – you bought them anyway. But please please please, let the poor CD filesystem driver alone!

Thanks.

source : http://grep.codeconsult.ch/2010/07/21/dear-oracle-can-we-have-our-nice-javadoc-urls-back/

How to group by objects in java... in a simple way ?

Sometime it is very useful to group objects by some criteria.

We have a collection of Person we want to group by their Age.

public class Person {
    public String getName() {...}
    public int getAge() {...}
}

The first method we can use is the following :

Collection<Person> persons = ...;
Collection<Person>  personsAgeIs20 = new ArrayList<Person>();
for (Person person : persons) {
    if (person.getAge() == 20) {
         personsAgeIs20.add(person);
    }
}

Again, using google-collections, the magic class is Multimaps

Grouping Person by Age is as simple as this :

Collection<Person> persons = ...;
Map<Integer, Person> personsGroupByAge = Multimaps.index(persons, new Function<Person, Integer>() {
    public Integer apply(Person person) {
        return Integer.valueOf(person.getAge()); // Integer.valueOf because I don't like autoboxing :-p
    }
});
List<Person> personsAgeIs20 = personsGroupByAge.get(Integer.valueOf(20));

Ok, you tell me, same amout of line, why bother use Multimaps ? Because you don't code the grouping, you code the grouping logic only. Plus, with the first solution we have only grouped by 20, not by other ages. So, the Multimaps way is far more powerful and evolutive.

unit test and new Date()

A lot of code which use new Date() or System.currentTimeMillis() is quite impossible to unit test.

A too-current-in-every-day-life example method :

public class SomeClass {
    public String currentDateAsString() {
        return new SimpleDateFormat().format(new Date(), "yyyyMMdd");
    }
}

The corresponding unit test will not work for so long :

@Test
public void testCurrentDateAsString() {
    Assert.assertEquals("20100622", new SomeClass().currentDateAsString());
}

It will fail tomorrow ;-)

If you own the code, you should use a Date provider. Using library such as google collection (now guava), you can simply use a Supplier.

public class SomeClass {
    public SomeClass(String pattern, Supplier dateSupplier) {
        this.pattern = pattern;
        this.dateSupplier = dateSupplier;
    }

    public String currentDateAsString() {
        new SimpleDateFormat().format(this.dateSupplier.get(), this.pattern);
    }

    private final String pattern;
    private final Supplier dateSupplier;

}

Now the unit test will be much nicer  and more it follows the Law of Demeter :

@Test
public void testCurrentDateAsString() {
    Supplier dateSupplier = Suppliers.ofInstance(newDate(22,6,2010));
    Assert.assertEquals("20100622", new SomeClass("yyyyMMdd", dateSupplier).currentDateAsString());
}

*newDate may be a static date factory method you wrote, it is here for readability.

If the code come from scary legacy code, you should use jmockit or powermock (see Can I mock static methods).