public boolean addElement(final T element) {
  if (!this.collection.contains(element)) {
    return this.collection.add(checkNotNull(element, "element")); //$NON-NLS-1$
  }

  throw new IllegalArgumentException("May not add duplicate elements"); //$NON-NLS-1$
}

So I’m not directly exposing the underlying collection but rather offer addElement, addAllElements, removeElement, etc. methods to work with the collection from the outside. This is done so that no one can insert or remove anything without the objects (that is the collection holder) knowledge. In the above example I’m restricting new elements to be non-null and any new element must not be in the collection already. Since this code looks more or less the same for every collection I’m using I thought about how to apply the DRY principle and move that piece of code somewhere else (that is away from the addElement, etc. methods).

At first I thought aspect oriented programming (always wanted to try AspectJ) but ditched it later on for something simpler. My final solution introduces a single static factory method which creates a so called CollectionJoiner which offers its users a DSL-like language to combine/merge/join collections with single elements are other collections. The code below was the result after my first iteration:

public boolean addElement(final T element) {
  join(this.collection).with(element);
}

This was is fairly simple because all it takes is to move the common code from all those addElement-methods to a central place (I’ve used static imports here to make the line even shorter). However I applied the same restrictions to every collection I was going to join so others may not be able to work with this code (e.g. all those who want to allow null-able objects). For that I came up with a new method called restrictedOn() which takes a so-called Restriction as parameter and applies all given restrictions to the element (or all elements of the given collection) to join. It looks like the following:

public boolean addElement(final T element) {
  join(this.collection)
     .restrictedOn(Restrictions.NO_DUPLICATES)
     .restrictedOn(Restrictions.NON_NULL_VALUES)
     .with(element);
}

That way I can apply different restrictions to different collections but I’m still able to define those restrictions only once and use them as often as I want to. The code for the final with() method looks quite simple as well:

public boolean with(final T element) {
  for (final Restriction<T> restriction : this.restrictions) {
    restriction.apply(element);
  }

  return this.collection.add(element);
}

Currently I’m looking into google-collections (and possible google-guava) to see whether the Restriction interface can be replaced with Predicates. I’m already using them with those checkNotNull-methods (see first example for an example..) and would be happy to integrate them into the CollectionJoiner class. Maybe I’ll add a method which sets the default restrictions (or predicates) too, so when you never ever want to work with null-objects you don’t have to specify that every time.

Any comments/suggestions on this?

public enum Month {
    January,
    February,
    ...
    December;
} 

To test that you could just use the valueOf(String) method of any enumeration and see if the resulting object is null or not. So you would call

assertThat(Month.valueOf("January"), is(notNullValue()));

for every item in the enumeration and probably create different test methods for each of those calls. Instead of that you could also use parameterized tests (with @RunWith(Parameterized.class) annotation) but I don’t like constructors in test classes. So with the release of JUnit 4.5 we now got Theories which are similar but not the same as parameterized tests. Instead of parameters and constructors with private fields you use data points and that’s it basically. With that we can replace all those more or less similar test cases for every enumeration item with a single:

@Theory
public final void monthIsNotNull(final String month) {
    assertThat(Month.valueOf(month), is(notNullValue()));
}

What’s missing here is the already mentioned DataPoint. You declare one with the @DataPoint annotation or multiple data points with the @DataPoints annotation like follows:

@DataPoint
public static final String JANUARY = "January"

After that you have to annotate your test class with the @RunWith(Theories.class) and JUnit will automatically run the theory on all available data points. You can take a look here to see how I applied that to unit-testing inside the Denove-core package.

InDefero is basically a clone of GoogleCode but with git, mercurial and subversion support. The motto of InDefero “beautiful simplicity“

So basically it is a bugtracker along with code-hosting and -review features. They also offer you some managed hosting space go get you started or you could download the whole thing and deploy it yourself. Sounds nice and looks good so far.

Since i can no longer live without Mylyn i digged deeper to see if there is any support for it (either on the side of InDefero/Ceondo or Eclipse/Tasktop) but to my disappointment there is was none. So i decided to use the generic web template connector feature from Mylyn to connect both Eclipse and InDefero. It still needs some work but i can query for existing tasks and create new ones just fine. Editing of tasks is done via the internal web browser so that should work too (as long as you are online). The configuration is listed below (i’m using Eclipse 3.5 and Mylyn 3.2):

