Monthly Archives: Oktober 2011

Grails-Plugin als *.ZIP im Maven-Repo ablegen.

Die Arbeit mit Maven und Grails macht wirklich Laune. Währen da bloß nicht auch solche Tage, an denen ich dieses Pärchen überhaupt nicht sehen mag – wie z.B. heute.

Wenn ich mit Grails ein Plugin schreibe, möchte ich es in ein Maven-Repo installieren und anderswo nutzen können. Schön wäre da eine Goal-Abfolge wie mvn grails:package-plugin install. Geht aber nicht, daher habe ich mir bisher mit dieser Lösung ausgeholfen.

Weil ich das aber recht nervig finde, habe ich heute noch mal geforscht, und siehe da, es geht doch – und zwar so:

  1. Grails Plugin erzeugen und „mavenifizieren“.
  2. Den Nachfolger des Maven-Publisher-Plugins installieren => Release-Plugin.
  3. In der pom.xml grails-plugin als Packaging eintragen: <packaging>grails-plugin</packaging>
  4. mvn install ausführen.

Im Resultat wird das Plugin gepackt und ein *.zip-Archiv erstellt, welches anschließend in das lokale Maven-Repo kopiert wird.

Damit ist es aber noch nicht ganz erledigt. Möchte ich in einer anderen Grails-Anwendung das Plugin nutzen, so trage ich in der application.properties die Abhängigkeit dazu ein. In meinem Fall heißt das Plugin Carty:

app.grails.version=1.3.7
app.name=XXX
app.servlet.version=2.4
app.version=0.1
plugins.carty=0.0.1
plugins.hibernate=1.3.7
plugins.tomcat=1.3.7

Grails versucht das Plugin zu finden, indem es diverse Quellen anzapft. U.a. auch den lokalen Maven Cache:

==== localMavenResolver: tried
	  /Users/hellboy/.m2/repository/org/grails/plugins/carty/0.0.1/carty-0.0.1.pom

Bloß, unter dem Standard Grails-Namespace findet er nichts, da meine Packages anders benannt sind. Ich helfe ihm einwenig nach und trage in der BuildConfig.groovy den entscheidenden Hinweis ein:

grails.project.dependency.resolution = {
  ...
  repositories {
    ...
    mavenLocal()
    ...
  }
  plugins {
    runtime 'de.fivews.carty:carty:latest.integration'
  }
}

Auf diese Weise kann ich Grails-Plugins bauen, sie in ein Maven-Repo installieren und anderswo als Abhängigkeit nutzen. Besonders bei der Verwendung eines Continuous Integration Servers ist das sehr nützlich.

WordPress Redirect auf wp-admin/install.php

Da läuft die Installation meines Blogs seit einigen Monaten problemlos, und auf einmal geht nichts mehr. Wie ich Serveradministration liebe … 😉 Dank den Logs habe ich schnell festgestellt, dass die /var Partition meiner FreeBSD Machine voll war. Die Übeltäter schnell mit du -skh /var/* | sort -n identifiziert und beseitigt.

Nach dem Neustart von Lighttptd und MySQL habe ich mein Blog aufgerufen und wurde auf wp-admin/install.php weitergeleitet. Das ist ganz schön ärgerlich und nur gut, dass ICH das festgestellt habe und nicht jemand, der das hier für eine Demo-Installation von WordPress hielt und die Installation mal durchgeführt hat 😉

Bei der Suche nach der Ursache half mir das hier weiter. Hätte ich nicht gedacht, aber auch eine MySQL Tabelle kann mal kaputt gehen. Abhilfe verschafft der Befehl mysqlcheck DATABASENAME. Wenn da was nicht in Ordnung ist, kann die Tabelle auch repariert werden und zwar mit mysqlcheck --repair DATABASENAME.

Puhh, schätze noch mal Glück gehabt 🙂