RRZE – Projekte & Prozesse (P&P)

Das Blog der RRZE Stabsstelle "Projekte & Prozesse"

Content

Grails Plugins – lokal und global / Grails Plugins – local and global

English Version

Bei der Verwaltung von Grails Plugins in einem zentralen Repository gestaltet sich die lokale Weiterentwicklung der Plugins ggf. schwierig.

Mit dem folgenden Code-Block in der BuildConfig.groovy kann mittels des Kommandozeilenparameters -Dlive=... eines, oder mit
Komma getrennt, mehrere Plugins lokal geladen werden.

Wichtig ist dabei, dass neben dem Hauptprojekt auch alle Plugins mit diesem Code Block ausgestattet werden. So werden auch transitive Abhängigkeiten wie gewünscht mittels relativem Pfad oder aus dem Repository aufgelöst.

[groovy]
/*
* PPSA PLUGIN CONFIGURATION
*/
def runtimePlugins = [
“:ppsa-menu:latest.release”,
“:ppsa-layout:latest.release”,
]

/* —– BEGIN: no changes past here —– */
def live = System.getProperty(“live”)?System.getProperty(“live”).split(‘,’):[]
def filteredLivePlugins = []
if (live) {
filteredLivePlugins = live.inject([]) { list, lib ->
runtimePlugins.grep { it.contains(lib) } ? list << lib : list
}
if (filteredLivePlugins) {
println “[YOUR_PROJECT_NAME_HERE] Loading some plugins from relative paths in the workspace: ” + filteredLive
filteredLivePlugins.each { pluginName -> grails.plugin.location.”${pluginName}” = “../${pluginName}” }
}
}
/* —– END: no changes past here —– */

grails.project.dependency.resolution = {
plugins {
def filteredRuntimePlugins = runtimePlugins.inject([]) { list, lib ->
filteredLivePlugins.grep { lib.contains(it) } ? list : list << lib
}
if (filteredRuntimePlugins) {
println “[YOUR_PROJECT_NAME_HERE] Loading plugins from release repository: ” + filteredRuntimePlugins
filteredRuntimePlugins.each { pluginDef -> runtime “${pluginDef}” }
}
}
}
[/groovy]

Beispiel, wie man zur live Umgebung für das Plugin ppsa-layout wechseln kann:
[bash]
grails clean -Dlive=ppsa-layout
grails run-app -Dlive=ppsa-layout
[/bash]

Grails Plugins – local and global


With the management of Grails Plugins in a central repository the local further development of plugins could become quite difficult.

With the following Code Block in the  BuildConfig.groovy one or more plugins — sepearted via commas — can be loaded locally instead of from the repository with the help of the command line parameter  -Dlive=....

In order to also resolve transitive dependencies in this way it is important that beside the main project all plugins are also provided with this code block. This way also transitive dependencies can be loaded from a relative path or from the repository.

[groovy]
/*
* PPSA PLUGIN CONFIGURATION
*/
def runtimePlugins = [
“:ppsa-menu:latest.release”,
“:ppsa-layout:latest.release”,
]

/* —– BEGIN: no changes past here —– */
def live = System.getProperty(“live”)?System.getProperty(“live”).split(‘,’):[]
def filteredLivePlugins = []
if (live) {
filteredLivePlugins = live.inject([]) { list, lib ->
runtimePlugins.grep { it.contains(lib) } ? list << lib : list
}
if (filteredLivePlugins) {
println “[YOUR_PROJECT_NAME_HERE] Loading some plugins from relative paths in the workspace: ” + filteredLive
filteredLivePlugins.each { pluginName -> grails.plugin.location.”${pluginName}” = “../${pluginName}” }
}
}
/* —– END: no changes past here —– */

grails.project.dependency.resolution = {
plugins {
def filteredRuntimePlugins = runtimePlugins.inject([]) { list, lib ->
filteredLivePlugins.grep { lib.contains(it) } ? list : list << lib
}
if (filteredRuntimePlugins) {
println “[YOUR_PROJECT_NAME_HERE] Loading plugins from release repository: ” + filteredRuntimePlugins
filteredRuntimePlugins.each { pluginDef -> runtime “${pluginDef}” }
}
}
}
[/groovy]

Example on how to switch to the live environment for the plugin ppsa-layout:
[bash]
grails clean -Dlive=ppsa-layout
grails run-app -Dlive=ppsa-layout
[/bash]

Grails Plugins in eigenem Maven Repository verwalten / Manage Grails Plugins in own Maven Repository

English Version

In diesem Beitrag zeige ich kurz wie man Grails 2 Plugins als Releases in einem eigenen Maven Repository wie Archiva oder Artifactory verwalten kann. Dafür sind grundsätzlich zwei seperate Konfigurationen für Upload und Download vom Repository nötig.

Upload

Für das Releasen neuer Versionen in das eigene Repository bietet Grails 2 das Release Plugin, das man allerdings erst selbst nachinstallieren muss:
[bash]
grails install-plugin release
[/bash]

Die nötige Konfiguration dazu wird in die ~/.grails/settings.groovy ausgelagert. Einträge in dieser Datei gelten für alle Grails Projekte und sind äquivalent zu Einträgen in der BuildConfig.groovy.

Hier ein Beispiel zur Einrichtung von Archiva als Release Repository:
[groovy]
/*
* THIS IS FOR UPLOADING TO THE REPO (via release plugin)
* To use this do:
* grails2 install-plugin release
*/
grails.project.repos.default = “rrzeArchiva”

grails.project.repos.rrzeArchiva.url = “http://REPOSITORY:PORT/archiva/repository/internal/”
grails.project.repos.rrzeArchiva.username = “USERNAME”
grails.project.repos.rrzeArchiva.password = “PASSWORD”

// disable nagging about not having committed all changes…
grails.release.scm.enabled = false
[/groovy]

Das Beispiel Konfiguriert das rrzeArcchiva Repository als Default für Uploads und deaktiviert die SVN Überprüfung für nicht eingecheckte Änderungen.

Fertig.

Neue Releases können dann mit folgenden Build Targets ins Repository geladen bzw. in den lokalen Maven Cache installiert werden.
[bash]
grails maven-deploy
grails maven-install
[/bash]

Download

Für den automatischen Download von Plugins aus dem Repository sind folgende Einträge in der BuildConfig.groovy des Projektes nötig.
[groovy]
grails.project.dependency.resolution = {
repositories {
mavenLocal()
mavenRepo name:”rrzeArchiva”, root:”http://REPOSITORY:PORT/archiva/repository/internal”
}
plugins {
runtime “:ppsa-menu:latest.release”
}
}
[/groovy]

Der Repositories Abschnitt Konfiguriert den lokalen Maven Cache und das Archiva Repository als zu durchsuchende Quellen für Plugin Abhängigkeiten.
Die Plugin Abhängigkeiten selbst werden im eigenen Abschnitt Plugins verwaltet. Der Beispieleintrag lädt immer die aktuellste Version des Plugins ppsa-menu.

Eigentlich würde das nun schon reichen, um Plugins auf dem Repository zu installieren.

Die allermeisten internen Repositories werden jedoch noch zusätzlich eine Authentifizierung erfordern. Hierfür muss noch der folgende Eintrag zur ~/.grails/settings.groovy hinzugefügt werden.
[groovy]
/*
* THIS IS FOR DOWNLOADING FROM THE REPO
* To use this add this to your BuildConfig.groovy:
* mavenRepo name:”rrzeArchiva”, root:”http://REPOSITORY:PORT/archiva/repository/internal”
*/
grails.project.ivy.authentication = {
credentials {
realm = “Repository Archiva Managed internal Repository”
host = “REPOSITORY(ohne Port!)”
username = “USERNAME”
password = “PASSWORD”
}
}
[/groovy]

—- WICHTIG —-

Für Archiva muss der Realm wie angegeben konfiguriert werden. Sonst geht nix!

Außerdem muss der Host hier ohne Port angegeben werden. Wenn das Archiva also z.B. auf Port 8080 läuft ist diese Angabe hier wegzulassen.
—- WICHTIG —-

Managing Grails Plugins in own Maven Repository


 

In this post I will briefly show how to manage Grails 2 Plugins as releases in an own Maven Repository such as Archiva or Artifactory. Therefore basically two separate configurations for Upload and Download from the repository are needed.

Upload

To release new versions in the own repository Graisl 2 offers the Release Plugin, which though must be installed additionally by yourself:
[bash]
grails install-plugin release
[/bash]

The necessary configuration for this is stored in the  ~/.grails/settings.groovy. Entries in this data are valid for all Grails projects and equivalent entries in the BuildConfig.groovy.

Here is an example of installing Archiva as release repository:
[groovy]
/*
* THIS IS FOR UPLOADING TO THE REPO (via release plugin)
* To use this do:
* grails2 install-plugin release
*/
grails.project.repos.default = “rrzeArchiva”

grails.project.repos.rrzeArchiva.url = “http://REPOSITORY:PORT/archiva/repository/internal/”
grails.project.repos.rrzeArchiva.username = “USERNAME”
grails.project.repos.rrzeArchiva.password = “PASSWORD”

// disable nagging about not having committed all changes…
grails.release.scm.enabled = false
[/groovy]

The example configures the rrzeArcchiva repository as Default for Uploads and deactivates the SVN proof for not-checked-in changes.

