Exim4 - Virtuelle Domains einrichten

Letzten November habe ich einen kurzen Bericht über Exim4 und /etc/alias veröffentlicht und beschrieben wie man Emailaliase für eine Domain (nur eine) anlegt. Was macht man aber nun, wenn Mailboxen von mehreren Domains auf einer Exim4 Instanz verwaltet werden sollen? Das Stichwort ist (wie auch bei Apache httpd) "virtuelle Domänen". Ich möchte nachfolgend kurz aufzeigen, wie man das ganze zum Laufen bringt (mich hats einen ganzen Sonntag gekostet *fg*, aber es geht hiermit auch schneller).

Einen sehr guten Artikel bzgl. virtuellen Domains findet man hier. Bzgl. virtuellen Aliases sollte man den folgenden Artikel bevorzugen.

Nachfolgende Beschreibung wurde auf einem Ubuntu Server durchgeführt.

Als erstes sollte man bei Exim4 wissen, dass dieser entweder durch das manuelle Ausführen des Skript /usr/sbin/update-exim4.conf oder durch den Wizard 'dpkg-reconfigure exim4-config' die Konfiguration für Exim4 zur Verfügung stellt. Exim4 sieht die geänderte Konfigration mittels '/etc/init.d/exim4 reload'.

Die virtuellen Domains werden in der Datei /etc/exim4/domains.virtual angelegt. Die Aliase für die virtuellen Domains, welche u.a. zur Weiterleitung von Email verwendet werden kann, kann die Datei /etc/exim4/aliases.virtual verwendet werden. Sofern die Dateien nicht bestehen, müssen diese angelegt werden und dürfen nur dem root User zur Verfügung stehen.

Falls die Exim4 Konfiguration in mehrere kleineren Dateien verteilt wurde (/etc/exim4/conf.d/) dann kann das Suchen der richtigen Stelle teilweise einwenig lästig sein. Daher kurz die Dateiangaben, in welchen in ich die beschriebenen Änderungen vorgenommen habe.

Die Änderungen bzgl. den virtuellen Domain habe ich in der Datei /etc/exim4/conf.d/main/01_exim4-config_listmacrosdefs vorgenommen. Einfach die Stelle 'domainlist local_domains' suchen und mit der verwiesen Dokumentation nachführen.
Für die virtuellen Aliase verwendet legt man eine neue Datei unter /etc/exim4/conf.d/router/410_exim4-config_virtual_domains und ändert diese wie in der verwiesen Dokumentation beschrieben.

Network attached storage

Es ist geschehen. Ich habe mir auch eine NAS (Network attached storage) zugelegt. Mein Lieblingshändler in Sachen MP3 und porable Devices K55 hatte das nachfolgende Angebot in ihrem Shop veröffentlicht und ich konnte dieser Offerte nicht widerstehen :)

Ich wollte mir nun schon seit ca. 2 Jahren ein Slimdevice von Logitech kaufen, habe es jedoch aus diversen Gründen immer wieder auf die lange Bank geschoben. Nun bin ich aber stolzer Besitzer von dem Slimdevice und dem NAS :) D.h. nun kann ich meine MP3 Sammlung dazu nutzen, die ganze Wohnung akustisch zu beschallen. Mein Freundin wird sich freuen :)

Continous Integration - Wenn ein Tool zu sexy ist

Letztes Jahr im Dezember habe ich über den CI (Continous Integration) Server TeamCity 3.0 von JetBrains geschrieben. Nachdem ich den CI Server für ein paar Tests erfolgreich eingesetzt habe, bin ich nun mit dem Projekt Minsight an die Grenzen gestossen. Der Build Server von Minsight läuft mit einem Apache Tomcat 5.x und Teamcity 3.0 kann nur auf Tomcat 6.x fehlerfrei deployed werden. Auf ein grosses Herumgebastel hatte ich keine Lust und machte mich daher auf die Suche nach CI-Alternativen. Bei dieser Suche bin ich auf ein Projekt namens Hudson gestossen, welches viel versprechend aufwartet.

Hudson hat mich sehr schnell durch seine Einfachheit beeindruckt. Man muss das WAR nur auf dem Tomcat oder dergleichen deployen und danach mittels dem Web Browser konfigurieren. Ausserdem verfügt der CI Server auch über ein Plug-in System, welches den CI Server einfach erweitern lässt. Bspw. gibt es ein Groovy Plugin für Hudson, welches einem erlaubt, Groovy Skripte durch Hudson ausführen zu lassen.

