Schlagwort-Archiv: Google

Google App Engine

GAE mit Maven, JSF und Spring – Teil 1

Tjo, mittlerweile ist der Hype um die Google App Engine schon wieder verflogen. Grund genug mich damit auseinanderzusetzen! Wenn das keinen Sinn ergibt ist das ok so, denn eigentlich spiele ich schon lange mit dem Gedanken mich mit der GAE zu beschäftigen. In Ermangelung des richtigen Projekts, zu vieler richtiger Projekte und zu vieler anderer Projekte, habe ich das aber immer wieder nach hinten verschoben. Bis heute! Denn ich brauche ein kleines Webinterface für eine Java Bibliothek die ich im Sinn habe. Und woher einen Servletcontainer nehmen wenn nicht stehlen? Nun z.B. über die Google App Engine.

Da ich auch meine Erfahrungen mit Spring weiter vertiefen möchte, bietet sich hierfür nun eine Kombination dieser beiden Technologien an. Damit das ganze dann auch noch hübsch aussieht möchte ich ich das ganze um eine gehobene JSF GUI Bibliothek erweitern: PrimeFaces. In dieser Riehe von Blogposts möchte ich nun dokumentieren welche Schritte notwendig waren um die berühmtesten Worte der Software-Development-Geschichte auf die Google App Engine unter Einsatz dieser Technologien zu zaubern: Hello World!

Und wo kämen wir hin wenn wir nicht die Abhängigkeiten sauber verwalten würden? Maven muss her! Als ran ans eingemachte: http://lmgtfy.com/?q=spring+maven+primefaces+google+app+engine

HALT!

Unsere BaugrubeWir wollen ja dabei eigentlich was lernen und nicht Fehler in irgendwelchen Blogeinträgen nachrennen, die die Hälfte von dem, was sie machen, auch erklären. (Daran sind frühere schnelle GAE Versuche mit PrimeFaces gescheitert, ich weiß also wovon ich spreche).

In der Hoffnung es mit meiner eigenen Blogreihe besser zu machen solls nun auch gleich losgehen.

Zuerst eine kurze Zusammenfassung der Zielsetzung

Eine Webanwendung unter Einsatz folgender Technologien:

  • Maven als Buildmanagement
  • Google App Engine als Servlet Container, Persistenz Schicht und schlicht zum Hosten
  • Spring als Mörtel zwischen meinen Java Klassen Ziegel
  • PrimeFaces als Verputz, damit das ganze am Schluss auch etwas gleichschaut.

Damit habe ich auch gleich eine gewisse Reihenfolge vorgegeben, wie Schritt für Schritt die Anwendung zusammengebastelt werden soll.

Als Erstes starten wir mit einem simplen Maven-GAE Projekt. Ich arbeite übrigends mit Maven 3.0.4 und der neuesten Version von Java 1.7

Damit sich Maven und die GAE gut vertragen nutzt man das maven-gae-plugin, auf Google Code bzw. Github, welches zum Zeitpunkt dieses Blogeintrags in der Version 0.9.4 vorliegt.

Damit erzeugen wir uns ein ganz frisches Maven Projekt:

mvn archetype:create\
-DarchetypeGroupId=net.kindleit\
-DarchetypeArtifactId=gae-archetype-jsf\
-DarchetypeVersion=0.9.4\
-DgroupId=your.groupId\
-DartifactId=your-artifactId

Danach haben wir ein gut dokumentiertes POM.xml erhalten, welches sich im Grunde selbst erklärt. Daumen hoch für die Entwickler!

Naja fast, es gibt da so ein paar Kleinigkeiten die fehlen, welche bekommen wir gleich angezeigt mittels

$ maven install

Es fehlt die GAE Versionsnummer
${gaeVersion}
sowie die Gae Plugin Versionsnummer
${gaePluginVersion}

Hätte man durchaus ins Template aufnehmen können mit einem “Huhu hier bearbeiten Kommentar!”, dem aufmerksamen Leser stach es beim Betrachten der POM aber bereits ins Auge.
Beide Einträge ersetzen wir durch die von uns genutzte Version, durch setzen eines entsprechenden Properties

Für die Properties gibt es bereits einen Eintrag
<gae.version>1.7.3</gae.version>

Für das Plugin schreiben wir selbst ein Property

<!--
Specify the Gae Maven Plugin Version
-->
<gaePluginVersion>0.9.4</gaePluginVersion>

 

Brick Wall in Philadelphia

