Vielen Probleme damit führten dazu, standardmäßig Disable Workspace Resolution und Disable Nested Modules zu wählen.

Das macht aber das Debuggen schwierig: Beim Debuggen möchte man beim Debuggen direkt in den Quellcode der mit der Startanwendung verbundenen Modulprojekte springen.

Defaultmäßig ist das nicht möglich, vielmehr wird die .class-Datei im Editor angezeigt. Hier hilft auch nicht, den Ort des Source-Codes in den Maven-Abhängigkeiten manuell mitzuteilen.

Verlinkte Quellordner (siehe linked resources) helfen hier nicht.

Lösung
In den Debug-Einstellungen als Quellordner die Modulprojekte angeben über Debug->Open Debug Dialog->Source.

Tip
Wenns beim Debuggen von WTP-Projekten dennoch nicht funktioniert, daran denken, den Server im Debug-Modus zu starten

Der Grund: Abhängige Module benötigen ab Maven 2.06 immer in ihrer eigenen pom.xml ebenfalls die Angabe der Versionsnummer. Zur Umstellung siehe die gesonderte Seite hier.

Glücklicherweise arbeite ich mit einer Struktur, in der ich Build-Tools in ein Defaultverzeichnis "current" packe, so dass schnell auf eine andere Version gewechselt werden kann.

Nichtsdestotrotz finde ich es wenig verständlich, wenn in einem Minor-Release eine derart elementare strukturelle Veränderung vorgenommen wird. Als Maven-Anwender hätte ich mir allenfalls eine Warnung gewünscht mit Rückfall auf die ältere Funktionalität.

Wozu gibt man denn in Maven die Versionsnummer im <modelVersion>-Element der pom.xml überhaupt an, wenn nicht auch für eine Abwärtskompatibilität? Sehr merkwürdig.

Über S.H.: von Struts über JSF, Spring MVC zu Grails. Erstellt Grails Podcast.

Motivation

Framework wie Rails – Convention over Configuration, DRY

Spring MVC im Hintergrund

Grails vs. Rails Benchmark – Skaliert weitaus besser als Rails. 1.0 Release im Sommer, 0.5 im Mai.

grails clean

grails update

zum Update, soll schmerzlos sein.

Benutzte Frameworks

Spring: Spring DI + Spring MVC

Hibernate

SiteMesh – Layouting

Java EE – Integration

Standalone oder Hib-Mappings f Legacy-Schemata; EJB3-Integration; vorhandene Spring-Beans können verwendet werden.

Quickstart siehe am besten hier.

ApplicationBootStrap zum Persistieren.

TL-Erzeugung. Zur Laufzeit deploybar, ebenso mit Controller + Service.

Server-Start runApp.groovy. snipplr.com

MVC in Grails

Model: Domain-Klassen etc.

class Podcast {

String title

String feedUrl

}

View: Groovy SP oder JSP; dynamic TagLibs

Controller: Grails Controller + Grails Service

Object-Relational Mapping GORM. Equals()/hashCode() werden automatisch + dynamisch erstellt.

grails create-domain-class

Mapping 1:1

class Podcast {
Author author
String title
}

Mapping 1:n

class Podcast {
def hasMany = [ episodes : Episode ]
String title
}

Mapping m:n

class Podcast {
def hasMany = [ episodes : Episode ]
String title
}

class Author
{
def hasMany = [ podcasts : Podcasts ]
}

GORM: Dynamic Finders

Podcast.findByTitle(), QBE + HQL unterstützt.

Constraints

class Podcast {
String title
String feedUrl
static constraints = {
title(size:1..50)
feedUrl(unique:true)
}
}

GORM DB Konfiguration

development/production/test

Classe Development[...]DataSource ändern. Standard: Development.

View-Technologien

Die meisten verwenden GSP wg. der Dynamic Tag Libs.

Grails Controller

Generierbar (mit CRUD), wird dynamisch geladen. Immer alle CRUD-Operationen werden erstellt, DELETE kann z.B. nicht ausgeschlossen werden. Controller und Views müssen entsprechend manuell angepasst werden.

Parameter, Session, Flash-Objekte.

render()-Methode sehr mächtig – AJAX

HTTP-MEthod-Restrictions.

Dynamisches Scaffolding

im Bsp.: def scaffold= Podcast

Services

Kapselung von Business-Logik.