Dieser kurze Artikel soll keineswegs Teamcity 3.0 in Frage stellen. Teamcity ist ein sehr reifes und ausgeklügeltes Produkt (und daher sexy), jedoch trifft man in der Praxis nicht immer auf aktuellste Software (Tomcat 6.x) und hat meistens auch keinen Einfluss dies zu ändern. Unser Hudson läuft nun schon ein paar Tage einwandfrei. Ich kann den CI Server daher nur weiterempfehlen.

Grails 1.0.2 wurde veröffentlicht

Pünktlich vor den Osterferien konnte G2One erneut einen Bugfix Release von Grails veröffentlichen. Der Release trägt die Versionsnummer 1.0.2 und beinhaltet hauptsächlich Bugfixes für Themen wie GORM, das Grails Plug-in System und das Autoreloading. Eine komplette Bugfixliste kann man aus den Release Notes entnehmen. Die aktuelle Version von Grails lässt sich auf der Projekthomepage von Grails herunterladen.

Voraussichtlich wird es nochmals einen erneuten Bugfix Release 1.0.3 geben, um danach zügig auf Grails 1.1 fortzuschreiten. Details zum Release 1.1 können aus der Roadmap entnommen werden.

Erstes eigenes Grails Projekt ist online

Vor rund einer Woche konnte ich meine erste Grails Webapplikation erfolgreich im Netz publizieren. Das ganze lässt sich hier besichtigen. Es handelt sich bei der Webapplikation um die Hochzeitsseiten meiner Schwester :)

Ich möchte hier keine grossen Worte verlieren. Eines soll jedoch gesagt werden. Die ganze Sache war grösstenteils trivial, hat Spass gemacht und wird mich zukünftig zum Wiederholungstäter machen. Ein grosses Dankeschön an G2One und die Grails/Groovy Community.

Genf und Zürich im Playoff-Halbfinal

Nach der gestrigen Playoff Viertelfinalrunde konnten sich Genf Servette und die ZSC Lions vorzeitig fürs Playoff Halbfinal qualifizieren. Die Servettiens schlugen die Rapperswil-Jona Lakers und die ZSC Lions konnten gegen die Kloten Flyers auswärts den vierten Sieg gutschreiben lassen.

Überraschen in dieser Runde war der HC Fribourg-Gottéron, welcher den SC Bern erneut in Schwierigenkeiten brachte und in der Nachspielzeit sogar gegen den ersten der Qualifikation den Siegestreffer erzielen konnte. In dieser Serie heisst es neu 3-2 für den Underdog Fribourg-Gottéron :)

Aus Stadt Zürcher Sicht kann der Halbfinalgegner auch jetzt noch nicht bestimmt werden. Schlussendlich ist dies jedoch auch egal. Um den Meistertitel zu gewinnen, muss man sowieso jeden bezwingen, welcher sich einem in den Playoffweg stellt. Bis Samstag kann sich Zürich aber noch einwenig ausruhen und der Sache einwenig gelassen entgegenblicken.

Open CMD here - Aber wo ist die Powershell?

In Windows Vista ist die neue Shell von Microsoft mit dem Namen Powershell enthalten. Seit den Powertoys für Windows XP und nun ebenfalls standardmässig mit Windows Vista gibt es im Kontextmenü des Windows Explorers die Möglichkeit ein Shell-Fenster zu einem angegebenen Pfad zu öffen. Doch wie kann man die neue Powershell aus dem Explorer via Kontextmenü öffnen.

Unter burgaud.com bin ich fündig geworden. Nachfolgende Registryerweiterung bringt mich ans Ziel.

Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\Directory\shell\powershell]
@="PowerShell Here"
[HKEY_CLASSES_ROOT\Directory\shell\powershell\command]
@="C:\\Windows\\system32\\WindowsPowerShell\\v1.0\\powershell.exe -NoExit -Command Set-Location -LiteralPath '%L'"

It's Playoff time

Nun ist es endlich wieder soweit. Die Regular Season der National League ist vorüber und die Playoffs beginnen am kommenden Donnerstag, 28.02.2008.