Server: Your Project Adress (e. g. http://denove.indefero.net/p/core)

Label: Whatever you want

User ID and Password: Should match your user ID and password

Task URL: ${serverUrl}/issues/

New Task URL: ${serverUrl}/issues/create/

Query Request URL: ${serverUrl}/issues/search/?q=${SEARCHTERM}&s=Search

Query Pattern: <td>({Id}.+?)</td><td><a href=”/p/core/issues/({Id}.+?)/”>({Description}.+?)</a>

2 things should be noted here:

1) I’ve put SEARCHTERM in the query request URL. I’m using this to build the different query later by just overriding the SEARCHTERM parameter.

2) The bold sequence in the querry pattern (/p/core/) is actually part of my ${serverUrl} adress but i could neither get ${serverUrl} to work nor any other self-defined parameter. So you have to change that to whatever your project URL looks like. Below or some screenshots for those without Eclipse ..

Repository Setup

Query Setup

Als Beispiel etwa http://www.shoss.de/ und http://shoss.de/. Ist beides das selbe und doch unterschiedliche Adressen. Mittels des oben Ausdrucks kann ich jetzt also sagen, dass ausschließlich http://shoss.de/ im Index landen soll und nicht noch zusätzlich die www-Variante..

Ein kurzer Besuch bei Google hat mir die erste Idee bei devdaily.com gegeben, bei der mittels Schlüsse in einer Property-Datei ein einzelner Token durch mehrere Zeilen ersetzt werden soll. Um den Schlüssel auf mehrere Zeilen auszudehnen hat man dort  ${line.separator} genutzt, was allerdings bei mir nicht funktioniert hat. Warum-auch-immer wollte Ant (1.7) ${line.separator} nicht auflösen und daher war das Ergebnis nicht ganz so schön. Außerdem war mir auch nicht ganz klar, ob ich die einzelnen Zeilen auch (unterschiedlich) einrücken kann. Da die HTML Seiten auf meiner Homepage alle möglichst gleichmäßig eingerückt sind hab ich mir also was anderes überlegt.

Anstelle der Server-Side-Includes (SSI), die ich erst letztes Jahr eingeführt hatte, wollte ich ich Ant die Arbeit des Ersetzens erledigen lassen. Die SSIs waren damals auch nur die Notlösung gewesen, weil das mehrzeilige Ersetzen mit Ant noch nicht so wollte. Die Ant-Lösung finde ich deswegen schöner, weil ich hier ausschließlich statischen Inhalt einfüge, der sich niemals dynamisch ändert. D. h. alle Besucher bekommen vom Server den selben Inhalt zugespielt. Der Einsatz von SSIs ist für sowas zwar möglich aber irgendwie überflüssig, wenn ich schon vor dem Hochladen der HTML Dateien den Inhalt anpasse. Was ich also gemacht habe ist folgendes:

1. Mittels LoadFile Task die bisherigen Include Dateien ausgelesen und an einen Wert gebunden.
2. Die jeweiligen Tokens durch die jeweiligen Werte ersetzt.

Problematisch dabei sind allerdings wieder die Tokens. Nimmt man irgendwas wie @VCard@ (o. ä.) beschwert sich der HTML-Editor in Eclipse, dass ein einzelnes @VCard@ mittem in einem HTML-Dokument kein richtig gültiges HTML (bzw. XHTML) ist. Schreibt man <p>@VCard@</p> und benutzt den gesamten Ausdruck als Token beschwert sich Eclipse, dass spitze Klammern keine gültigen Tokens sind. Die Lösung ist relativ einfach: Man erstellt neue Schlüssel in der Property-Datei, die diese kompletten Ausdrücke enthalten und referenziert diese im Buildfile von Ant mittels ${Key} und das wars Schön dabei ist auch, dass ich die bisherigen Include Dateien weiterhin nutzen kann, ich also nichtmal eine Zeile neuen HTML Code schreiben musste. Im Ergebnis sieht das dann etwa so aus:

<loadfile srcfile=”${source.dir}/Includes/back-button.inc” property=”back-button”/>

<replace dir=”${deploy.dir}” token=”${backButton}” value=”${back-button}”/>

Mit den beiden Zeilen hab ich mal eben schnell in allen HTML-Dateien einen Back-Button zurück auf die Startseite hinzugefügt.

Wie kommt man da raus ohne auf Tomboy zu verzichten? Ganz einfach die “–search” Option aus dem Starter Menü entfernen Kleine Sache, große Wirkung.

As always everything can be found at http://denove.shoss.de/. And as you may see there the DenoveSE project didn’t quite make it so we are postponing that release to somewhere in june/july.