DEFREN

Login und Suche



CH Open Sponsoren

Hürlimann Informatik AG - /ch/open-Sponsor

Continuous Integration mit JavaScript GUI

04.09.2015 | von Christoph Raaflaub

Es gibt immer mehr JavaScript GUI’s zu Java Backends. Sie haben jedoch ganz unterschiedliche Build-Management Tools. Java Entwicker benutzen oft Apache Maven und JavaScript Entwickler Grunt, um den Build der Applikation zu konfigurieren und automatisieren.

In einem Java Backend werden beim Build zuerst die Abhängigkeiten zu anderer Software über Maven-Repositories aufgelöst und die benötigten Third-party Libraries heruntergeladen. Danach wird die Applikation kompiliert, getestet und für den Deploy auf dem Appliktions-Server in WAR- oder EAR-Dateien gepackt.

Für ein JavaScript Frontend werden beim Build auch Abhängigkeiten aufgelöst und eingebunden. Der Build beinhaltet weitere Schritte wie:

  •  holt third-party JavaScript Tools
  •  JavaScript und CSS Dateien überprüfen
  •  Unit-Tests durchführen
  •  JavaScript und CSS Dateien minifizieren
  •  Alle benötigten Dateien für die Applikation zusammenstellen

Wie bringen wir jedoch diese zwei Welten unter einen Hut? Wie können wir mit einem einzigen Befehl die ganze Applikation, also Backend und Frontend, für den Deploy Builden?

  1. Lösung: Alle Build Tasks von Grunt werden mit Maven gemacht
  2. Lösung: In Maven ein Grunt Plugin verwenden, welches die bestehende JavaScript Build Konfiguration verwendet
  3. Lösung: Der Build wird mit Gradle und einem Grunt Plugin gemacht

Die dritte Lösung verbindet die zwei Welten, ohne dass eine benachteiligt wird. Darum und weil Gradle weniger verbereitet ist als Maven, werde ich hier tiefer auf sie eingehen.

CI mit Gradle-Grunt Plugin

Wer bereits Gradle benutzt, kann das gradle-grunt Plugin verwenden. Dort stehen Gradle alle Grunt Tasks zur Verfügung. Sie haben alle den Prefix “grunt_”. Das Plugin leitet die Aufrufe an das installierte Grunt weiter. Somit muss nicht ein Execute-Task definiert werden. Als Beispiel wird der Grunt test Task so über Gradle benutzt:

$ gradle grunt_test

Für Continuous Integration beider Bereiche können die Tasks in Abhängigkeit gebracht werden. Dafür muss folgendes im Gradle Buildfile konfiguriert werden. Das Gradle Buildfile entspricht der Maven POM-Datei.

clean.dependsOn grunt_clean build.dependsOn grunt_build test.dependsOn grunt_test

Damit werden z.B. bei einem Build das Backend kompiliert und das Frontend gebildet. Dazu einfach

$ gradle build

aufrufen.

Mit dem WAR Task kann die ganze Applikation in eine WAR-Datei für den Deploy auf dem Application-Server gepackt werden. Hier die Konfiguration im Gradle Buildfile, um die Frontend-Dateien in die WAR-Datei zu integrieren.

apply plugin: 'war' //--> Web Application Plugin war { from 'dist' //--> Fügt Frontend Dateien in den Root-Ordner vom Archiv ein //--> weitere Konfiguration für das Erstellen vom Archiv } war.dependsOn grunt_build //--> Vor dem Archiv erstellen muss das Frontend gebildet werden

 

Anmerkung: So wird das gradle-grunt Plugin im Grade Buildfile aktiviert.

 

plugins { id "com.moowork.grunt" version "0.10" }

Für die Installation von node und npm müssen die Versionen im Gradle Buildfile definiert werden.