Die Playoffs bestreiten diese Saison folgende Teams.

• SC Bern (1.) - HC Fribourg-Gottéron (8.)
• HC Genève-Servette (2.) - Rapperswil-Jona (7.)
• Kloten (3.) - ZSC Lions (6.)
• EV Zug (4.) - HC Davos (5.)

Zur "Schaden-"Freunde vieler hat es der HC Lugano dieses Jahr zum ersten Mal seit der Einführung der Playoffs vor 23 Jahren nicht ins Playoff geschafft. Naja, als ZSC Fan ist man sich die Playout Runde auch gewohnt :).

Auf jedenfall freue ich mich bereits auf spannende Derby Partien zwischen den Kloten Flyers und den ZSC Lions.

Grails 1.0 - und wie weiter?

Vor einigen Tagen, genauer am 18. Februar 2008, ist der Bugfix V.1.0.1 veröffentlicht. Dieser beinhaltet diese Fehlerbehebungen. Offensichtlich plant G2One einen weiteren Patch Release, den in ihrem Issue Tracker sind bereits Issues dem Release 1.0.2 zugeteilt.

Nun stellt sich die Frage, wie es mit Grails weitergeht? Was sind Features, welche in zukünftigen Release 1.5.x bzw. 2.x hinzukommen? Auf der Grails Roadmap werden folgende Punkte als zukünftige Features (sogenannte Post Grails 1.0) deklariert.

• Implement support for JPA
• Implement generation of domain model from DB (Middlegen integration)
• Add server-side scripting of client Javascript (javascript DSL)
• Refactor scaffolding to make it more pluggable and extensible
• Implement support for JSP custom tag libraries in GSP
• Fork GSQL and use to add support for database migrations
• Add XML-RPC support for Service classes
• Implement Grails-AOP an AOP mechanism built on the Groovy MOP
• Add scaffolding of user authentication code
• Start to build up a UI component tag library

Gerade die Integration von Middlegen könnte interessant werden, um Grails weiter in der "Enterprise-Welt" voranzutreiben. Nicht alle IT-Projekte (sehr wenige sogar) entstehen als sogenannte "Grüne Wiese Projekte" und daher macht es Sinn auf dieses Reverse-Engineering Tool zurückgreifen zu können.
Auch die Möglichkeit in Service Klassen XML-RPC Funktionalität zur Verfügung gestellt zu bekommen oder auf Basis Groovy MOP aspect-oriented-programming (AOP) in Grails zu nutzen klingt in meinen Ohren sehr attraktiv.

Wann diese tollen Features für jedermann erhältlich sind, konnte ich bisher nicht ermitteln. Auf jedenfall werde ich mich auf diesen Tag freuen und bis dahin weiter ausschau halten (oder allenfalls mal mit commiten *fg*). Die Suche geht also auch nach Version 1.0 weiter.

Nachtrag 27.02.2008: Graeme Rocher hat ein paar Folien zu Thema Grails und über die Zukunft von Grails veröffentlicht. Sie sind sehenswert :)

Grails 1.0 ist da! - The search is over

Das lange Warten hat nun ein Ende. Die finale 1.0 Version von Grails wurde heute von G2One Inc. für die Öffentlichkeit freigegeben. Gleichzeitig zur Veröffentlichung wurde der Grails Homepage auch ein neues Gesicht geschenkt; eines welches es sich im Vergleich zu ähnlichen Software-Vorhaben (z.B. Ruby on Rails) zeigen lässt.

Grails ist ein Framework zum effektiven Erstellen von Web Applikationen. Es bedient sich unter anderen an in der Java-Welt akzeptieren Frameworks wie Spring und Hibernate. Mittels Techniken wie Scaffolding, Coding by Convention, usw. welche von Ruby on Rails entnommen wurden, stellt Grails ein leichtgewichtiges Framework dar, mit welchem Webapplikationsentwicklung zügig voran getrieben werden kann.

Zu den neuen Features gehören unter anderem Unterstützung von REST, JNDI, Content Negotiation und die vereinfachte Definition von Filtern. Weitere Informationen dazu finden sich in den Release Notes.

Nachtrag: Offensichtlich hat sich in der Taglibrary ein Bug eingeschlichen (siehe Jira). Nach Absprache mit der Grails Community habe ich ein Issue eröffnet. Meiner Ansicht nach ist der Bug umgehbar und somit überhaupt nicht kritisch.