Will man nun das Projekt erneut zum laufen kriegen bekommt man neben so einigen MegaByte App-Engine-Jar Files auch einen kleinen Stolperstein. (Im Gegensatz zu Version 0.9.2 hat das Plugin einiges dazugelernt und so sind einige Fehlerkorrekturen mit falschen Abhängigkeiten nicht mehr notwendig)

Wie gesagt ein Stolperstein ist noch vorhanden. Das maven-war-plugin meldet sich zu Wort, denn das Template hat zwar das POM erzeugt aber keinerlei Verzeichnisse

Diese sind flott nachgezogen, hier der Aufbau:
src
src/main
src/main/resources
src/main/webapp
src/main/webapp/WEB-INF
src/main/java
src/main/java/your.grouID.artefactId
src/test
src/test/resoruces
src/test/java
src/test/java/your.grouID.artefactId

Wir bekommen nun eindeutig Fahrwasser! Das nächste Problem dass uns ein

$ mvn install

offenbart ist eine fehlende web.xml! Und da drinnen wird schon die Anwendung konfiguriert. Das ist nun der Punkt an dem wir das erste Google App Engine Beispiel auf der Herstellerseite für Maven adaptieren.

Als erstes wird ein Servlet erstellt, dazu legen wir in unserem src/main/java ein entprechendes Java File an (Die Servletklasse des Tutorials)

Als nächstes ergänzen wir das Projekt um die web.xml und hinterlegen diese unter src/main/webapp/WEB-INF, ebenfalls wie im Tutorial

Abschließend noch die Konfigurationsdatei, wie im Tutorial, für die App Engine: appengine-web.xml welche wir ebenfalls unter src/main/webapp/WEB-INF ablegen

So frohlockend wie es nun voranging, so schnell laufen wir auch wieder auf Sand:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-war-plugin:2.1-bet
a-1:war (default-war) on project wls: Execution default-war of goal org.apache.m
aven.plugins:maven-war-plugin:2.1-beta-1:war failed: Cannot construct org.apache
.maven.plugin.war.util.WebappStructure as it does not have a no-args constructor
: Cannot construct org.apache.maven.plugin.war.util.WebappStructure as it does
not have a no-args constructor

Hier hat uns das das Alter des Templates einen Streich gespielt, da es noch nicht mit Java 7 umgehen kann. Erhöht man die Version des maven-war-plugin auf 2.1.1 hat man auch dieses Problem behoben.

Jetzt sollten wir in der Lage sein das Google App Engine Projekt zum laufen zu kriegen. Zuerst laden wir das SDK in unser Maven Repository

$ mvn gae:unpack

nun noch ein schnelles

mvn gae:run

und es sollte laufen.

Schön wär’s gewesen, würde alles funktionieren. Aber das Tutorial von Google hat in der appengine-web.xml scheinbar einen Punkt übersehen. So ist es wohl mittlerweile notwendig die Konfiguration für die Threadsicherheit zu hinterlegen. Wir holen dies mit

<threadsafe>false</threadsafe>

nach.

Nun nochmal

mvn gae:run

Und unter http://localhost:8080 steht auf einem Jetty Server unser GAE Hallo World bereit! Naja genauer unter http://localhost:8080/guestbook wenn ihr die GettingStarted Dateien eins zu eins übernommen habt.

Win Win Win!

Und im nächsten Blogeintrag werden wir das ganze um JSF erweitern!

Greets!

Ähnliche Artikel:

Meine genutzten Plugins aus dem Eclipse Marketplace

Anlässlich der millionsten Installation eines Plugins über den Eclipse Marketplace seit Juni 2010 wollte ich hier ein wenig über die Top10 der gedownloadeten Plugins schreiben, sowie über die von mir eingesetzten Erweiterungen.

01. Subclipse

Subclipse steht in Konkurrenz zu Subversive, welches ich verwende. Auch wenn ich Subclipse schon selbst verwendet habe, bin ich doch überzeugter Subversive Nutzer. Wohl aber nur weil ich das Teil bereits gewöhnt bin.
http://marketplace.eclipse.org/content/subclipse

02. Maven Integration for Eclipse

