About software development for the enterprise. Focus on Java EE and more general Java platforms.
You'll read a lot about Conferences, Java User Groups, Java EE, Integration, AS7, WildFly, EAP and other technologies that hit my road.

Tuesday, July 22, 2008

Fünf Missverständnisse bei der Webanwendungsentwicklung

12:09 Tuesday, July 22, 2008 Posted by Markus Eisele
Web Application Development. Nichts leichter als dass und doch gibt es wenigstens fünf große Missverständnisse, über die man als Webentwickler stolpern kann. Eran Galperin, seit über 5 Jahren als Web Developer tätig, hat sie jetzt zusammengetragen:

* Objektorientierter Code ist weniger performant als prozeduraler Code.
* Das Backend ist das Wichtigste bei der Entwicklung
* Grafikdesigner sind auch gute Interfacedesigner
* Es gibt eine überlegene Programmiersprache
* XML ist ökonomischer als eine Datenbank

Dabei lässt Eran seine Punkte nicht als bloße Behauptungen im Raum stehen, sondern erklärt jedes Missverständnis anhand eines kurzen Beispiels und zeigt auf, worin der Irrglaube genau besteht.

(Quelle: Jaxenter)

und hier ist das Original

Monday, July 21, 2008

maven goal eclipse:rad und checkstyle

06:36 Monday, July 21, 2008 Posted by Markus Eisele
,
Ich muss gestehen, dass ich länger danach gesucht habe.
Nun bin ich fündig geworden.
Das Maven goal eclipse:rad erzeugt die IBM RAD spezifischen Konfigurationsdateien und macht damit aus einem einfachen eclipse-projekt ein echtes RAD Projekt.
Was fehlt nun noch zum richtigen Enterprise Software Projekt?
Natürlich die Softwarequalität.
Wenn man am maven-eclipse-plugin folgende zusätztliche Einstellungen vornimmt, dann wird direkt beim Build der IDE Konfiguration die entsprechende Checkstyle Einstellung gesetzt:


<plugin>
<groupid>org.apache.maven.plugins</groupid>
<artifactid>maven-eclipse-plugin</artifactid>
<configuration>
<additionalconfig>
<file>
<name>.checkstyle</name>
<url>http://some.place.org/path/to/file</url>
</file>
</additionalconfig>
</configuration>
</plugin>


Nachtrag:
Auf den ersten Blick könnte man meinen, dass es sich bei dem <file> um die checkstyle.xml handelt. Das ist leider nicht wahr.
Tatsächlich handelt es sich um den xml-Schnipsel, den Eclipse in der.checkstyle Datei erwartet. Erst darin befindet sich dann der Pfad zu einer externen oder internen Konfiguration.


<fileset-config file-format-version="1.2.0" simple-config="true">
<local-check-config name="ITP_Checks_for_ACM" location="/path/to/checks.xml" type="external" description="">
<additional-data name="protect-config-file" value="false"/>
</local-check-config>
<fileset name="Alle" enabled="true" check-config-name="ITP_Checks_for_ACM" local="true">
<file-match-pattern match-pattern="." include-pattern="true"/>
</fileset>
</fileset-config>

Maven Repository Manager Nexus

06:30 Monday, July 21, 2008 Posted by Markus Eisele
,
Kaum gibt es mal wieder ein verregnetes Wochenende, kann man sich auf die Suche nach Dingen begeben, die man schon immer haben wollte.
Und wie üblich, wird man im Netz fündig. Hab ich im letzten Post noch den Codebaus Maven Proxy als zentrales Repository empfohlen, kann ich heute mit einem neuen Fund aufwarten.
Der Nexus Repository Manager (http://nexus.sonatype.org/).
Ein schickes Stück Software.
Wer es bunt mag, mit einer komfortablen Oberfläche, der sollte einen Blick darauf werfen. Ich hab mich ürigens entschieden, bei dem Codehaus Proxy zu bleiben.
Gründe:
- Er ist offensichtlich schlanker
- Hat weniger Konfigurationsmöglichkeiten (damit auch weniger Fehlerquellen)
- Man kann ihm leichter Dinge "unterschieben" ;)


