OlliN's » groovy

Groovy – Process#pipeTo und Operator Overloading

ollin — Mon, 10 Mar 2008 15:13:11 +0000

Operator Overloading ist eine feine Sache. Groovy erweitert z.B. die Klasse java.lang.Process um die Methode “or(Process right)”. “or” wird in Groovy auf den Operator “|” gemappt. Dadurch kann man die Ausgabe eines Prozesses zu einem anderen “pipen”

test.groovy:

#!/usr/bin/env groovy
def p1 = "ls -al".execute()
def p2 = "grep test".execute()
p1 | p2
p2.waitFor()
println p2.text

Groovy als Javaentwickler

ollin — Sun, 03 Jun 2007 18:08:32 +0000

Inzwischen sind ein paar Tage ins Land gegangen seit ich über Groovy berichtet habe. Was wirklich toll ist, dass man als Java-Entwickler “fast” einfach so loslegen kann. Man braucht auf keine seiner Lieblings-lib’s verzichten und syntaktisch sind sich Groovy und Java auch recht nah. So habe ich auch das Nümmerlitiger-Tool geschrieben – just do it. Es ist fertig und funktioniert.

Damals war ich ca auf Seite 150 von “Groovy in Action”. Jetzt bin ich um die Seite 300. Sozusagen um das Doppelte schlauer Die Hälfte vom Code könnte ich wahrscheinlich schon wegwerfen – weil unnötig. Da gibt es ja so schöne Sachen in Groovy – z.B die Builder oder GPath. Allein wegen des AntBuilder ist, z.B. für alle die die sich mit Build-Automatisierung auseinandersetzen, Groovy einen Blick wert.
Und wie sagt schon Der Pragmatische Programmierer: Jedes Jahr eine Sprache lernen.

Talk to Snipplr with Groovy

ollin — Fri, 11 May 2007 11:16:07 +0000

Wie ich schon geschrieben habe, bin ich derzeit dabei in Groovy einzuarbeiten. Dazu schreibe ich ein kleinen Command Line Tool, welches wir zum Eclipse-RCP-Release-bauen verwenden können. Es gibt da einen Job den nennen wir “Nümmerlitiger” (jeder Entwickler darf mal). Eine Eclipseapplikation besteht aus Plugins und sind alle in separaten Eclipseprojekten. Wenn man nun die Version zu einem Plugin baut, so müssen wir pro Plugin an dem entwickelt wurde (diff in subversion) wurde die Bundle-Version-Nummer im MANIFEST.MF des Plugins hochsetzen, dann die Datei ins Subversion einchecken und dann noch unsere MAP-Datei auf die Versionsnummer aktualisieren. Die MAP-Datei (Siehe dazu Präsentation von meinen Kollegen Edwin und Löti) ist unsere Steuerdatei für den automatischen Build. Diese muss natürlich zum Schluss auch eingecheckt werden. Ausserdem darf man das Taggen des Plugins nicht vergessen. Der Prozess ist nicht nur Fehleranfällig, nein er ist auch langweilig und dauert schon mal 30min wenn man wie wir ca. 20 Plugins in einem Projekt hat.

Gestern bin ich beim Suchen nach Beispielen auf snipplr gestossen und habe am Abend gleich mal probiert mit Groovy auf die XML-RPC Schnittstelle zuzugreifen.

[snippet=2624]

Das ist wirklich einfach. (Übrigens wird der Code via einem Snipplr-Wordpress-Plugin von snipplr geholt und dargestellt. Die Buchstaben “URL” z.B. sind ein Link auf Google.) Als XML-RPC-Implementierung habe ich die von ws.apache.org benutzt.

—

Update 2008-03-03: Das Plugin funktioniert nicht mehr mit neueren WordPress-Versionen. Deshalb der Code hier:

package net.nautsch.snipplr;import org.apache.xmlrpc.client.XmlRpcClient;

import org.apache.xmlrpc.client.XmlRpcClientConfigImpl;

class SnipplrRunner {

static void main(args) {

        XmlRpcClientConfigImpl config = new XmlRpcClientConfigImpl()

    config.setServerURL(new URL("http://snipplr.com/xml-rpc.php"))

XmlRpcClient client = new XmlRpcClient()

        client.setConfig(config)

        Object[] params = ["insert your id here"]

def boolean result = client.execute("user.checkkey", params)

    println result

  }

}