Unverzichtbar für jedes Maven Projekt. Da ich selbst bei TrayRSS auf Maven setze komme auch ich nicht um m2e herum. Hier bleibt zu resumieren, dass einem das Plugin nicht davor bewahrt sich mit Maven selbst auseinander zu setzen, um das beste für seinen Build zu erzielen. Wer sich mehr mit Maven auseinandersetzen möchte, dem empfehle ich die Dokumentation auf der Maven Seite selbst: http://maven.apache.org/ Diese ist mMn gut aufbereitet. Für tiefersitzende Probleme ist vielleicht folgendes frei erhältliches EBook hilfreich: The Maven Cookbook. Es ist als PDF oder als HTML Version als direktes Nachschlagewerk vorfügbar.
http://marketplace.eclipse.org/content/maven-integration-eclipse

03. Subversive – SVN Team Provider

Das SVN Plugin meiner Wahl. Bisher durchaus ein Usabilitygraus in der Installation, hat der Market die Installation des Plugins erheblich vereinfacht. Subversive bietet nämlich die Möglichkeit über verschiedene Connectoren auf die Repositories zuzugreifen. Diese mussten aus lizenzrechtlichen Gründen über eine extra Installationsseite nachinstalliert werden. Der Market bietet nun nach Installation des Basis-Plugins eine eigene Auswahlseite auf der die gewünschten Connectoren gewählt werden können, sodass Eclipse diese dann ohne weiteres zutun des Benutzers installiert.
http://marketplace.eclipse.org/content/subversive-svn-team-provider

04. EGit – Git Team Provider

“Neu” in der Familie der meiner Plugins ist EGit. Da ich Git noch nicht sehr lange als Versionierungsverwaltung nutze, und erst langsam auf den Geschmack von Git und Github gekommen bin, beschränkt sich meine Erfahrung mit dem Plugin auf ein paar Feldversuche. Git selbst hat mich bereits überzeugt. Und in Zusammenhang mit Open Source finde ich hat Git alle Trümpfe in der Hand. Das Plugin selbst ist etwas komplexer aufgebaut, lässt aber auf den ersten Blick nichts missen. Als Unterstützung für Git-Einsteiger ist es jedoch im Gegensatz zu den SVN-Plugins meiner Meinung nach nicht geeignet. Hier führt der Weg an einem Kommandozeilenbasierten Einstieg nicht vorbei.
http://marketplace.eclipse.org/content/egit-git-team-provider

05. Spring IDE

Dieses Plugin habe ich bisher noch nicht genutzt. Equivalent dazu sind wohl die JBoss Tools. Um Spring Anwendungen zu entwickeln greife ich selbst noch auf die Pluginsammlung von MyEclipse zurück (u.a. die MyEclipse Spring Tools), welche von meinem Arbeitgeber zur Verfügung gestellt wurde.
http://marketplace.eclipse.org/content/spring-ide

06. Eclipse Color Theme

Dieses Plugin nutze ich ebenfalls nicht. Ich habe mir im Zuge dieses Artikels die Funktionsweise des Plugins angesehen, denke aber dass ich es weiterhin nicht einsetzen werde. Ich war bisher noch nie der Typ Mensch, der seine Fenster farblich komplett neu coloriert und muss daher auch den Inhalt des Editors an nichts anpassen.
http://marketplace.eclipse.org/content/eclipse-color-theme/metrics

07. PyDev – Python IDE for Eclipse

Jeder der schon mal in Eclipse eine Python Anwendung entwickelt hat kommt an diesem Plugin eigentlich nicht vorbei. Auch ich nicht. Ich habe damit z.B. Pong programmiert. Mag es zum Python Entwickeln nicht mehr missen, auch wenn die mit Python mitgelieferte IDLE Entwicklungsumgebung durchaus auch seinen Charm und seine Einsatzzwecke hat.
http://marketplace.eclipse.org/content/pydev-python-ide-eclipse

08. FindBugs Eclipse Plugin

Dieses Plugin habe ich aktuell ebenfalls nicht im Einsatz. Das sollte ich allerdings nochmal gründlich überdenken. Erste Versuche damit vor mehr als einem Jahr waren eigentlich ein für meinen Code interessant Erlebnis. FindBugs versucht mittels prüfen auf Bug Pattern Fehlerquellen im Code zu identifizieren durch z.B. falsch genutzte API Aufrufe. Vielleicht gebe ich dem Plugin bald mal wieder einen Versuch.
http://marketplace.eclipse.org/content/findbugs-eclipse-plugin

09. Google Plugin for Eclipse

Mit diesem Plugin habe ich leider noch keine Erfahrung und kann daher nicht viel dazu sagen. Am besten selbst mal nachlesen.
http://marketplace.eclipse.org/content/google-plugin-eclipse

