Hans Dockter mit The Future of Gradle – The Ultimate Build System bei uns am 7.7. um 18 Uhr

Gemeinsam mit der Java Usergroup Berlin-Brandenburg präsentieren wir am 7. Juli den Vortrag von Hans Dockter The Future of Gradle – The Ultimate Build System. Einlaß ist um 18:00 Uhr. Der Vortrag beginnt um 18:30 Uhr.

gradleware

Vortrag: The Future of Gradle – The Ultimate Build System

We are convinced that Gradle is already the best available enterprise build system. Yet we are far from done. We have finally the R&D bandwidth to deeply improve Gradle in the areas where it lacks. We also have the bandwidth to contribute some fundamental innovation to the domain of build and continuous delivery. All this will bring Gradle much closer to our vision of Gradle being the ultimate build system.

We start by giving an overview of where Gradle is currently in the build system market when it comes to features and adoption. We will then talk about the next generation multi-platform dependency management. A dependency management that can fully capture the requirements of Android, JavaScript and the native domain as well as to improve the dependency management for the Java world. We will talk about how Gradle will dramatically improve the performance by introducing global caches and other optimizations. Finally we will talk about the new Gradle extendability model and its upcoming native and JavaScript support.

Der Vortrag wird je nach Wunsch in englisch oder deutsch gehalten.

Redner: Hans Dockter

Hans Dockter is the founder of Gradle and Gradleware. Hans has 13 years of experience as a software developer, team leader, architect, trainer, and technical mentor in vast array of industry sectors such as automotive, finance, public transport and business intelligence. Hans is a thought leader in the field of project automation and has successfully been in charge of numerous large-scale enterprise builds. He is also an advocate of Domain Driven Design, having taught classes and delivered presentations on this topic together with Eric Evans.

Treffpunkt

Hypoport AG, Klosterstr. 71, 10179 Berlin, am 7.7. um 18 Uhr

Anmeldung

Über eine Vorabanmeldung zur Veranstaltung über das XING-Event der XING-Gruppe der JUG Berlin-Brandenburg würden wir uns freuen, jedoch ist die Anmeldung nicht zwingend erforderlich.

Wir freuen uns auf euch.

Apache RewriteRule – Rewriting URLs With Already Encoded QueryStrings

Recently we renamed a URL which was publically available. The system uses Apache httpd, so it was quiet easy to create a RewriteRule:

RewriteRule ^/oldname/(.*) /newname/$1 [R,L]

Unfortunately that didn’t work as expected. A URL like myserver/oldname?myprop=name with spaces will be encoded to myserver/oldname?myprop=name%20with%20spaces. With the above RewriteRule the rewritten URL will be myserver/oldname?myprop=name%2520with%2520spaces. It got encoded two times!.

To fix this, you need the right keywords and Google. Searching for mod_rewrite url encode revealed that adding the NE flag (for No Encoding) does the trick:

RewriteRule ^/oldname/(.*) /newname/$1 [R,NE,L]

Developing with TeamCity 7.1: from remote run to feature branches – Pavel Sher and Dmitry Neverov at Hypoport on Feb 18th

Gemeinsam mit der Java Usergroup Berlin-Brandenburg präsentieren wir am 18. Februar den Vortrag von Pavel Sher und Dmitry Neverov Developing with TeamCity 7.1: from remote run to feature branches. Einlaß und Zeit für Networking startet ab 18:30 Uhr. Der Vortrag beginnt um 19:00 Uhr.

Abstract
Continuous integration tools play important role in software development these days. In an ideal world every commit in version control system must be checked by running a build on it, builds must be fast and broken builds must be fixed quickly. But we do not live in the ideal world, so how we can protect ourselves from breaking changes? How we can minimize effects of breaking changes on our teammates?

This talk covers effective ways of using TeamCity, a CI server from JetBrains, with different version control systems. You will see how to commit only a verified code with help of pre-tested commits, how to use personal branches if you’re using Git or Mercurial, and how to implement your favorite DVCs workflow using TeamCity feature branches support.

Speaker

