Introduction to m2eclipse

Eine Einführung in die Benutzung von m2eclipse ist seit ein paar Tagen auf theserverside.com zu finden.

Sehr lesenswert!

maven goal eclipse:rad und checkstyle

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

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.

Maven Best Practices

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.

ant oder maven oder wie man schnell und einfach ..

... Java Projekte kompliziert machen kann.
Ok. Ich geb es ja zu: Auch ich bin nicht immer auf der Höhe der Zeit, was die aktuellsten Hype-Tools oder Open Source Trends angeht. Einen hab ich bisher sicherlich verschlafen. Maven.
Auf mehr oder minder elegante Art und Weise wurde ich jetzt dann mit der Nase draufgedrückt. Frei nach dem Motto: Das Wasser ist blau und tief: Schwimm!
Mit ein paar Jahren Build und Ant Erfahrung bringt einen sowas nicht mehr um den Nachtschlaf und daher bin ich frohen Mutes drangegangen. Und ich muss gestehen, ich hatte es mir einfacher vorgestellt. Selten hab ich ein Werkzeug in der Hand gehabt, was derart eigenwillig war *g*
Mal kurz zum positiven: Das Modulkonzept und die Definition von Abhängigkeiten treibt einem vor lauter Freude das Wasser in die Augen. Einfach klasse. Damit kann man, wenn man es nicht ganz verbockt sich eine Menge Refactoring sparen. Man verlagert die Aufwände einfach in den Build und definiert sein Projekt sauber. Klasse!
Auch das automatische Herunterladen von abhängigen Open Source Bibliotheken ist einfach klasse. Aber dann geht es los: Der Kampf mit den Projektanforderungen.
- Wie sieht eine elegante Integration in Eclipse aus?
- Welche Bibliotheken gibt es in welchen Repositories und warum?
- Wie strukturiert man poms und super-poms?
- Welche Repositories braucht man neben maven 1 und 2 noch?
- Wann steigt mir die Netzwerktruppe auf den Hals, wenn ich mit 40 Entwicklern den ganzen Tag Bibliotheken aus dem Netz ziehe?
- Warum brauche ich wofür einen Maven Proxy?
- Was für Plugins gibt es?
- Warum brauche ich immer noch Ant?
- Soll Ant Maven oder Maven Ant aufrufen?
- Wann wird welche Einstellung von wo vererbt?
- Wieso gibt es keine brauchbare Visulaisierung von Abhängigkeiten?

Fragen über Fragen. Mal sehen, ob ich demnächst noch ein paar Antworten schreiben kann :)