10. JBoss Tools (Helios)

Als ich damals für eine Übung an der TU mit JBoss Seam entwickeln musste hab eich die JBoss Tools kennen gelernt. Sie sind eine mächtige Sammlung an Tools für das Entwickeln von Webanwendungen. Dabei habe ich aber auch ein paar Grenzen kennengelernt. So erzeugen die JBoss Tools in Fundament gegossene Projektstrukturen, was einem späteren Einsatz der Tools auf bereits vorhandene Projekte etwas erschwert. Dennoch bieten sie genug positive Funktionalitäten um derartige Hürden zu überwinden. Und sie sind natürlich perfekt auf den JBoss Server zugeschnitten ;)
http://marketplace.eclipse.org/content/jboss-tools-1

Aus den Top10 habe ich somit bereits 8 Verwendet und verwende 6 immer noch, lediglich 4 weitere Plugins kommen bei mir bewusst zum Einsatz:

Checkstyle

Dieses Plugin dient zur Code Analyse und unterstützt den Entwickler bei der Einhaltung von Coding Conventions.
http://marketplace.eclipse.org/content/checkstyle-plug

GitHub Mylyn Connector

Um Mylyn mit den Github Issues kurzzuschließen
http://marketplace.eclipse.org/content/github-mylyn-connector

Android Configurator m2e

Um Maven mit der Android Entwicklung zu verbinden
http://marketplace.eclipse.org/content/android-configurator-m2e

Android Developement Tools

Die Entwicklungstools für Android sind nicht Teil des Marketplaces sondern direkt zu beziehen:
http://developer.android.com/sdk/eclipse-adt.html

Leider ist der Eclipse Marketplace noch nicht für Eclipse 4.x vorhanden. Auf diese Version bin ich im Zuge des Releases von Java 7 umgestiegen. Wenn jedoch der große Umstieg bevorsteht hoffe ich ihn auch darin wieder nutzen zu können.

Ähnliche Artikel:

Gebt Oracle Zeit!

Es schlägt zur Zeit überall große Wellen, erst kauft Oracle Sun auf, dann braucht es länger als einen Tag um sich in den Unternehmensstrukturen zurechtzufinden, gibt schließlich an Tag 2 nicht zu allen Projekten die weitere Zielsetzung bekannt. Will an Tag 3 doch tatsächlich mit dem Einkauf Geld verdienen und hat an Tag 4 immer noch nicht alle Projekte komplett gesichtet und die zukünftige Roadmap festgelegt. Verklagt daraufhin an Tag 5 Google, und während der Kampf Böse gegen Böse hier nun tobt, tun sich noch weitere Fronten auf. Eine Woche nach der Übernahme sprießen die Forks von Sun Projekten (Maria DB, Libre Office, Open Solaris) wie Maiglöckchen im Frühling. Zwei Wochen nach der Übernahme hat die Apache Software Foundation dem JCP den Rücken gekehrt. Oracle hatte im Lizenzstreit über Wochen hinaus keinerlei Bereitschaft für ein Miteinander gezeigt und strikt seine Sicht der Dinge fortgeführt.

Den Aufschrei der nun durch die Blogosphäre (grausames Wort) geht kann ich verstehen und nachvollziehen. Ja er ist sogar notwendig, damit Oracle sieht was diese Entscheidungen bewirken. Und dass dahinter sehr viel Emotion und Identifikation steckt.

Dass die ASF als Non-Profit-Organisation mit Oracle Lizenztechnisch im Klinsch liegt, und noch lange liegen wird, ist ebenfalls verständlich, und in meiner Position kann man hoffen dass hier das letzte Wort noch nicht gesprochen ist.

Und auch wenn ich selbst einige Entscheidungen seitens Oracle gern anders gesehen hätte, bleibt mir gerade deshalb nur zu sagen: Gebt Oracle Zeit!

Viele Geschäftsfelder dieser Firma funktionieren in und mit Java, man ist also davon abhängig. Und sie haben Recht, Java muss sich weiterentwickeln. Es herrschte lange Stillstand, der durch eine tolle Community kompensiert wurde. Durch 3rd Party Frameworks u.a.. Und deshalb kann die Community auch jetzt zeigen, dass ihr was an Java liegt, und weiterhin den Dialog suchen, versuchen Java voranzubringen und vor allem versuchen Oracle etwas Zeit zu geben einen Weg zu finden der für alle akzeptabel ist (und dabei weiterhin aufschreien wenn man nicht gehört wird).

