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.

Artikel von: everflux.de

Heuschrecken @ SpringSource: Spring Framework lock-in

Ähnliche Beiträge:

1. Spring Framework: SNAPSHOT Versionen per Maven
2. Spring Framework 2.0.4
3. Gründe gegen Spring Framework
4. SpringSource kauft ein: Groovy und Grails G2One

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>


Artikel von: everflux.de

Spring Framework: SNAPSHOT Versionen per Maven

Ähnliche Beiträge:

1. Heuschrecken @ SpringSource: Spring Framework lock-in
2. Spring Framework 2.0.4
3. Gründe gegen Spring Framework
4. GridGain und Maven

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.

Unter anderem bringt Netbeans 6.5 M1 auch direkte Unterstützung für Eclipse Projekte mit, kann mit Spring Beans  (incl. Refactoring) umgehen, und bringt sogar für PHP Code-Completion und Refactoring Support mit. Unter Linux lief Netbeans 6.5 M1 stabil und konnte problemlos mit Eclipse Projekten arbeiten. Auch der Profiler (der in abgespeckter Form als VisualVM auf der JavaOne promoted und als Teil des Java 6 Update 7 ausgeliefert wird) ist intuitiv bedienbar.

CSS und JavaScript Code-Completion sind ebenfalls an Board, man sollte meinen, Sun möchte es jetzt allen einmal richtig zeigen. Gerade dynamische und nicht-Java Sprachen machen Netbeans zu einer attraktiven Alternative zu IntelliJ oder Eclipse. Auch bei bekannten Stärken von Netbeans, wie dem GUI Builder Matisse gibt es Verbesserungen und Ergänzungen.

Glassfish v3, der bisher als technology Preview verfügbar ist, läßt sich ebenfalls in Netbeans integrieren. Der modulare und schlanke (100kb Kernel) Applikationserver könnte dank Projekten wie Quercus sogar zukünftig eine interessante Plattform für das Deployment von mit Netbeans entwickelten Anwendungen in “fremden” Sprachen darstellen.

Und so hat Netbeans für jeden etwas zu bieten – und vor allem trägt Netbeans dazu bei, dass es viel Auswahl auf dem IDE Markt gibt.

Artikel von: everflux.de

Netbeans 6.5 Milestone 1 PHP, Groovy, Glassfish und mehr

Ähnliche Beiträge:

1. Glassfish 3.1: Probleme mit DWR 2 (und mehr)
2. Netbeans 6.5 kommt: RC1
3. Netbeans 6.5 released
4. GlassFish v3 Prelude: Der neue Glassfish ist da

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.

Artikel von: everflux.de

GWT: Google Web Toolkit wird erwachsen

Ähnliche Beiträge:

1. GWT (Google Web Toolkit) zum Mitreden
2. GWT 2: Google Web Toolkit Entwicklung auf Ubuntu 64bit Linux
3. Symbian (S60, UIQ, MOAP) wird OpenSource
4. EC-Karten PIN: Es wird geklagt