Gant 1.1.0 wurde veröffentlicht

Gant ist ein Build-Tool, welches auf dem Java Buildtool Ant aufsetzt. Im Gegensatz zu Ant, welches Buildfiles in XML Dateien abbildet, verwendet Gant Groovy Scripts. Und hier liegt auch der Unterschied und die Mächtigkeit von Gant. In den erwähnten Groovy können sämtliche Möglichkeiten von Groovy (und natürlich auch von Java) ausgeschöpft werden. Mit Ant wird dies innerhalb der XML Dateien einwenig unübersichtlich.

Am 30. Januar 2008 hat der Projektleiter von Gant, Russel Winder, den Release von Gant 1.1.0 bekanntgegeben.

Russel Winder, 30. Januar 2008: "With the release of Groovy 1.5.2, it seemed entirely appropriate to release Gant 1.1.0, so this has been done."

Der Release beinhaltet unter anderem einen Ant Task, welcher es ermöglichen soll mittels dem Ant-Gant Workaround Gant Skripte auch in Continous Integration Server, welche derzeit Gant noch nicht direkt unterstützen, ausführen zu können.

Grails 1.0 - Bald schon da?

Grails Issue Tracker Jira zufolge kann es nicht mehr lange dauern, bis die erste stabile 1.0 Version offiziell zum Download bereit steht. Aktuell beinhaltet der Grails 1.0 RC4 noch 6 offene Issues, welche gelöst werden müssen. Danach wird anhand der letzten 55 Issues auf direktem Weg auf die Version 1.0 hingearbeitet. Der Projektleiter von Grails spricht in seinem Blog davon, dass Grails innerhalb des nächsten Monats (Februar 2008) erscheinen soll.

Umgebungsvariablen in der Windows Registry

Windows verwaltet die Systemumgebungsvariablen unter nachfolgendem Registrypfad.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment

Softwareentwicklung mit Groovy und Gant

Vor kurzem haben Freunde und ich ein Open Source Projekt namens Minsight gestartet, welches mittels Java und Groovy entwickelt wird. Da wir mit Apache Ant bereits gute Erfahrungen gemacht haben, jedoch im Buildprozess mit Groovy arbeiten wollten, haben wir uns entschieden auf Gant zu setzen, welches auf Ant aufsetzt.

Unter diesem Link findet man ein Slideshow zum Thema "Wieso soll Gant verwendet werden?".

Vor ein paar Tagen wollte ich mich daran machen einen Continuous Integration Server aufzusetzen, welcher unser SVN Repository überwacht. Genauer wollte ich TeamCity 3.0 als CI Server verwenden. Als alles schön aufgesetzt war, d.h. als der CI Server funktionierte und bereit war ein Softwareprojekt zu überwachen, ist mir aufgefallen, dass Gant Skripte durch TeamCity 3.0 aktuell nicht unterstützt werden. Ich gebe zu, dass ich keinerlei vorgängige Evaluation durchgeführt habe, ansonsten wäre mir dies wahrscheinlich schon früher aufgefallen wäre :) Anyway. Das hätte in diesem Fall nicht viel gebracht, da keiner der bekannten CI Server Gant direkt unterstützt. Nach meiner Recherche konnte ich auch keinerlei Intention finden, dass sich dies in Kürze ändern würde.

Nach einem kurzem Besuch auf dem Gant Issue Tracker Jira ist mir aufgefallen, dass wir nicht das erste Groovy Softwareprojekt sind, welches in dieses Problem gelaufen ist. Unter Jira Issue Gant-18 hat der Projektleiter von Groovy bereits ein Issue eröffnet, welches nach einem Ant Task verlangt, um eine Art Ant Build Wrapper für ein Gant Skript schreiben zu können.

Zu diesem Zeitpunkt (2. Januar 2008) war das Issue noch nicht in Bearbeitung und daher schrieb ich Russel Winder, dem Projektleiter von Gant, ein Mail und fragte ihn, ob das Issue umgesetzt würde und ob es bereits auf einer Roadmap ersichtlich ist. Offensichtlich hatte Russel im jungen 2008 bereits wieder Tatendrang entwickelt und schrieb mir, dass er aufgrund meiner Anfrage mit der Entwicklung des Ant Tasks begonnen habe *freu*.

Seit dem 4. Januar ist nun auch im aktuellen Snapshot von Gant 1.0.3 der Ant Task zur Verfügung und Russel bat uns diesen mit dem Buildskript von Minsight zu testen. Wie so oft funktioniert neue Software (in diesem Fall die Kollaberation zwischen dem neuen Ant Task und Gant) nicht immer gleich beim ersten Mal. In unserem Gant Skript verwenden wir den ConfigSlurper von Groovy, um auf einfache Weise Java Properties Dateien einzulesen. Offensichtlich verursacht dies ein Problem:

< BUILD FAILED
< C:\minsight\build.xml:12: java.lang.NoClassDefFoundError: groovy/lang/Script

Es scheint als findet Gant die Groovy Libraries (JARs) nicht. Entfernt man den ConfigSlurper funktioniert das Ganze soweit. Offensichtlich gibt es jedoch noch weitere Probleme in diesem Kontext. Russel hat angeboten, das Issue nochmals zu analysieren.

Wir freuen uns auf jedenfalls auf die stabile Gant Version 1.0.3, welche einen Ant Task beinhalten wird, um Gant Buildskripte auch in CI Server ausführen zu können (ohne mit Skriptdaten à la .cmd oder .sh zu arbeiten). All denjenigen, welche Gant verwenden oder es planen in ihrem Softwareprojekt einzusetzen, können wir an dieser Stelle versprechen, dass wir den neuen Ant Task aus der Groovy Gemeinde auf Herz und Nieren im Rahmen unseres Verwendungszwecks testen werden.

Spring 2.x - Dynamic language support

Seit der Version 2.0 unterstützt das Spring Framework dynamische Skriptsprachen wie JRuby, Groovy und BeanShell. Bezüglich JRuby und BeanShell kann ich an dieser Stelle nichts aussagen, da ich die beiden Sprachen nicht genauer kennen. Bezüglich Groovy und Spring hingegen möchte ich ein paar Worte verlieren.

In Groovy hat man die Möglichkeit sogenannte Groovy Skripte anzulegen, welche dann zur Laufzeit als Klasse kompiliert und ausgeführt wird. Diese Skripte ermöglichen gewisse Applikationslogik in Skripte auszulagern und Anpassungen diesen dann ohne erneutes kompilieren (durch den Entwickler oder den Buildrechner à la Continous Integration) durchführen zu können. Über die Nachteile (Einspielen von bösartigem Code, erhöhter Sicherheitsaufwand) dieser Variante möchte ich an dieser Stelle nicht weiter eingehen.

Im nachfolgenden Beispiel sieht man wie man in Spring 2.x (XSD Version, mit der alten DTD Version geht das nicht) ein Groovy Skript als Spring Bean bekannt macht. Mittels dem Attribut refresh-check-delay erhält man die Möglichkeit Spring mitzuteilen, in welchem Zeitinterval es das Groovy Skript auf Veränderungen testen soll. Dieser Mechanismus lässt sich laut Dokumentation auch ausschalten, indem man einen negativen Wert angibt.

<lang:groovy id="messenger" refresh-check-delay="5000"
 script-source="classpath:Messenger.groovy">
  <lang:property name="message" value="I Can Do The Frug" />
</lang:groovy>

Ein weiteres neues Feature ist die Spring inline dynamic language, welches es dem Entwickler ermöglicht direkt in der spring.xml Datei Groovy Code einzubetten.

<lang:groovy id="messenger">
   <lang:inline-script>
    package org.springframework.scripting.groovy;

    import org.springframework.scripting.Messenger

    class GroovyMessenger implements Messenger {

       String message
    }
   </lang:inline-script>
   <lang:property name="message" value="I Can Do The Frug" />
</lang:groovy>

Gemäss den Angaben von SpringSource (ehem. Interface21) kann der Einsatz von dynamischen Skriptsprachen in Zusammenhang mit Spring in nachfolgenden Punkten Sinn machen.

• Scripted Spring MVC Controllers
• Scripted Validators
  

Anmerkung: Die Codebeispiele sind alle aus der Spring Dokumentation (Spring 2.5) übernommen worden.

Debian packages

Debian packages werden wie folgt installiert: dpkg -i package-name.deb

Installierte Debian packages anzeigen: dpkg -l

Mittels grep kann die Ausgabe von dpkg eingeschränkt werden. Sucht man bspw. das Groovy Paket, so kann dies folgendermassen ermittelt werden. dpkg -l | grep groovy.

Mit dpkg -r package-name kann das installierte Paket wieder entfernt werden.

Internationalisierung mit dem Spring Framework

Das Spring Framework bietet einen einfachen Mechanismus um Applikationen zu internationalisieren (I18N) ohne die sprachspezifischen Texte in den Sourcecode einbetten und somit bei Änderungen erneut kompilieren zu müssen. Mittels der Klasse ReloadableResourceBundleMessageSource können die sprachspezifischen Texte in Java Properties Dateien ausgelagert werden. Die Klasse bietet, wie es ihr Namen schon verspricht, das Erkennen von Änderungen, die zur Laufzeit in der Properties Datei gemacht werden, an die Applikation weiterzuleiten.

Als erstes benötigt man die angesprochene Properties Datei, in diesem Beispiel hat sie den Dateinamen meinePropertyDatei.properties und enthält zwei Properties namens login.username und login.password. Diese beiden Properties Einträge dienen bspw. als Textinhalte für Masken, auf welchen ein Login durchgeführt wird.
Nachfolgend sind zwei Properties Dateien abgebildet. Einmal die erwähnte meinePropertyDatei.properties, welche als Basis Datei dient und dann eine Property Datei namen meinePropertyDatei_DE.properties, welche Texte in deutscher Sprache beinhaltet. Wie dieser Postfix im Dateinamen durch Spring behandelt wird, möchte ich zu einem späteren Zeitpunkt in diesem Artikel erklären.

[meinePropertyDatei.properties]

1. login.username=Please enter your username
2. login.password=Please enter your password

[meinePropertyDatei_DE.properties]

1. login.username=Bitte geben Sie Ihren Benutzernamen ein
2. login.password=Bitte geben Sie Ihr Passwort ein

Um die Klasse ReloadableResourceBundleMessageSource in der eigenen Applikation via Spring verwenden zu können, muss diese im ApplicationContext vermerkt werden. Dabei gibt man den Dateinamen der Basis Properties Datei meinePropertyDatei.properties ohne Dateiendung (und ohne Postfix) an.

[spring.xml]

1. <bean id="messageSource"
class="org.springframework.context.support.ReloadableResourceBundleMessageSource">
2.  <property name="basenames">
3.   <list>  
4.    <value>meinePropertyDatei</value>
5.   </list>
6.  </property>
7. </bean>

Damit man nun aus der Applikation auf die Properties Datei bzw. deren Textinhalte zugreifen kann, muss man in der entsprechenden Klasse nur die Interfaceklasse MessageSourceAware implementieren.

[HibernateUserService.java]

1. public class HibernateUserService implements MessageSourceAware {
2.  
3.   private MessageSource messageSource;
4.  
5.   public void setMessageSource(MessageSource messageSource) {
6.        this.messageSource = messageSource;
7.   }
8.
9.   public void printStuff() {
10.        System.out.println("Username Text: "
            + messageSource.getMessage("login.username", null, null));
11.        System.out.println("Password Text: "
            + messageSource.getMessage("login.password", null, null));
12.        System.out.println("Deutscher Benutzername Text: "
            + messageSource.getMessage("login.username", null, Locale.GERMAN));
13.        System.out.println("Deutscher Passwort Text: "
            + messageSource.getMessage("login.password", null, Locale.GERMAN));
14.   }
15.}

Nun muss man die Klasse HibernateUserService nur noch dem Spring Context bekannt machen.

[spring.xml]

1. <bean name="userService" 
  class="ch.minsight.core.java.services.HibernateUserService" />

Wenn man nun das Bean userService via dem Spring Application Context anfordert wird die MessageSource automatisch in die Instanz von HibernateUserService implantiert. Dies nennt man ein sogenanntes 'Autowiring', da Spring automatisch erkennt, dass HibernateUserService eine MessageSource benötigt und somit das Bean mit der ID 'messageSource' übergibt. Wie man aus dem Java Sourcecode entnehmen kann, können die Texte unter Bekanntgabe der jeweiligen Locale, sprachabhängig ausgelesen werden.