Dmitry Neverov – software developer in TeamCity project. Dmitry works in JetBrains for almost 3 years and his responsibilities include wide range of tasks related to distributed version control systems, from integration with Git and Mercurial to feature branches support in TeamCity core.

Pavel Sher – senior software developer and project manager in TeamCity. Pavel started working on TeamCity almost from the beginning, 7 years ago. As such he took part in many aspects of TeamCity functionality and is responsible for many architectural decisions in TeamCity core.

Anmeldung
Anmeldung erfolgt wie üblich über die Xing JUG BB Event-Einladung.

Tipp
Zusätzlich zu dem Vortrag gibt’s noch ein Goodie von Jetbrains:) Lasst euch überraschen!

jb

Unit- und Integration-Test eines MicroService mit Maven

Was ist ein MicroService? In unserem Kontext ist es ein (kleines) Modul der Gesamtanwendung, welches seinen Dienst als Webapplikation (.war) anbietet. Das konkrete Schnittstellen-Protokoll ist für diesen Artikel nicht entscheidend. Möglich ist klassisch SOAP, REST aber auch Spring HttpInvoker. Ein MicroService ist eine gute Möglichkeit Sollbruchstellen in die Gesamtanwendung einzubauen.

Nun zum eigentlichen Thema: Wie teste ich einen solchen Service? Im Grunde wie immer, d.h. viele Unit-Tests und ein paar ausgewählte Integration-Tests. Die Integration-Tests sollen zeigen, dass die angebotenen Schnittstellen des Services funktionieren und alles richtig konfiguriert ist. Die Integration-Tests, die die Gesamtanwendung, d.h. das Netz aller Services testet, ist hier nicht Bestandteil.

Wie macht man das jetzt mit Maven? Eine Variante ist die Unit-Tests und Integration-Tests zu trennen. Vor der integration-test Phase einen Tomcat zu starten, dann seine Integration-Tests auszuführen und anschließend wieder den Tomcat zu stoppen. Tomcat, weil wir diesen nicht nur lokal einsetzen und somit “gleicher” zur Produktion sind. Eine echte Plugin-Auswahl fand nicht statt, wir sind einfach mit dem tomcat7-maven-plugin gestartet.

Mit Maven Tomcat automatisch starten und stoppen

  <build>
    <plugins>
      ..
      <plugin>
        <groupId>org.apache.tomcat.maven</groupId>
        <artifactId>tomcat7-maven-plugin</artifactId>
        <version>2.0-beta-1</version>
        <configuration>
          <contextFile>${project.basedir}/src/test/resources/test-context.xml</contextFile>
        </configuration>
        <executions>
          <execution>
            <id>tomcat-run</id>
            <goals>
              <goal>run-war-only</goal>
            </goals>
            <phase>pre-integration-test</phase>
            <configuration>
              <fork>true</fork>
            </configuration>
          </execution>
          <execution>
            <id>tomcat-shutdown</id>
            <goals>
              <goal>shutdown</goal>
            </goals>
            <phase>post-integration-test</phase>
          </execution>
        </executions>
      </plugin>

    </plugins>
  </build>

Das Starten des Tomcats binden wir an die pre-integration-test Phase (Zeile 17). Wichtig ist fork auf true zu setzen (Zeile 19), da sonst Maven nach Start des Tomcats stehen bleibt. Das Beenden binden wir entsprechend an die post-integration-test Phase (Zeile 27). Wenn keine context.xml in der webapp enthalten ist, muss eine per contextFile angeben werden (Zeile 9).

So, unser Tomcat startet und stoppt nun beim Ausführen von mvn integration-test.

Mit Maven innerhalb eines Modules Unit- und Integration-Tests trennen