Denn wenn Oracle noch nicht mal die Verpackung der Sun Produkte komplett erneuern konnte (siehe Bild), wie soll dann bei so vielen Projekten schon der für alle Beteiligten richtige Weg eingeschlagen sein?

Virtualbox Installationsdialog Oracle Sun gemixed

PS: Die zeitliche Anordnung der Ereignisse ist frei definiert. Die genannten Distanzen sollen vor allem eins Zeigen, es ist alles noch in den Kinderschuhen.

Ähnliche Artikel:

Programmiersprachen-Popularität auf TIOBE

Einer der typischen Stereotypen die min vorallem im Umfeld eines Wirtschaftsinformatikers findet sind Java Entwickler, die meinen Java zu können und nur Java. Vielleicht noch etwas HTML und Javascript, wir sind schließlich 2.0!

Wer jedoch seinen Horizont erweitern will, und dazu muss man nicht zwingend aus diesem Umfeld kommen, der scheint vor einer schier endlosen Auswahl zu stehen. Mit welcher Programmiersprache soll man sich auseinandersetzen? Man will schließlich nicht zuviel Zeit in eine Programmiersprache setzen, deren Bedeutung am absteigenden Ast ist. (Es sei denn man will bewusst in diese Niesche treten, Legacysysteme zu pflegen gilt es nachwievor!)

Eine kleine Entscheidungshilfe könnte der TIOBE Programming Community Index sein, der Monatlich unter folgender URL aufrufbar ist:

http://www.tiobe.com/tpci.htm

Zu sehen ist dass die beiden Zugpferde C und Java sich ein heißes Duell liefern. Generell ist die komplette C Rige stark vertreten, doch auch die Scriptsprache PHP scheint nicht so leicht aus den Herzen der Programmierer wegzudenken sein. Immer mehr im Kommen ist Objective-C dass die letzten Monate einen rasanten Zugewinn verzeichnet. Nach anfänglicher Euphorie 2009 hat auch Googles C Alternative Go den Wiedereinstieg in die Top 20 geschafft. (Stand August 2010)

Freilich repräsentiert dieser Index nur die Häufigkeit von Suchanfrage zu den Programmiersprachen bei den Suchriesen Google und Yahoo und sind noch lange kein Indikator dafür, was der Jobmarkt nun tatsächlich bietet. Ein Hype bei einer Programmiersprache bedeutet noch lange nicht dass diese auch kommerziell verwendet wird. Hinzu kommt dass nur englischsprachige Suchbegriffe gewertet werden, so dass man die Ergebnisse nur begrentz auf unseren Wirtschaftsraum umlegen kann.

Sich über das Potential und das Interesse anderer an eben der zukünftigen Programmiersprache im klaren zu sein kann aber durchaus motivationsfördernd sein.

In diesem Sinne

Frohes Schaffen

Ähnliche Artikel:

Google Street View Autos in Wien gesichtet

Am Parkplatz vor dem Palais Schwarzenbergplatz [1] wurden heute gegen 13:30 die Google Street View Autos gesichtet. Sie sind wohl schon oder bald in Wien Unterwegs. Wer jetzt schon Wien betrachten will kann dies auf der rumänischen Seite: http://www.norc.at

Dass die Wagen bald hier wieder unterwegs sein könnten wurde schon auf computerwelt in folgendem Artikel bekanntgegeben: http://www.computerwelt.at/detailArticle.asp?a=127085

Google Street View Autos

Google Street View Autos

So standen sie am Parkplatz rum, wobei der rechte Wagen etwas ramponiert war. Man beachte den Spiegel auf der Fahrerseite. – ein paar Schrammen seitlich zeigten dass man beim Fotographieren wohl die Breite seines Wagens aus den augen verlieren kann ;)

Google Street View Autologo

Google Street View Autologo

Nicht ganz typisch ist das Google Logo auf dem Wagen. Aber bitte auch auf der Suchmaschinenseite ist das Logo regelmäßig anders verpackt!

Google Street View Wagenaufsatz

Google Street View Wagenaufsatz

Leider waren die Kameras eingepackt. Die Vorrichtung lässt ein Kippen der Kameras zu um durch Brücken oder ähnliches durchzupassen.

[1] http://de.wikipedia.org/wiki/Palais_Schwarzenberg_am_Schwarzenbergplatz

Ähnliche Artikel: