Fundiertes Git Know How als Artikel

Alex Blewitt hat einen sehr interessanten GIT Artikel veröffentlicht, dieser findet sich hier:

http://alblue.blogspot.com/2010/02/git-for-eclipse-users.html

Die Artikel von Alex sind es immer wert, gelesen zu werden, viel Spass damit!

Ein wenig bunter, das GIT leben

Ein Tipp den mir ein Kollege kürzlich gemailt hat (danke Ruby!!) ist folgender:
git config –global alias.lg “log –graph –pretty=format:’%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr)%Creset’ –abbrev-commit –date=relative”

und dann mal git lg eingeben:
übrigens, für Leute die viel mit Subversion arbeiten könnte folgender alias auch interessant sein:
git config –global alias.status “st”:)

Remote Repositories mit GIT einrichten

Da ich mich beruflich aktuell sehr intensiv mit der Verwendung von GIT beschäftige, möchte ich hier (nicht zuletzt für mich selbst) einige Informationen bereitstellen.

Das hier soll keine allgemeine Einführung in GIT werden, sondern hier möchte ich gerne einige Best-Practices dokumentieren, und den Artikel Schritt für Schritt um interessante Informationen erweitern.

Remote Repositories einrichten

Zunächst möchte in demonstrieren, wie man ein Remote Repository mit GIT einrichten kann. Ich verwende hierzu einen Rechner im lokalen Netzwerk (192.168.178.1).

Das Repository richte ich ein im Verzeichnis : /home/user/development/git/repo mit git init –bare (durch das Bare wird die ganze “Noise” aus dem Repository ferngehalten, das ist also kein Repo mehr, mit dem man arbeiten kann, sondern hier liegen nur die “rohen” Git Informationen.)

Der einfachste Weg, auf ein solches Repository zuzugreifen ist über SSH (das git-protokoll soll hierfür zwar besser sein, aber praxisrelevanter ist aus meiner Sicht SSH).

Die Adresse, mit der auf das REPO zugegriffen wird wäre dann:

ssh://user@192.168.178.1/home/user/development/git/repo

Ok, zunächst pushen wir was ins REPO, damit wir was zum auschecken haben (leere Repos auschecken funktioniert nicht).

git remote add origin ssh://user@192.168.178.1/home/user/development/git/repo
(hiermit legen wir einen Namen für das Repo fest, damit wir nicht immer die URL eingeben müssen)

mkdir ~/tmp
cd ~/tmp
git init // initialisiert ein leeres git repo
echo “hallo welt” >> file //irgendwelchen content anlegen
git add . //content stagen
git commit -m “Intitial Commit”

Ok, jetzt haben wir ein funktionierendes Repo mit Content, jetzt pushen wir auf den Server

git push origin master:master

Damit liegt der Content auf dem “Server”. Die Syntax ist hierbei folgende:

git push origin (also wohin gepusht wird) master (von welchem branch gepusht wird) : master (auf welchen branch in Remote gepusht wird)

Hier kann auch ein komplett neuer Remote-Branch angelegt werden, indem master:neuerBranchName verwendet wird.

Zum Testen holen wir uns gleich mal den Content in ein anderes lokales Repository.

mkdir ~/home/tmp2
cd ~/home/tmp2
git init
git clone ssh://user@192.168.178.1/home/user/development/git/repo

Auschecken von Remote Branches

git clone ssh://user@192.168.178.1/home/user/development/git/repo

Damit checken wir den aktuellen HEAD aus (also quasi den Branch, auf dem das Remote Repository aktuell steht).
Alle Branches im Remote REpository kann man sich mit git branch -r anschauen.
origin/HEAD -> origin/master
origin/master
origin/testbranch1
origin/testbranch2

Wichtig, clone checkt wirklich das komplette Repository inklusive aller Branches aus, wir können aber nicht direkt auf den Branches arbeiten. Will man im obigen Beispiel auf dem Branch origin/testbranch1 arbeiten, so muss man diesen erst in einen Remote-Tracking-Branch auschecken mit

git checkout -b testbranch1 origin/testbranch1

Hat man jetzt mit git clone ein Repository gecloned, dann werden alle Branches getrackt. Ein Update für alle Branches bekommen wir mit einem einfachen git fetch. (Git weiß, welche Branches für welche Remote Repositories getracked werden, indem es die entsprechenden Repos in .git/config unter dem Remote-Namen speichert.)

