everflux

Spring Framework – damals revolutionäre Konzepte, weg von „bloated enterprise committee driven“, „lightweight“ war angesagt. Spring setzte sich rasend schnell durch, die Macher verdienten mit Consulting, Training und Büchern.

Die „Community“ verhalf Spring zum Erfolg – Menschen, die in neuen Projekten den Mut aufbrachten auf Spring zu setzten. Entwickler, wie ich, die Bücher kauften, Bugs meldeten, testeten und Marketing betrieben.

SpringSource wurde geboren – Venture Capital floß. Nach der Enterprise Application Platform und JavaOne T-Shirts die furchtbar die Wäsche verfärben kommt jetzt der absolute Knüller: Wer nicht zahlt erlebt ein Debian revival: Veraltete Version benutzen oder „unstable“ fahren. Wobei Debian wenigstens Security Fixes noch in den antiken Versionen bereitstellt.

Wer zahlt, der bekommt eine stabile Version – jedoch unter einer Lizenz, die es nicht erlaubt diese Version weiterzugeben. Ich weiß nur, dass ich nach dem Theater mit der ext-js Lizenz ganz schnell bei jquery war, und sicher da bleiben werde. Bleibt abzuwarten, wie es mit Spring weiter geht.

Einen Blick auf Google Guice und pico container habe ich bereits geworfen – doch Spring ist mehr. Vendor lockin auf allen Ebenen, das tut weh.

• Rod Johnson Interview auf dzone
• Stefan Reuter zu den Lizenzänderungen beim Spring Framework
• SpringSource Licensing FAQ
• Analyse: Wie sehr ist Spring eigentlich „OpenSource“
• Diskussions Thread bei TheServerSide

Rod Johnson hat sicherlich Recht, dass SpringSource „über 100 OpenSource Releases pro Jahr“ machte, aber wie wird die Zukunft aussehen? Sicher, Bandbreite für Dokumentation, Maven Repo, Amazon S3, das kostet alles Geld – jedoch zumindest für diejenigen, die selber Spring kompilieren, könnte ein SVN Tag bereitstehen. Ich bin gespannt, wann jemand svn revision Nummern zu enterprise releases als Mapping zur Verfügung stellt.

Das könnte auch SpringSource helfen – zumindest wenn gewünscht ist, dass die Community weiterhin BugReports einreicht, und das nicht nur noch enterprise Kunden per Support Ticket sollen/dürfen: Doppelte Bugreports und Reports zu längst gefixten Problemen dürften die Regel statt die Ausnahme werden. Oder eben man schaltet bei „Community“ komplett auf taub.

Update:
Wie Rod Johnson im SpringSource Team Blog erläutert, hat SpringSource dank des umfangreichen Community-Feedback Änderungen an den Änderungen vor. Grob gesagt: Spezielle Preise für kleine Unternehmen und ständige Verfügbarkeit von Releases aus dem aktuellen Zweig.

Damit kann man gut leben – Unternehmen, die gerne ältere Versionen gepflegt haben möchten, haben auch die Ressourcen das zu finanzieren.

Das Spring Framework, gerade besonders (un)populär aufgrund von Lizenzänderungen des Herstellers SpringSource, ist für viele Java Enterprise Anwendungen Infrastrukturgrundlage.

Sei es für Dependency Injection, AOP, JDBC Templates oder Vereinfachung von Remoting – die Spring API macht nach erster Eingewöhnung die Arbeit wesentlich einfacher und vereinheitlicht die Nutzung verschiedener Technologien. Doch was, wenn man eine Snapshot Version verwenden möchte? Netterweise gibt es neben „selbst gebaut“ noch die Alternative eines bei Amazon S3 gehosteten Snapshot Repositories für Maven, wie man aus dem SpringSource Blog erfährt.

Das ganze funktioniert so, Maven Repositories um einen Eintrag ergänzen, Spring Version auf x.y.z-SNAPSHOT (z.B. 2.5.6-SNAPSHOT) setzen und den Rest erledigt Maven. Danke SpringSource, danke Maven!

So sieht der SpringFramework Snapshot Repository Eintrag im Maven dann aus:

<repository>
<id>spring-snapshot</id>
<name>Spring Portfolio Snapshot Repository</name>
<url>http://s3.amazonaws.com/maven.springframework.org/snapshot</url>
</repository>


Netbeans 6.5 Milestone build 1 ist verfügbar (www.netbeans.org). Die Liste der neuen Features und Updates macht wirklich neugierig!

Unter anderem hat Netbeans verbesserten JavaScript Support (incl. JavaScript Debugger), Groovy und Grails werden von Haus aus unterstützt, und auch PHP ist jetzt direkt mit von der Partie. Weiterlesen »

Das Google Web Toolkit wird erwachsen – das behauptet Google zwar nicht selber, doch das Umfeld spricht eine deutliche Sprache. GWT 1.5 wird endlich – lang ersehnt – Java 5 und damit auch die Generics von Java 5 unterstützen. Auch wenn noch keine fertige 1.5 Version von GWT vorliegt, so arbeiten bei Google eifrig die Entwickler an dem OpenSource Projekt.

Während von GWT 1.5 inzwischen Milestone 2 verfügbar ist, wächst auch das Ökosystem rund um das Google Web Toolkit:

GQuery ist eine typsichere Umsetzung von jQuery für GWT – wer jQuery kennengelernt hat, wird es sicherlich auf Anhieb lieben.

GWT-SL, die Google Webtoolkit Server Library zielt auf Spring Framework Integration ab: Spring Beans können als RPC Dienste exportiert werden, und macht so die Integration in bestehende Entwicklungs-Stacks oder auch Applikationen einfacher.

Hibernate4GWT schließlich rundet das ganze ab: Hibernate persistierte Objekte (und lazy collections) können ohne Verrenkungen mit GWT verwendet werden. Mit GWT 1.5 und Java Generics wird das sicherlich noch ein großes Stück angenehmer.