Done.

New releases can be loaded with the following Build Target in the Repository, respectively installed the local Maven Cache.
[bash]
grails maven-deploy
grails maven-install
[/bash]

Download

For the automatic download of plugins from the repository the following entries in the  BuildConfig.groovy of the project are needed.
[groovy]
grails.project.dependency.resolution = {
repositories {
mavenLocal()
mavenRepo name:”rrzeArchiva”, root:”http://REPOSITORY:PORT/archiva/repository/internal”
}
plugins {
runtime “:ppsa-menu:latest.release”
}
}
[/groovy]

The repository paragraph configures the local Maven Cache and the Archiva Repository as sources for plugin dependencies which have to be browsed.
The plugin dependencies themselves are managed in the own paragraph plugins. The example entry is always loading the most current version of the plugin ppsa-menu.

Actually this would be enough to install plugins on the repository.

Most of all intern repositories will though need further authentication. Therefore the following entry has to be added ~/.grails/settings.groovy.
[groovy]
/*
* THIS IS FOR DOWNLOADING FROM THE REPO
* To use this add this to your BuildConfig.groovy:
* mavenRepo name:”rrzeArchiva”, root:”http://REPOSITORY:PORT/archiva/repository/internal”
*/
grails.project.ivy.authentication = {
credentials {
realm = “Repository Archiva Managed internal Repository”
host = “REPOSITORY(ohne Port!)”
username = “USERNAME”
password = “PASSWORD”
}
}
[/groovy]

—- IMPORTANT —-

For Archiva the realm must be configured as shown. Or nothing will work!

Also, the Host must be stated here without Port. If the Archiva is also running e.g. on Port 8080 these information can be omitted here.
—- IMPORTANT —-

Log4j Appender mit automatischem Zip-nach-Rotate

English version

Um Pattenplatz bei der Benutzung von Log4j zu sparen wurden zwei alternative Appender implementiert die neben der üblichen Rotation der Logdatei, diese auch gleich mittels zip komprimiert.

Die beiden Appender Klassen sind entsprechend ihren Pendants auf die Namen DailyRollingZipAppender und RollingZipAppender getauft und im repo unter ppsa-log4j-zip zu finden.
Beide Klassen erweitern die ursprünglichen Appender Implementierungen und können deshalb 1:1 ohne zusätzlichen Konfigurationsaufwand ausgetauscht werden.

Um eine Logdatei beim rotieren automatisch zu zippen müssten zum Beispiel folgende Anpassungen vorgenommen werden:

     <appender name="FILE" class="org.jboss.logging.appender.DailyRollingFileAppender">

ersetzen durch

     <appender name="FILE" class="de.rrze.ppsa.log.DailyRollingZipAppender">

Außerdem muss die ppsa-log4j-zip-0.0.1.jar im Classpath liegen.

Die Implementierung wurde inspiriert von einem Blogbeitrag auf ralfhaug.de.

Log4j appender with automatic zip-after-rotate

In order to save precious disc space when using Log4j, we developed to alternative appender implementations with zip functionality. In addition to the usual rotation of the log files, these appenders also compress the rotated logs using the zip algorithm.

The two appender classes are named after their respective counterparts: DailyRollingZipAppender and RollingZipAppender. They are available in our repo under ppsa-log4j-zip.
Both classes extend the oiginal appender implementations and can be used as plug-in replacements without any additional configuration.

An example configuration to automatically zip a logfile after rotate would be done something like this:

     <appender name="FILE" class="org.jboss.logging.appender.DailyRollingFileAppender">

must just be replaced with

     <appender name="FILE" class="de.rrze.ppsa.log.DailyRollingZipAppender">

Additionally the ppsa-log4j-zip-0.0.1.jar has to be in the classpath.

The implementation was inspired by this blog entry on ralfhaug.de.

Inkscape und Datenschutz jetzt auch mit dem RRZE Icon Inspector

English Version

An den letzten Artikel anknüpfend kann nun auch der RRZE Icon Inspector die etwas zu gesprächigen XML Tags aus den Inkscape SVGs entfernen.

Nach Vorlage von Sebastian Pippings svgstrip werden bei jedem Lauf die Attribute ‘sodipodi:absref’, ‘sodipodi:docbase’, ‘sodipodi:docname’ im SVG-Tag, sowie das Attribut ‘inkscape:export-filename’ aus allen Tags entfernt.

Datenschutz wieder hergestellt 😉

Inkscape and Data security with the RRZE Icon Inspector

Picking up where the last article left off, the RRZE Icon Inspector is now able to remove the rather “talkative” XML Tags from Inkscape’s SVG files.