Groovy: Update 1.5.1 verfügbar

Am 21. Dezember - pünktlich als Weihnachtsgeschenk - kündigt Guillaume Laforge, der Groovy Projektleiter, die Verfügbarkeit des Bugfix Releases Groovy 1.5.1 an.

The Groovy development team and G2One are pleased to announce the
release of Groovy 1.5.1 -- a bug fix release for Groovy 1.5.

It fixes a few problems that were discovered after the release of Groovy 1.5.0.
In particular: a dead lock in the Groovy classloader, and a problem
with input streams with the Ant builder.
Also, a problem in highly concurrent setups on multi-processor
machines made Groovy run anormally slowly, and this new release also
fixes this problem and makes Groovy run much faster using the full
power of all the CPUs.

Groovy 1.5.1 kann hier heruntergeladen werden. Wie gewohnt kann nebst dem Source Code auch eine vorkompilierte Version, ein inoffizieller Windows Installer oder ein Debian Package heruntergeladen werden.

TeamCity 3.0 - Ein weiteres kostenloses Continous Integration Tool steht zur Verfügung

Praktisch zur gleichen Zeit wie IntelliJ IDEA 7.0 veröffentlich wurde, haben die Entwickler von JetBrains das Continuous Integration Tool TeamCity 3.0 freigegeben. Bisher habe ich jeweils mit CruiseControl(.NET) in Projekten gearbeitet, bin aber seit dem Erwerb von IntelliJ IDEA 7.0 auf TeamCity aufmerksam geworden. Es wird in einer Professional und Enterprise Edition angeboten, wobei die erstere Version kostenlos ist und sich laut JetBrains für kleinere und mittlere Entwicklungsunternehmen eignet. In dieser Version können 20 Softwareprojekte parallel verwaltet werden. Ausserdem können maximal 20 Anwender in TeamCity festgelegt werden. Dies sind aber bereits die einzigen Einschränkungen, welche in der Professional Edition hingenommen werden müssen. Eine Auflistung aller Features von TeamCity findet man hier.

Im direkten Vergleich mit CruiseControl sticht einem die relativ simple und GUI-unterstützte Konfiguration ins Auge, welche ermöglicht, dass sich der Administrator nicht mit einem XML Konfigurationsdokument à la CruiseControl auseinandersetzen muss. Ferner steht für die gängigen IDEs ein Plug-in für TeamCity zur Verfügung, mit welchem man das Continous Integration Tool aus der Entwicklungsumgebung steuern kann.

TeamCity 3.0 ist als Windows Installer, Mac OS X und Linux Setup verfügbar, welches jeweils mit einem integrierten Apache Tomcat mitgeliefert wird. Alternativ steht einem ein Web Application Archive (WAR) für ein Deployment auf einem eigenständigen Application Server.

TeamCity 3.0 macht mir nach ersten kleinen Tests einen sehr ausgereiften Eindruck. Es macht richtiggehend Spass mit TeamCity zu arbeiten, da alles sehr einfach zu konfigurieren ist.

Groovy 1.5 ist erschienen

Seit dem 08.12.2007 Groovy in der Version 1.5 als stabiler Release erhältlich. Einer der grossen Erweiterungen seit 1.0 ist die sogenannte Joint-Compilation von Groovy/Java Source Code. Dies ermöglicht es Groovy Abhängigkeiten in Java Klassen in einem Buildlauf (z.B. mit Ant) zu kompilieren. Weiter können nun auch GroovyTestCases mit JUnit 4.0 arbeiten. Die Release Notes sind wie immer in Jira von Codehaus zu finden.

Aktuell steht noch kein Windows Installer oder Ubuntu / Debian Paket zum Download bereit. Diese sollen aber in den kommenden Tagen nachgeliefert werden.

Offensichtlich scheint es sich bei diesem Release um den wahrscheinlich letzten Groovy 1.x Release zu handeln. Dies vermute ich, da die Releasekandidaten dieses 1.5 Releases allesamt die Versionsnummer 1.1 trugen. Ich vermute daher, dass die kommenden Erweiterungen von Groovy unter 2.x weitergeführt werden.

Nun kann man gespannt sein und darauf warten, dass Grails erstmals in einer stabilen 1.0 Version veröffentlicht wird.