Nächster Schritt ist die Unit- und Integration-Tests zu trennen. Im Netz empfehlen einige dies in separaten Maven-Modulen zu tun. Wir finden es sinnvoller dies über die Test-Phasen zu steuern:

  <build>
    <plugins>
      ..
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-surefire-plugin</artifactId>
        <configuration>
          <skip>true</skip>
          <trimStackTrace>false</trimStackTrace>
        </configuration>
        <executions>
          <execution>
            <id>unit-tests</id>
            <phase>test</phase>
            <goals>
              <goal>test</goal>
            </goals>
            <configuration>
              <skip>false</skip>
              <includes>
                <include>**/*Test.java</include>
              </includes>
              <excludes>
                <exclude>**/*IntegrationTest.java</exclude>
              </excludes>
            </configuration>
          </execution>
          <execution>
            <id>integration-tests</id>
            <phase>integration-test</phase>
            <goals>
              <goal>test</goal>
            </goals>
            <configuration>
              <skip>false</skip>
              <includes>
                <include>**/*IntegrationTest.java</include>
              </includes>
            </configuration>
          </execution>
        </executions>
      </plugin>

    </plugins>
  </build>

In Zeile 8 wird das Default-Test-Verhalten vom maven-surefire-plugin ausgeschaltet. Durch zwei einzelne <execution/>'s können wir unterschiedliche <configuration/>'s an unterschiedliche Phasen binden (Zeile 14 und 30). In der test Phase werden alle Klassen mit Endung Test.java ausgeführt außer jene mit Endung IntegrationTest.java. In der integration-test Phase werden nun lediglich alle Klassen mit Endung IntegrationTest.java ausgeführt. Vielen Dank an HDave, der letzteres auf Stackoverflow schön erklärt.

Hast du ähnliche Anwendungsfälle? Wie hast du diese gelöst?

Oliver Gierke von SpringSource kommt am 14. Juni 2012 nach Berlin

Gemeinsam mit der Java Usergroup Berlin-Brandenburg präsentieren wir am 14. Juni den Vortrag von Oliver Gierke Huch, wo ist meine Architektur hin?. Einlaß und Zeit für Networking startet ab 18:30 Uhr. Der Vortrag beginnt um 19:00 Uhr.

Vortrag
Wenn Applikationen über eine bestimme Größe oder einen bestimmten Zeitraum hinaus wachsen wird Modularität ein Kernaspekt für Wartbarkeit. Designentscheidungen die getroffen wurden sind kaum noch im Code wiederzufinden, Abhängigkeiten zwischen einzelnen Modulen der Applikation wachsen oft wild. Der Vortrag Patterns und Best Practices rund um generelle Code-Organisation und Package-Strukturen vor um eine solide Grundlage für langlebige Java-Applikationen zu legen, sowie eine möglichkeit mit Spring lose gekoppelte Komponenten und dedizierte Erweiterungspunkte in Applikationen zu definieren und zu verwenden.

Speaker
Oliver Gierke ist Teil des Spring Data Teams bei SpringSource, a division of VMware und leitet dort das JPA, MongoDB und Core Modul. Seit über 6 Jahren widmet er sich dem Entwicklen von Java Enterprise Applikationen, Open Source Projekten und ist Mitglied der JPA 2.1 Expert Group. Seine Arbeitsschwerpunkte liegen im Bereich Softwarearchitektur, Spring und Persistenztechnologien. Er ist regelmäßiger Sprecher auf deutschen und internationalen Konferenzen sowie Autor von Fachartikeln.

Sonar Analyse eines Maven Projektes mit Cobertura und AspectJ

Wir verwenden unter anderem Sonar, um unsere Codequalität zu analysieren. Sonar bietet viel Spannendes. Interessant ist auch die Analyse der Testabdeckung. Hierzu kann man Cobertura verwenden. Im Zusammenspiel mit einem Projekt, welches AspectJ einsetzt kann es zu Problemen kommen, wenn man versucht das Kompilieren der Anwendung mit der Sonar-Analyse zu kombinieren.


mvn clean install sonar:sonar -Dmaven.test.failure.ignore=true

Die Lösung liegt wie so oft in RTFM. Der empfohlene Weg eine Sonar-Analyse durchzuführen ist es zuerst die Anwendung zu bauen und danach die Analyse zu starten.


mvn clean install -Dtest=false -DfailIfNoTests=false
mvn sonar:sonar

Wichtig ist hierbei beim Bauen der Anwendung die Tests auszuschalten, da diese in der Sonar-Analyse laufen und man sonst unnützerweise zwei Testläufe hat.

Nun können wir uns die Testabdeckung der einzelnen Module ansehen.

Hibernate4 verwendet jboss-logging statt slf4j. Durch die log4j Bridge leiten wir die Logs zu logback.

Bei der Migration auf Hibernate 4 haben wir festgestellt, dass Hibernate statt wie bisher slf4j nun ihre eigene Logging API jboss-logging verwendet. Glücklicherweise logt diese API standardmäßig auf log4j. Durch Einsatz der log4j-over-slf4j Bridge lenken wir die Logs wieder auf slf4j, um sie dann per logback zu loggen.

Es ist wichtig bei der Nutzung dieser Bridge keine log4j.jars im Klassenpfad zu haben! Es dürfen kein direkten oder transitiven log4j.jar Abhängigkeiten mehr existieren. Mit maven kann das leicht über ein mvn dependency:tree geprüft werden. Das exclude erfolgt dann beispielhaft so:

    <dependency>
      <groupId>sample.groupId</groupId>
      <artifactId>sample.artifactId</artifactId>
      <scope>compile</scope>
      <exclusions>
        <exclusion>
          <groupId>log4j</groupId>
          <artifactId>log4j</artifactId>
        </exclusion>
      </exclusions> 
    </dependency>

Podcast und Slides von Chris Chedgey’s Talk Restructuring: Improving the modularity of an existing code-base

Chris hat uns dankenswerter Weise die Tonaufnahme und die Folien zur Verfügung gestellt.

Die Slides sind aktualisiert und enthalten Beispiele der Restructuring Strategies! Schaut sie euch ruhig noch mal an.

Berlin Expert Days mit 4 Vorträgen unserer Mitarbeiter

Die Berlin Expert Days 2012 haben ein sehr interessantes Programm. Neben bekannten Speakern erhalten auch weniger bekannte Speaker die Gelegenheit sich und Ihre Erfahrungen zu präsentieren. U.a. gibt es 4 Vorträge von Hypoport Mitarbeitern:

Verena Würfel, eine freie Mitarbeiterin, präsentiert sich mit Was Frankenstein und Anwendungen gemeinsam haben.

Chris Chedgey von Headway Structure101 kommt am 6. März 2012 nach Berlin

Gemeinsam mit der Java Usergroup Berlin-Brandenburg präsentieren wir am 6. März den Vortrag von Chris Chedgey Restructuring: Improving the modularity of an existing code-base. Einlaß und Zeit für Networking startet ab 18:30 Uhr. Der Vortrag beginnt um 19:00 Uhr.

Vortrag
When a code-base reaches a certain age, it starts to creak, grind, rot. It seems like everything uses everything. Developers do not understand the big picture and start duplicating or creating parallel worlds of design, making things even worse. Architects are uneasy and sleep badly. Managers notice how long it takes to get new features into the product, and to get the bugs out of incremental releases, and they make sure nobody sleeps well. Now is the time for the code-base to be restructured, or die a painful death.

This talk covers the most common structural problems, gives strategies for fixing them with minimal impact to the logical design, and shows how this reduces coupling and complexity, improves modularity, and can be used to establish an architecture that the whole team understands and that helps the developers as they edit the code. In other words, how to stop the rot, and keep it stopped.

The principles and strategies will be illustrated by examples.

Speaker
Chris is a founder of Headway Software (Structure101). He has an MSc. in Computer Science from Trinity College Dublin. He has 28 years of experience in commercial software development, notably on large military and aerospace projects in Canada, including 5 years on the International Space Station project. He has 2 lovely daughters in college and lives on the south coast of Ireland, with a big dog, 2 goats and a boa constrictor.

Anmeldung
Anmeldung erfolgt wie üblich über die Xing JUG BB Event-Einladung.

Tipp
Zusätzlich zu dem Vortrag wird noch eine Lizenz für Structure101 und eine Lizenz für Restructure101 verlöst. Wir drücken dir die Daumen:)


Meeting sponsored by Structure101 for Tangle free software