Using Sebastian Pippings svgstrip template, attributes ‘sodipodi:absref’, ‘sodipodi:docbase’, ‘sodipodi:docname’ are removed from the SVG-Tag, and attribute ‘inkscape:export-filename’ is removed from all tags..

Welcome back, Data security! 😉

Icon Inspector / GTK Icon Inspector

English Version

Neues Verwaltungstool für Icon-Sammlung

Zusätzlich zu dem vom Regionalen Rechenzentrum Erlangen (RRZE) der Friedrich-Alexander-Universität entworfenen eigenen Icon-Satz, der zur freien Nutzung im Internet angeboten wird, gibt es nun auch einen sogenannten Icon Inspector, der die kleinen "Bildchen" verwaltet.

Unter der Haube des Icon Inspectors steckt weit mehr, als mit der ursprünglich geplanten einfachen Icon-Übersicht für das RRZE Icon Set Projekt geplant war. Neben einer ansprechenden, tabellarischen Aufbereitung der zur Verfügung gestellten Symbole, inklusive alphabetischem Index und Ankern zur direkten Verlinkung wartet der Icon Inspector mit zahlreichen nützlichen Funktionen auf. So behält er zum Beispiel den Inhalt und Aufbau der Ordnerstruktur im Auge, um die Icon-Designer bei ihrer Arbeit und der Einhaltung der Icon Set Richtlinien zu unterstützen. Darüber hinaus wird bei jedem Inspektionslauf überprüft, ob jedes Icon in allen benötigten Skalierungsgrößen vorhanden ist und welche skalierten Icons nicht als skalierbare Vektorgrafik (Scalable Vector Graphics, kurz SVG) vorliegen, was meist auf Tippfehler schließen lässt. Außerdem kontrolliert der Icon Inspector, ob die Metadaten der Inkscape-SVG-Dateien existieren und den Vorgaben entsprechen und ob alle Bilddateien korrekt in die Ordnerstruktur eingeordnet wurden.

Ermittelte Probleme werden in einer Logdatei protokolliert und lassen sich dann nacheinander beheben. Um fehlende Skalierungsgrößen automatisch aus den Scalable Vector Graphics zu generieren, kann sich der Icon Inspector auf Wunsch eines installierten Inkscapes bedienen. Damit wird Entwicklern das eintönige "Durchskalieren" jedes neu erstellten Icons erspart. Darüber hinaus ist der Icon Inspector bereits in der Lage, mit mehreren Detailstufen ein und desselben Icons umzugehen. Für den problemlosen Einsatz mit gängigen Versionsverwaltungstools werden Nicht-Bilddateien und hier insbesondere versteckte SVN- und CVS-Verzeichnisse vom Icon Inspector standardmäßig ignoriert.

Der komplett in PHP programmierte Icon Inspector kann mittels mitgelieferter Startskripte einfach von der Kommandozeile aufgerufen werden. Die Konfiguration erfolgt wahlweise über Kommandozeilenparameter, eine config.php-Konfigurationsdatei oder beim Einsatz der GIMP-Toolkits direkt in der grafischen Oberfläche.

Weitere Informationen

Kontakt

Florian Löffler
Stabsstelle Projekte & Prozesse
florian.loeffler@rrze.uni-erlangen.de

New Icon manager for Icon collection

In addition to the Icon set created by the Friedrich-Alexander-University’s Regional Computing Centre Erlangen, which is freely available for use, there is now the Icon Inspector to manage all the little "pictures".

The Icon Inspector manages a lot more than what was originally planned, i.e. a simple icon overview for the RRZE Icon Set Project. In addition to an attractive, tabular view of the available symbols with alphabetic indec and anchors for direct links, the Inspector has several other useful functions. It keeps an eye on your folders content and structure, to make it easier for icon designers to keep to the Icon Set guidelines. It also tests availability of the necessary scaling sizes with every inspection run, and notes which icons are not available as scalable vector graphics. It also checks if metadata for Inkscape SVG files is available and in keeping with the guideline, and whether the picture files are in their correct folder.

Any uncovered problems are saved in a log file and can then be dealt with. To generate missing sizes, the Icon Inspector is able to use an installed version of Inkscape if wanted. This saves developers from the boring work of "Scaling" every single new icon. Furthermore, the Inspector is able to deal with several levels of detail for every icon. To make use with subversion tools easier, non-picture files and especially hidden SVN and CVS folders are generally ignored.

Icon Inspector has been programmed in PHP completely and can be run from the commandline using the start scripts that come with it. Configuration can be done either via commandline parameter, a config.php configuration file or directly in the graphic interface when using the GIMP toolkit.

Further Information

Contact

Florian Löffler
Stabsstelle Projekte & Prozesse
florian.loeffler@rrze.uni-erlangen.de