Eine Frage die mir immer noch nich ganz klar ist, ist wie man jetzt seine lokalen GIT-Branches mit dem Master in sync hält (der Master ist immer auf den SVN-Trunk gerebased), nimmt man jetzt merge, pull, rebase? funktionieren tut alles, aber was ist der richtige weg? Für Tipps hierfür wäre ich dankbar.

Für die allgemeinen Informationen nachfolgend einige interessante Links:

http://git.or.cz/course/svn.html
http://flavio.castelli.name/howto_use_git_with_svn
http://progit.org/book/ch8-1.html

http://blog.tsunanet.net/2007/07/learning-git-svn-in-5min.html
http://git.or.cz/gitwiki/GitFaqhttp://stackoverflow.com/questions/747075/how-to-git-svn-clone-the-last-n-revisions-from-a-subversion-repository
http://www.kernel.org/pub/software/scm/git/docs/git-branch.html
http://toolmantim.com/articles/setting_up_a_new_remote_git_repository
(sehr gut!!!) http://www.kernel.org/pub/software/scm/git/docs/user-manual.html
http://wiki.sourcemage.org/Git_Guide
http://www.vilain.net/talks/git-svn/intro.html#howto-fetch

Frohes neues Jahr 2010

Ich wünsche allen ein Frohes Neues Jahr 2010.
Ich bin gespannt, was uns im neuen Jahr alles erwartet.
Vor allen Dingen bin ich gespannt auf E4, hiervon erwarte ich mir einiges.
Weiterhin habe ich vor, mich intensiv mit dem Thema Wicket auseinanderzusetzen.

Ansonsten hoffe ich, dass das neue Jahr genauso erfoglreich und spannend wird wie das noch aktuelle Jahr 2009.

W-JAX am 12.11.

Auch am 12.11. durfte ich noch einen Tag an der W-JAX in München verbringen. Der Tag war recht angenehm, wenn auch einige des Sessions nicht das gehalten haben, was ich mir davon versprochen habe.

Session 1 : JSON in the real World

Die erste Session des Tages wurde bereits um 08:30 von Scott Davis (Groovy Veteran) gehalten mit dem Titel “JSON in the Real World”. Ich kannte zwar JSON, habe aber bisher nie damit gearbeitet und dachte mir deshalb, “in the Real World?” – Kann nicht schaden. Scott ist ein begnadeter Speaker und es macht richtig Spass ihm zuzuhören (vor allem weil er gerne ab und an einige Jokes einbaut, die echt recht amüsant sind).

Zunächst mal JSON (Javascript Object Notation) ist nichts weiter, als eine Möglichkeit, Javascript Objekte sinnvoll als Objekt-Strukturen zu speichern (das ganze ist prinzipiell nicht mehr als eine Map). “Erfunden” bzw. eingeführt wurde das ganze massgeblich von Douglan Crockford.

Aussehen tut das Ganze prinzipiell so:

var blogEntry = {
Blog: “Splitshade”,
Host: “WordPress”,
Topic: “Json”,
Location: “W-JAX”
}

var blogEntryArr = [blogEntry,blogEntry,blogEntry]

Scott hat in seinem Vortrag versucht, anhand eines konkreten Beispiels den Einsatz von JSON und dessen Vorteile gegenüber beispielsweise Javascript herauszuarbeiten. Scott hat den Webservice “Boss@yahoo” verwendet, der es erlaubt, programmatisch die Suchfunktion anzusprechen und als Ergebnis u.a. auch JSON liefern kann.

