Schlagwort-Archiv: maven

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:

Java 7 Compiler in Maven

Lang ist’s her dass ich hier was technisches gebracht hab. Die Fotographie und einige private Dinge haben mich davon ab gehalten. Doch die Zeit der dürre ist vorbei, ich hab wieder begonnen meine Erfahrungen für den Blog festzuhalten :D

Möchte man Java 7 in einem Maven Projekt verwenden muss man dem Maven Compiler Plugin das auch mitteilen. Dieses würde atm. ansonsten versuchen das Projekt mit gutem alten Java 5 zu bauen.

Dazu muss das Plugin über folgende Angaben in der pom.xml umkonfiguriert werden:

<build>
    
    <plugins>
        
        <plugin>
            <groupid>org.apache.maven.plugins</groupid>
            <artifactid>maven-compiler-plugin</artifactid>
            <configuration>
                <source>1.7</source>
                <target>1.7</target>
                <showdeprecation>true</showdeprecation>
                <showwarnings>true</showwarnings>
                <executable>${env.JAVA_7_HOME}/bin/javac</executable>
                <fork>true</fork>
            </configuration>
        </plugin>
    </plugins>
</build>

Natürlich muss der Entwickler dafür die Umgebugnsvariable JAVA_7_HOME auf den Rootordner des JDKs der Version 7 linken.

Weitere Infos gibts auf der Seite des Maven Compiler Plugin. Unter Examples gibt es auch den Punkt “Compile Using A Different JDK” der die Vorgehenswiese dabei analog beschreibt. Dabei wird auch eine Möglichkeit aufgezeigt wie der Entwickler den Path JAVA_7_HOME in seiner Maven settings setzen kann.

Have Fun mit Java 7

Ä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:

Java 6 SplashScreen in maven

Ein gut gemachter Splash Screen ist schon lange in diversen Anwendungen das Mittel zum Zweck gewesen um den Anwender zu zeigen, dass das Programm das er eben gestartet hat lädt und bald zum Einsatz bereit steht. Neu in Java 6 wurde die Möglichkeit einen Splash Screen bei Programmaufruf bereits mitzugeben. Früher musste man dazu ein JFrame oder ein JWindow in Java Swing erzeugen, welches jedoch erst nach Start der VM und dem laden der dafür erforderlichen Klassen erfolgte. Schneller geht das nun mittels der von Java 6 bereitgestellten Möglichkeiten, entweder in der Command Line

java –splash:images/splash.jpg MyMainClass

oder in der Manifest Datei einer Jar

Manifest-Version: 1.0Main-Class: MyMainClassSplashScreen-Image: images/splash.jpg

Dabei wird das Bild von Java in einem einfachen nicht dekorierten Fenster dargestellt, d.h. z.B. ohne X zum schließen. Folgendes Beispiel soll nun zeigen wie selbiges über Maven erreicht wird, wenn man eine Jar erzeugen lässt.

Zuerst legt man eine Grafikdatei die als SplashScreen dienen soll unter den Ressourcen des Programms ab. Als Beispiel könnte folgender Pfad dienen:

ProjektName/src/main/resources/images/splash.jpg

Dann fügt man das maven-jar-plugin in sein POM File ein und konfiguriert dieses so, dass es den SplashScreen anzeigt.

            <plugin>
                <artifactid>maven-jar-plugin</artifactid>
                <version>2.3.1</version>
                <executions>
                    <execution>
                        <phase>package</phase>
                        <goals>
                            <goal>jar</goal>
                        </goals>
                    </execution>
                </executions>
                <configuration>
                    <archive>
                        <manifest>
                            <mainclass>my.packages.MyMainClass</mainclass>
                            <adddefaultimplementationentries>
                                true
                            </adddefaultimplementationentries>
                            <addclasspath>true</addclasspath>
                            <classpathprefix>lib/</classpathprefix>
                        </manifest>
                        <manifestentries>
                            <version>
                                ${project.version}
                            </version>
                            <implementation-version>
                                ${project.version}-${buildNumber}
                            </implementation-version>
                            <splashscreen-image>imgages/splash.jpg</splashscreen-image>
                        </manifestentries>
                    </archive>
                </configuration>
            </plugin>

In die <manifestentries> kann man den Eintrag <splashscreen-image> schreiben, der den selben Inhalt hat wie man es in der Manifest Datei der Jar Datei schreiben würde. Der gesamte Pfad wo wir die Datei abgelegt haben (also das ProjektName/src/main/ressources/… ) ist dabei nicht erforderlich da sich hierbei auf den Inhalt der zukünftig generierten Jar Datei bezogen wird.

Bis zum nächsten mal, mit mehr zum Thema SplashScreen.

Ähnliche Artikel:

rss_icon

TrayRSS 1.0.1 is here!

Hi there,

i’d like to announce the new Bugfixrelease of Trayrss! Besides bugfixing, I made some pretty interesting changes

Changes in 1.0.1
* performance refactoring
* event-dispatcher threads for gui
* log4j updated
* refactored the useage of log4j
+ task 00035: implementing maven
* fix 00033: timesets starttimes where set as endtime
+ task 00035: packaging by maven
+ task 00035: buildnumber
- task 00044: SWIXML menu removed

You can download the new relesase here.

Changes

I’ve fixed some bugs in the event-dispatcher thread of the gui, so trayrss is now more stable. Also there was an error when monitoring feeds with an invalid timeframe. TrayRSS stopped monitoring without telling the user if the format of the timeframe could not be parsed correctly.

Besides the logging feature was updated too. This and some additional changes within the source should lead to a little performance increase.

Bugtracker

TrayRSS relied on Trac for about two years. But Trac has its limitations. Now MantisBT is used to track all the tasks that are required to improve the application. The relation between a sourcecode change and a task will be noticed in the changelog in future by adding the tasknumber. Also Trac was binded to sourceforge. Now it isn’t necessary to have a sourceforge-account anymore to report an bug or request.

In MantisBT there are some additional possibilites to create reports. Also better notifications and a easier way to manage milestones are provided by the new bugtracker.

Maven

Additionally TrayRSS developement steps ahead to the next major release 1.1 Some major changes will be part of this release and the first step was also shipped with this Bugfixrelease: TrayRSS moved from ant to maven to manage the build process and to collect all the dependencies. That offers TrayRSS some important possibilities for the future such as managing multimodule projects, improves reusability, convention over configuration and so on. Some details about the migration will be described in future on nullpointer.at.

Hope you enjoy the new release

Kind regards!

Ähnliche Artikel: