Demnächst ist es soweit. Das Release 0.6 des JBoss Development Deployers kommt im Mai. Das größte Feature ist das EAR-Deployment. In der EAR-Datei können die Pfad zur Entwicklungsumgebung angegeben werden und damit sind Redeployments oder schwierige JSP-Bearbeitungen im Temp-Verzeichniss des JBoss Vergangenheit. Derzeit befindet sich das Projekt noch in der Testphase, aber es hat zahlreiche Tests mit EJB, WAR (mit unteranderem JSF-Komponenten) und weiteren Modulen bestanden.

Der JBoss Development Deployer ist unter http://jb-dev-deploy.sourceforge.net/ verfügbar.

Entwickler in Multi-Modul-Projekten haben viele Aufgaben. Während der Entwicklung wirkt sich besonders das Deployment/Re-Deployment einer Anwendung negativ auf die Effizienz aus. Es gibt zwar kostenpflichtige Tools (z. B. JRebel), die Abhilfe schaffen, jedoch noch kein Open Source Tool.

Dies habe ich zum Anlass genommen und einen Development Deployer für JBoss AS entwickelt. Mit diesem Deployer können J2EE Multi-Modul-Projekte während der Entwicklung in der IDE bleiben, das lästige JAR's bauen/deployen entfällt. So können beispielsweise in einer Web-Anwendung (WAR-Deployment) mehrere Klassenpfade (z. B. classes- und/oder lib-Verzeichnisse) konfiguriert werden.

Das Projekt wird bei SourceForge gehostet und ist unter http://jb-dev-deploy.sourceforge.net/ erreichbar.

Derzeit wird ein Web-Deployment (WAR) unterstützt (getestet mit BouncyCastle/JSF-Komponenten). Geplant ist die komplette Unterstützung von J2EE Projekten (EAR/SAR/HAR).

Ich freue mich auf Feedback.

Eine häufige Aussage von Anwendern ist: Schon wieder ist alles langsamer geworden. Oftmals nach neuen Releases, bei denen viele neue Features hinzugefügt und bestehende Funktionen erweitert wurden.

In nahezu allen Enterprise-Projekten sind Zugriffe auf Datenbestände in Datenbanken erforderlich. Manchmal direkt über JDBC oder, in den besser organisierten Projekten, über objektrelationale Mapper wie JPA, Hibernate oder ähnliche.

EMF kann aus einem Modell Java-Code erzeugen. Das so erzeugte Java-Programm kann Instanzen dieses Modells erstellen, abfragen, manipulieren, serialisieren (eingebaut als XMI oder anderes XML, mit Plugin auch in einer relationalen DB), validieren und auf Änderungen überwachen (für MVC). Darüber hinaus wird JUnit-Code erzeugt, der den generierten Code testet.

Seit dem 25.06.2010 ist es soweit: Mein Artikel Code-Recycling: Refaktorisierung einer Alt-Anwendung in der Praxis (Refactoring) wurde in der OBJEKTSpektrum veröffentlicht. Ich bin auf Feedback gespannt und freue mich über andere Erfahrungsberichte mit Refactoring.

Wenn ich heute jemanden Frage, was er in der letzten Zeit so gemacht hat, so antworten über 90 % "Ein Projekt im Bereich ...". Dabei sind dies bei weitem nicht alles Projekte im IT Bereich. Ja die Projektarbeit dringt in immer weitere Bereiche von Unternehmen vor. So stellt sich mir immer wieder die Frage: Wann ist ein Projekt erfolgreich, wann ist es fehlgeschlagen?

Bei SOA stellt sich nur noch diese Frage. Aber eine Service-Architektur erfordert nicht gleich ein Enterprise Backend.

Es gibt viele Ansätze und Möglichkeiten, einzelne Dienste zu veröffentlichen, zu benutzen und diese auch zu realisieren. Ich möchte einen kurzen Überblick darüber schaffen, welche Erfahrungen ich gemacht habe - Eine Enterprise Anwendung mit JEE Bordmitteln jenseits von OSGi.

Viele Entwickler, denen ihre Software wichtig ist, haben eine Idealvorstellung vom Prozess der Entwicklung.

Was kann man mit dem Eclipse Modeling Framework so anstellen?. Nun, zum Beispiel statt das Modell in XML zu serialisieren, können die Daten auch in einer Datenbank abgespeichert werden.