Buchempfehlung Getting Started with Grails (InnoQ)

]]> http://blog.gresch.de/2007/04/26/jax-2007-grails-rapid-web-application-development-sven-haiges-actionality/feed/ 0 http://blog.gresch.de/2007/04/26/jax-2007-maven-2-ae-umstellung-eines-projekts-von-ant-zu-maven-2-oliver-stauss-exxcellent-solutions/ http://blog.gresch.de/2007/04/26/jax-2007-maven-2-ae-umstellung-eines-projekts-von-ant-zu-maven-2-oliver-stauss-exxcellent-solutions/#comments Thu, 26 Apr 2007 08:46:36 +0000 KG http://web636.webbox122.server-home.org/wpkg/?p=179 Historie – von make über Ant, Maven 1 zu Maven 2. Einfluss der Rails-Community. Komplett neue Implementierung von 1.

Paradigmenwechsel: Nicht Build-Skripte erstellen, sondern Projekte konfigurieren.

Nicht das wie des zu erzeugenden, sondern das was. Mehr managen als erzeugen. OO-Mechanismen zur Konfiguration (also Projekt).

mvn2 hilft bei einem Großteil des Entwicklungsprozesses. Unterstützung für

• Kompilation
• Releaserstellung
• Bibliotheksabhängigkeiten
• Dokumentation
• Unit- und Integrationstests
• nn
• nn

Weniger ein Tool wie Ant – vielmehr eine standardisierte Best-Practices-Enforcment-Box.

Konzepte

Project Object Model, beschrieben in pom.xml. Name + Version + Typ, Vererbung, Unterprojekte (Module), Abhängigkeiten und Repos, Lifecycle- Plugin Konfigurationen, Profile, Properties, sonstiges (Issue Tracker, Version Control etc).

Artifact:

Ergebnis (Produkt) eines mvn2-Projekts. Typen: jar, war, ear, sar; plugin, archetype, pom.

Werden in Rep abgelegt. Jedes mvn2-Projekt erzeugt lediglich ein Ergebnis (dadurch Modularisierung erzwungen).

Goal

Wie Ant-Target.

Plugin

Logische Gruppierung von Goals. In Reps verwaltet.

Syntax: plugin:goal

archetype:create – Skeleton für weitere Projekte.

cargo:start – Für Java EE interessant.

compiler:compile: Quellcode kompilieren.

Repositories

Zentrale Stelle, in der alle Artifacts abgelegt werden. Zwei Type: Lokal (file://[user-home].m2/repository), Remote (z.B. http://repo1.maven.org)

Dependency-Management

Alle abhängigen Artefakte über Repositories verwaltet, werden nicht physische in das Projekt kopiert. Kein "Jarmaggedon".

Build-Lifecycle

Definiert in Phasen: validate-generate-resource-compile-test_compile-test-package-integration_test-install-deploy. Phasen mit plugin-goals verbunden.

Reports

QA-Reports, generelle Projektinformationen.

Frage: Wie funktioniert das innerhalb Eclipse?

Antwort: Plugins, libraries in rep

Ãœbergang von Ant zu Maven 2

Refactoring des Ant-Projekts. Projektstrukturen vereinfachen! Bei mehreren Artifacts in Unterprojekte aufteilen.

Auflösen der Abhängigkeiten. Verwendete Bibliotheken identifzieren (mit Version!) – das ist normalerweise der aufwendigste Punkt.

Einspielen von 3rd-Party- und Inhouse-Bibliotheken in internes Repository.

POM definieren. Spezielle Ant-Targets in mvn2 umsetzen. Weitere features nutzen, um Qualität zu steigern.

Beispiel: antAuthProject

/src und /test/src-Folders. /lib, /etc; client, common und server-Packages.

=> mvn: drei Verzeichnisse /server, /common, /client und eine pom.xml auf root-Ebene und jeweils in den drei Verzeichnissen. Sourcen darunter in /src/main (Mvn2-Konzept) und /src/test. Alles andere in /resources.

Auflösen der Abhängigkeiten: Gut, wenn Versionsnummer in jar-Namen enthalten sind.

mvn install:install-file, um Libs in Rep zu bekommen (für internes Rep).

Mvn-plugin für spezielle Ant-targets. <parent>-Tag für Submodule. Submodule erben Konfig des Hauptprojekts (z.B. Unit-Tests, CodeCoverage).