node { // version of node version = '0.12.7' // version of npm npmVersion = '2.13.4' // enable the automatic download download = true }

Build nach Gradle wechseln

Für Maven Benutzer gibt es Unterstützung, um zu Gradle zu Migrieren, den init Task:

$gradle init

Damit werden von einen bestehenden Maven Build die Konfiguration für Gradle erstellt. Da Gradle auch Maven Repositories verwendet, werden die Abhängigkeiten übernommen. Applikationen mit mehreren Projekten und hierarchischen Abhängigkeiten dazwischen werden richtig abgebildet.
Beim Übernehmen der Abhängigkeiten kann es jedoch vorkommen, dass Library Versionen nicht 100%-ig klar sind. Dazu wird ein Kommentar in das Buildfile geschrieben.

compile(group: 'org.hibernate.javax.persistence', name: 'hibernate-jpa-2.0-api', version:'1.0.1.Final-redhat-2') { /* This dependency was originally in the Maven provided scope, but the project was not of type war. This behavior is not yet supported by Gradle, so this dependency has been converted to a compile dependency. Please review and delete this closure when resolved. */ }

Um die Abhängigkeiten sichtbar zu machen, gibt es analog zum Maven’s “$mvn dependency:tree” den Befehl “$gradle dependencies”.

compile - Compile classpath for source set 'main'. +--- joda-time:joda-time:2.4 +--- org.jadira.usertype:usertype.core:3.2.0.GA | +--- org.slf4j:slf4j-api:1.7.6 | \--- org.jadira.usertype:usertype.spi:3.2.0.GA | \--- org.slf4j:slf4j-api:1.7.6 +--- org.jboss.spec.javax.faces:jboss-jsf-api_2.1_spec: 2.1.19.1.Final-redhat-1 +--- javax.enterprise:cdi-api:1.0-SP4.redhat-3 | +--- org.jboss.spec.javax.interceptor:jboss- interceptors-api_1.1_spec:1.0.0.Beta1 | +--- org.jboss.spec.javax.annotation:jboss- annotations-api_1.1_spec:1.0.1.Final | \--- javax.inject:javax.inject:1 +--- org.jboss.spec.javax.ejb:jboss-ejb-api_3.1_spec: 1.0.2.Final-redhat-2 +--- org.hibernate.javax.persistence:hibernate-jpa-2.0-api: 1.0.1.Final-redhat-2 +--- org.jboss.spec.javax.ws.rs:jboss-jaxrs-api_1.1_spec: 1.0.1.Final-redhat-2 +--- org.hibernate:hibernate-validator:4.3.1.Final-redhat-1 | +--- javax.validation:validation-api:1.0.0.GA-redhat-2 | \--- org.jboss.logging:jboss-logging:3.1.2.GA-redhat-1 \--- org.hibernate:hibernate-entitymanager:4.2.7. SP1-redhat-3 +--- xml-resolver:xml-resolver:1.2.redhat-9 +--- org.jboss.logging:jboss-logging:3.1.2.GA-redhat-1 +--- org.jboss.spec.javax.transaction:jboss-transaction-api _1.1_spec:1.0.1.Final-redhat-2 +--- org.hibernate:hibernate-core:4.2.7.SP1-redhat-3 | +--- xml-resolver:xml-resolver:1.2.redhat-9 | +--- org.jboss.logging:jboss-logging:3.1.2.GA-redhat-1 | +--- org.jboss.spec.javax.transaction:jboss- transaction-api_1.1_spec:1.0.1.Final-redhat-2 | +--- antlr:antlr:2.7.7.redhat-4 | +--- org.hibernate.javax.persistence:hibernate-jpa- 2.0-api:1.0.1.Final-redhat-2 | +--- org.hibernate.common:hibernate-commons-annotations: 4.0.1.Final-redhat-2 | | \--- org.jboss.logging:jboss-logging:3.1.2.GA-redhat-1 | +--- dom4j:dom4j:1.6.1.redhat-6 | \--- org.javassist:javassist:3.18.1-GA-redhat-1 +--- org.hibernate.javax.persistence:hibernate-jpa-2.0-api: 1.0.1.Final-redhat-2 +--- org.hibernate.common:hibernate-commons-annotations: 4.0.1.Final-redhat-2 (*) +--- dom4j:dom4j:1.6.1.redhat-6 \--- org.javassist:javassist:3.18.1-GA-redhat-1

Wenn es unerwünschte Abhängigkeiten gibt, können sie aus dem Build ausgeschlossen werden. Vor allem dann, wenn sie mit anderen Version der gleichen Library Konflikte machen.

compile(group: 'org.jadira.usertype', name: 'usertype.core', version:'3.2.0.GA') { exclude(module: 'hibernate-entitymanager') }

Danach die gewünschte Version einbinden:

compile group: 'org.hibernate', name: 'hibernate-entitymanager', version:'4.2.7.SP1-redhat-3'

Auch Apache-Ant Benutzer können den Init Task von Gradle benutzen, um ihren Build Prozess zu Migrieren. Weiter gibt es die Möglichkeit, Ant Buildfiles in Gradle einzubinden und die enthaltenen Tasks mit Gradle auszuführen.
Einbinden:

ant.importBuild 'build.xml'

Die Tasks haben danach den gleichen Namen wie bei Ant. Wenn der Task-Name jedoch bereits durch ein Gradle Plugin besetzt ist, gibt es Probleme. Die können jedoch einfach mit einem Umbenennen der Ant Tasks aufgehoben werden.

Continuous Deployment Pipeline

Wenn diese Automation vom ganzen Build steht, also Backend und Frontend zusammen gebaut und getestet werden, ist Continuous Integration bereit.
Ein nächster Schritt ist die Automatisierung vom Deploy der Applikation für das Continuous Deployment.

Wenn diese Grundlagen bereit sind, kann eine Deployment Pipeline gebaut werden.

Verweis: Gradle Dokumentation



Weiterführende Informationen aus dem OSS Directory

Puzzle ITC GmbH

puzzle.ch | 115 Mitarbeitende | 12 Referenzen | 1 Produkt


Puzzle ITC ist spezialisiert auf interdisziplinäre Lösungen vom Betriebssystem bis zur Anwendung für Endbenutzer - zugeschnitten auf Ihre Bedürfnisse.
Im Jahr 1999 als Software- und ...

» Mehr
Letzte Aktualisierung: 14.09.2018  -  Anzahl Ansichten seit dem 01. April 2013: 1605
Erstellt: 29.09.2012

Twitter Feed







Links

Über unsNewsletterKontaktNutzungsbedingungenCH Open Initiativen