Scott hat hierbei auch auf die XSS-Problematik hingewiesen, die sich durch die SOP (Single Origin Policy) von Javascript ergibt. Prinzpiiell heisst das, wir können von jedem beliebigen entfernten Server Javascript (und somit auch JSON) laden, aber eben nur einmal, mehrmals geht das nicht. Hier gibt es nun mehrere Möglichkeiten, wie man das Problem umgehen kann (“Sign your Javascript”, Proxy auf unserem eigenen Server oder einen Hack (man gibt direkt eine lokale Javascript-Methode als Callback an, die als Ergebnis mit rausgerendert wird. Anhand von obigem Beispiel wäre das, wenn die CallbackMethode render() heissen würde folgender Rückgabewert: “render(blogEntryArr)” statt nur “blogEntryArr”. D.h. die Funktion wird direkt aufgerufen, das wird beispielsweise auch bei GoogleMaps gemacht.

Zu guter Letzt hat Scott noch auf sein kommendes Buch hingewiesen (Getting Started with Grails , kostenlos!!).

Bean Validation

Im zweiten Vortrag ging es um das Thema “Bean Validation” und den JSR 299. Gehalten wurde der Vortrag von Emmanuel Bernard (JBoss) und gleichzeitig Spec Lead für die Implementierung.

Die Referenzimplementierung für Bean Validation ist Hibernate Validator 4.03.

Prinzipiell gestatt die BeanValidation-API, ValidationConstraints als Annotations zu deklarieren und auf allen Schichten einer EnterpriseAnwendung einzusetzen, d.h. sowohl im Frontend, als auch im Middletier und sogar im Backend und der Datenbank können die Regeln geprüft werden und zwar normalerweise automatisch.

Die API definiert schon eine ganze Menge Constraints (@NotNull, @MaxLength etc.) und kann sehr einfach erweitert werden, indem beispielsweise CompositeConstraints aus den vorhandenen zusammengebaut werden. Zusätzlich bietet die API eine sehr weitreichende Integration in die JEE-Welt (beispielsweise die Integration in JSF 2.0 geht ad-hoc ohne eine Konfiguration). Emmanuel hat hier gezeigt, das die Constraints auf den ManagedBeans angegeben werden und automatisch beim Zugriff durch einen JSF-PropertyResolver ausgewertet werden. Coole Sache.

Weiterhin können die definierten Constraints automatisiert an ein Javascript-Frontend durchgereicht werden oder auch automatisiert in ein Datenbankschema gespielt werden. Find ich persönlich jetzt nicht sooo wichtig, aber das das so einfach geht ist schon erstaunlich. Nachteil ist auf jedenfall, das man die Anwendung der Regeln nicht so einfach auf eine Schicht begrenzen kann.

Insgesamt lohnt sich der Blick darauf wohl, ich werde mir das in nächster Zeit auf jedenfall mal reinziehen.

Keynote Cloud Computing

Puh, was soll ich dazu sagen, sehr theoretisch und langweilig, ich habe beinahe die ganze Note damit verbracht, eine kleine Ajax-Anwendung zu basteln, damit ich ein wenig mit JSON rumspielen konnte;-).

Keynote Scala

Interessanter Vortrag, in dem Martin Odelsky (Scala Mitbegründer) sich zu den nächsten 5 Jahren in Scala äusserte. Wenig technisch, aber durchaus interessant anzusehn. Ich persönlich habe bislang relativ wenig bis keine Erfahrung in Scala und ich persönlich find auch, das sich der Code nicht besondern einfach liest, aber evtl. kommt das ja mit der Zeit, ich habe mir auf jedenfall vorgenommen, hier durchaus mal einen Blick zu wagen.

OSGI Best practices

Vortrag von Martin Lippert und Matthias Lübken.  War recht amüsant, doch leider wenig technisch und ging nicht wirklich ins Detail, mich hätten einige Praxistipps noch interessiert.

Die Folien des Vortrags kann man sich hier anschauen.

GUI Security

In diesem Vortrag von Michael Wiesner ging es prinzipiell darum, wie Security schon in der GUI realisiert werden kann.
Diese Frage hat durchaus ihre Berechtigung (Beispiel war, das in heutiger Software eigentlich Security nur dadurch realisiert ist, das ein Button zwar vorhanden ist und angezeigt wird, aber erst beim Drücken wirkliche SecurityContsraints im Backend abgefangen werden).

Folgende Tipps hatte “Mike” für uns:

1. Berechtigungskonzept am Client – hier sollte nicht mit Rollen sondern vielmehr mit Rechten gearbeitet werden
2. Die Constraints sollten direkt ins Domänenmodell mit Hilfe von AspectJ eingewoben werden

Insgesamt interessanter Vortrag, wenn auch die Ansätze für die PRaxis nicht besonders relevant sein dürften.

Das wars von mir von der W-JAX, mehr als zwei Tage “durfte” ich leider nicht. Ich hoffe, alle Beteiligten hatten ebensoviel Spass wie ich.

 

W-JAX am Dienstag 10.11.

Resumée W-JAX vom 10.11

Da dies mein erster Besuch auf der W-JAX war, war ich natürlich ordentlich gespannt, wie die einzelnen Sessions wohl ablaufen werden.

Eröffnet wurde der Tag mit einer Keynote von Ted Newark, der etwas provokative Titel „Why the next five years will be about languages“ liess schon einiges Versprechen.

Ich sage mal, ich habe selten einen so kompetenten Speaker wie Ted erlebt, mit Wortwitz und Eloquenz konnte er mich durchaus überzeugen.

Idee hinter der Keynote war hauptsächlich, herauszuarbeiten wieso das Thema Languages die letzten paar Jahre (Jahrzehnte?) nicht wirklich relevant für das tägliche Business war.

Die Essenz der Aussage von Ted hierauf war, das Sprachen typischerweise im akademischen Bereich entwickelt werden. Der Fokus einer akademischen Arbeit ist üblicherweise aber der, einer „akademisches“ Problem zu lösen. Ist dieses akademische Problem gelöst, verliert sich das Interesse an der Weiterentwicklung dieser Sprache in den meisten Fällen leider sehr schnell.

Versuchte man also früher, als Entwickler eine „neue“ Sprache zu verwenden, stiess man sehr schnell an die Problematik, dass die Funktionalität einer Sprache über diese spezifische Problemstellung hinaus dürftig, wenn überhaupt vorhanden war (humoristisches, leicht übertriebenes Beispiel von Ted war die Frage, wie greife ich in einer hypotetischen Sprache auf eine relationale Datenbank zu? Die Antwort hierauf, „Relational Databases? I never heard of this new Thing??“. Es herrscht wohl die Meinung vor, dass Sprachen üblicherweise von Professoren entwickelt werden, die mindestens ein Jahrzehnt nicht mehr draussen in Projekten waren;-).

Heute scheint es möglich zu sein, seine eigene „einfache“ Sprache innerhalb von einem Tag zu entwickeln, und zwar nicht von Akademikern, sondern vom Standardentwickler wie auch ich einer bin. Eingie Beispiele zu neuen Sprachen, die natürlich zur Sprache kamen waren Groovy, Ruby, Scala etc. Insgesamt stimmte die Keynote auf einen erfolgreichen Tag ein.

Die zweite Session die ich besucht habe war geleitet von … Hierbei ging es darum, die Neuigkeiten in JEE6 gegenüber JEE5 und sogar J2ee herauszuarbeiten. Der Vortragsstil des Referenten ist als durchaus „nüchtern“ zu beschreiben, da wünsche ich mir doch ein wenig mehr Enthusiasmus, nichts desto trotz war es für mich interessant, mal zu hören, was denn alles so zu kommen scheint. (Ich habe in meiner täglichen Arbeit eher weniger mit EJBs etc.. zu tun, deswegen muss ich leider eingestehen dass ich hier nicht mehr so ganz auf dem laufenden bin).

Der Referent berichtete aus seinem täglichen Projektgeschäft und speziell von einem Projekt zur Erstellung eines FTS ( Führerlosen Transportsystems auf Basis von EJB und Java, als Frontend kam ein Swing Client zum Einsatz).

Meiner Ansicht nach interessante Änderungen die mit EJB 3.1 komme sind:

1. @Singleton-Annotation : hierbei bietet die Spec die Möglichkeit, eine EJB wirklich nur einmal (pro JVM) zur Verfügung zu stellen. Könnte sich durchaus eigenen, um Applicationsettings einmalig global zu setzen. Hieraus ergeben sich natürlich recht interessante Multithreadingproblematiken, was ist zum Beispiel, wenn mehrere Clients gleichzeit auf die Singleton Instanz zugreifen? Hier bietet die Spec einigre interessante Annotations, mit denen das Locking geregelt werden kann (@Lock(READ oder WRITE) oder @AccessTimeout.
2. Endlich, standardisierte JNDI-Namen für EJBs , und zwar Herstellerunabhängig nach dem Pattern java:global/<app>/<module>/beanImpl:Interface, keine Ahnung wieso das nicht schon früher kam.
3. Timerservice (@Timeout, @Schedule etc., müsste man sich mal im Detail anschauen)
4. @Asynchronous, wir haben jetzt die Möglichkeit, eine Session-Bean-Methode asynchron auszuführen, d.h. Die Methode kehrt sofort zurück und liefert bei Bedarf ein Future (JDK 1.5), mit dem das Ergebnis abgefragt werden kann.
5. Die Möglichkeit, einen EJBContainer lokal programmatisch durchzustarten (für beispielsweise UnitTests : EJBContainer.createEJBContainer(), über diesen bekommt man beispielsweise einen Context, mit dem alle EJBs abgefragt werden können). Extrem cooles Feature!!
6. Man braucht keine Interfaces mehr (@LocalBean)

Container die EJB3.1 aktuell schon unterstützen sind Glassfish V3, Jboss 5.2 und OpenEJB.

Die dritte Session des Tages trug den verheissungsvollen Titel „EJB in the Large“. Die Referentin war direkt aus Brasilien eingeflogen, um aus Ihrer täglichen Arbeit zu berichten. Das Projekt das hier beschrieben wurde ist als durchaus eindrucksvoll zu bewerten. Es wurde beschrieben, wie ein „Health Care System“ für die Stadt „Sao Paolo“ in sage und schreibe 9 Monaten entwickelt wurde, und zwar auf Basis von EJB 2.1, Entity Beans, Xdoclet, Drools, Luntbuild und CrossDB. Das System konnte täglich ca. 1 Mio Anfragen bearbeiten, was zusammen mit der eingesetzten Technologie schon beinahe Sagenhaft ist.

Auch die Ansätze die die Referentin (gleichzeitig Projektleiterin) gewählt hat, waren sehr interessant. Insgesamt waren in dem Projekt ca. 70 Entwickler beschäftigt aufgeteilt in 3 Teams, teilweise EJB Experten, teilweise aber auch nicht. Am Ende bestand das Projekt aus 600!! EJB-Instanzen (für jeden Use-Case wurde eine eigene SessionFacade erstellt). Der Persistenzlayer wurde mit EntityBeans realisiert. (Aber nicht komplett, denn beispielsweise wurde aus Performancegründen komplett auf das Queriying mittels EntityBeans verzichtet. Dies wurde separat mit einem SQL-Framework CrossDB erstellt).

Der Vortrag an sich konnte leider wenig beeindrucken. Abgerundet wurde das Ganze von einem „Film“ gedreht von Sun, der ca. 10 Minuten dauerte. Ich habe derweil versucht, meine Eindrücke ordentlich zusammenzuschreiben;-).

Der Vortrag bestand eigentlich aus zwei Teilen. Im zweiten Teil sollte die Migration auf EJB 3 beschrieben werden, aufgrund des eher dürftigen ersten Teils habe ich mich aber entschlossen, den zweiten Teil auszulassen.

Als nächstes kam die Keynote von Adam Bien („The Future of Enterprise Java“). Gewohnt souverän versuchte hier Adam Bien die rosige Zukunft von Enterprise Java zu bestätigen, und das prognostizierte Aussterben von EJB zu widerlegen;-).

Das Fazit, dem ich mich persönlich durchaus anschliesse, EJB wird in nächster Zeit nicht aussterben! Good news!

Der nächste Workshop hatte den Titel „JPA under the Hood“ und wurde gehalten von Alois Reitbauer.

Kern des Workshops sollte es sein, herauszuarbeiten, wie sich verschiedene Persistenzframeworks für bestimmte Use-Cases verhalten (untersucht hat der Speaker Hibernate, EclipseLink und OpenJPA). Hierbei wurden u.a. die UseCases ObjectCache und QueryCache betrachtet.

Sehr interessant war für mich hier die vom Speaker eingesetzte Software. Die zentrale Frage hierbei war, kenne ich mein System wirklich, wenn ich nur die Interfaces kenne? (JPA? Hallo?).

Erste Frage: Das Query „select User u where u.id=1“

Essenz: Niemals feste Parameter in Queries kodieren, denn diese Queries können nicht im Querye-Cache landen und werden vom ORM-Framework immer und immer wieder ausgeführt.

Interessanterweise checkt sowohl OpenJPA als auch EclipseLink, dass es den Parameter hierzu ersetzen muss (gespeichert wird also die Query „select User u where u.id=?“.

Hibernate hingegen setzt tatsächlich die nicht parametrisierte Query ab.

Zweite Frage:

Was passiert, wenn der User geladen wird, eine Änderung in der Datenbank gemacht wird und dann diesselbe Query erneut abgesetzt wird?

Antwort: Die Änderungen aus der Datenbank werden nicht geladen, weil die Persistenzframeworks auf Objektidentität prüfen und bemerken, das der User mit der bestimmten ID bereits im Cache vorhanden ist. Durchaus überrsaschend, wenn auch logisch.

Dritte Frage:

Ist „getReference“ tatsächlich sinnvoll? GetReference() bietet die Möglichkeit, eine Referenz aus einer Klasse zu laden, ohne das die eigentliche Klasse wirklich geladen werden muss. (Beispielsweise kann man eine AdressEntity eines Users laden, ohne das der User komplett geladen werden muss).

Ergebnis: Ja, das funktioniert sowohl in Hibernate als auf OpenJPA. EclipseLink lädt leider standardmässig trotzdem alles aus der Datenbank, vorsichtshalber.

Vierte Frage:

Wieviele Connections werden erzeugt, wenn man in einem Loop ständig neue Sessions anfordert?

Antwort: Ohne Transaktionen, eine. Mit Transaktionen erzeugt Hibernate für jede angeforderte Session eine eigene Connection (autsch!).

Eergebnis: Es wäre schön, wenn alle Persistenzframeworks einen gemeinsamen Defaultstandard hätten. Ist aber nicht der Fall…

Im nächsten Workshop ging es um die Specs JSR-299, 330 und 340. Der Referent war Werner Keil, leider habe ich bisher keinen so schlechten Vortrag gehört, deswegen habe ich die gesamte Session versucht, mein Wlan ans Laufen zu bekommen;-).