Nexus is a powerful and robust Maven repository manager, created to provide reliable access to artifacts required for development and provisioning. Maven's central repository has always served as a great convenience for users of Maven, but it has always been recommended to maintain your own repositories to ensure stability within your organization. Nexus greatly simplifies the maintenance of your own internal repositories and access to external repositories. With Nexus you can completely control access to, and deployment of, every artifact in your organization from a single location.

Saturday, July 19, 2008

Maven Best Practices

08:06 Saturday, July 19, 2008 Posted by Markus Eisele
,
Den Einsazt von maven als Experiment zu bezeichnen ist warscheinlich schlicht zu gewagt. Dafür existiert es schon zu lange und wird in vielen Projekten erfolgreich verwendet. In Summe ist es ein wirklich netter Ansatz um modulorientiert Software zu entwicklen und zu builden. Alles in Allem finde ich es nach den ersten Wochen des wirklich harten Projekteinsatzes durchaus charmant.

Ein paar Punkte fallen allerdings immer wieder unangenehm auf. Aus ihnen kann man schnell und einfach ein paar best practices ableiten:


  • Keine Snapshot builds.

    Maven gibt nicht umsonst eine Warnung aus. Wenn es sich gar nicht vermeiden läßt, dann sollte man auf alle Fälle einen halbwegs getesteten Snapshot verwenden und den manuell im Repository bereitstellen.

  • Grosse Teams brauchen einen Proxy.

    Je größer das Entwicklungsteam ist, desto eher sollte man über einen maven proxy nachdenken. Eine stabile und brauchbare Lösung kommt von Codehaus (http://maven-proxy.codehaus.org/). Nett ist, dass man diesen sowohl standalone als auch als WAR auf nahezu jedem beliebigen Appserver betreiben kann.

  • Modulabhängigkeiten sind böse.

    Modulabhängigkeiten mit maven machen einfach keinen Spass. Vor allem dann nicht, wenn man aus maven heraus mit bspw. eclipse:eclipse auch die Entwicklungsumgebung und ihre Abhänigkeiten definiert. Bei jeder Änderung eines Moduls sind potentiell andere Module betroffen. Für das Neuanlegen/Updaten der Entwicklungsumgebungen geht ganz schön viel Zeit drauf. Allein das sollte Grund genug sein, die maven Module entlang den Softwarekomponenten zu schneiden. Damit macht man den Entwicklern auch das (ungewollte) Verweben der Komponenten schon beim Build sehr unangenehm. Es ist damit quasi ein pre-build-dependency check :)

  • Maven ist nicht ant.

    Wer lange Jahre mit ant seine Projekte gebaut hat, der kommt mit maven erfahrungsgemäß nicht sofort klar. Die Dokumentation von maven ist sehr verstreut und die tatsächlichen Fähigkeiten muss man sich doch in der Praxis erarbeiten. Es empfiehlt sich, dass im Projekt ein Verantwortlicher mit maven Erfahrung regelmäßig überprüft, ob und wie man was besser machen kann.
    Darüber hinaus gibt es Dinge, die man mit maven einfach nicht machen kann. So kann man pro Modul bspw. nur ein Artefakt (*.jar, *.war, etc.) erzeugen. Benötigt man mehr, dann muss man tatsächlich auf ant zurückgreifen

  • Maven und Opensource lieben sich.

    Abseits von Opensource Entwicklungsumgebungen wird der Einsatz von maven schnell unbequem. Setzt man beispielsweise auf WebSphere, Bea und Co, dann fehlen einem die gewohnt kompfortablen ant Targets zur Erstellung von Deployment Descriptoren und Ähnliches. Auch wenn es für den RAD schon ein goal im maven gibt. Hier muss man tatsächlich noch ein wenig investieren, damit auch auf weniger quelloffenen Umgebungen eine nahtlose Integration möglich ist.



Soviel für Heute. Mehr in den kommenden Woche, wenn Zeit bleibt.