Die Letzte Session war definitv das Highlight des Tages : Live on Stage Jave EE 6 Hacking mit Adam Bien.

Unter anderem wurden einige SessionBeans erstellt, Restful-Zugriff, JSF 2.0 Seiten, JPA Entities etc.. immer wieder ein Spass, Adam zuzuschauen.

Bin schon gespannt, was morgen kommt.

W-JAX in München

Heute und morgen bin ich glücklicher Inhaber einer Eintrittkarte für die W-JAX 2009 in München.
Es dürften zwei vielversprechende Tage werden, ich werde hier natürlich berichten.

Exzellentes P2-Tutorial

Ein wirklich exzellentes Tutorials über P2 gibt hier.

VIelen Dank an Ralf Ebert für diesen Beitrag.

Toolbar in einer Form mit Commands bevölkern

Wieder 2 Stunden meines Lebens verschwendet, weil ich eine einzige Zeile vergessen habe,

es ist zum ausrasten, damit mir das nicht nochmal passiert, soll das Ganze hier dokumentiert werden. Was wir machen möchten ist die Bevölkerung einer FormToolbar mit einem deklarativ beschriebenen Menu.

Das Ganze soll also über Commands funktionieren.

Hierfür definieren wir zunächst 2 Commands nebst irgendwelchen Handlern:

<command commandId=”playmp3″ icon=”icons/Button-Play-32×32.png” label=”Play” style=”push”>
<command commandId=”stopmp3″ icon=”icons/Button-Stop-32×32.png” label=”Stop” style=”push”/>

Dann definieren wir die Toolbar-Menucontribution, die in der FormToolbar angezeigt werden soll:

<menuContribution locationURI=”popup:myMp3ToolBar”>
<command commandId=”playmp3″ icon=”icons/Button-Play-32×32.png” label=”Play” style=”push”>
</command>
<command commandId=”stopmp3″ icon=”icons/Button-Stop-32×32.png” label=”Stop” style=”push”>
</command>

</menuContribution>

Um dieses deklarativ beschrieben Menu nun in einer FormToolbar anzuzeigen, braucht mal folgendes Codefragment:

…

ToolBarManager manager = (ToolBarManager) sForm.getToolBarManager();
toolkit.decorateFormHeading(sForm.getForm());
IMenuService menuService = (IMenuService)getSite().getService(IMenuService.class);
menuService.populateContributionManager(manager, “toolbar:myMp3Toolbar“);
manager.update(true);
Composite container = sForm.getBody();

Die in fetten Lettern  beschriebene ID ist die genau die ID die wie zuvor definiert haben in der plugin.xml.

Achtung, der Grund für diesen Blogeintrag, vergisst man die zweite fette Zeile, passiert nichts! keine Fehlermeldung kein gar nichts, einfach nichts! Manchmal hasse ich Eclipse.

Maven local Repository

Nur so als Tipp am Rande,

ein lokales Repository konfiguriert man entweder in der ~/.m2/conf/settings.xml oder in der $M2_HOME/conf/settings.xml.

Das GAnze schaut so aus:

<localRepository>G:/development/libs/maven_repo/</localRepository>

und nicht so:

<localRepository>G:/development/libs/maven_repo</localRepository>

Man beachte den / am Ende, der Spass hat mich einen ganzen Abend gekostet um den Build wieder zum Laufen zu kriegen. Zumindest sind jetzt alle Poms wieder aufgeräumt;-)