everflux

GridGain 2.1 hat neben einer Menge neuer Features und Bugfixes nun auch ein eigenes Maven Repository bekommen (und die Abhängigkeiten wurden gemäß der normalen Namenskonvention benannt).

Das bedeutet, dass nun mittels Maven GridGain Projekte reproduzierbar gebaut werden können, und kein lokales Deployment der GridGain Artefakte mehr nötig ist. (Vor allem für den Einsatz von Continuous Integration Server und offsite Builds relevant)

Dazu wird einfach das GridGain Repository in der pom.xml angegeben, und eine Abhängigkeit auf GridGain definiert:

                <dependency>
                        <groupId>org.gridgain</groupId>
                        <artifactId>gridgain</artifactId>
                        <version>2.1.0</version>
                </dependency>

Und das GridGain Maven Repository:

        <repositories>
                <repository>
                        <id>gridgain</id>
                        <url>http://www.gridgainsystems.com/maven2/</url>
                </repository>
        </repositories>

Speicher ist immer zu knapp – das ist nichts neues. Aus Zeiten als 64MB noch recht viel waren, stammt der Default Wert für eine Java VM: 64MB für den Heap, da muss die Applikation reinpassen.

Normalerweise stellt man (mittels -Xmx) eine entsprechend größere Heap Größe für die Java VM ein, insbesondere für Applikationsserver. Einen Sonderfall des „out of memory error“ ist der „GC overhead limit exceeded“ Fehler. Dieser wird dann erzeugt, wenn der Garbage Collector zu viel Zeit damit zu bringt, Speicherplatz frei zu räumen, und die Applikation nicht mehr dazu kommt, zu arbeiten. (GC Dokumentation)

Abhilfe schafft hier ebenfalls ein größerer Heap Space für die JVM, bzgl. ein Profiling der Applikation, um Speicherlecks zu finden. (Wird eine Applikation per Maven-jetty-Plugin testweise gestartet, wird hier übrigens keine separate JVM gestartet, sondern die von Maven weiter verwendet. Damit hilft hier MAVEN_OPTS entsprechend zu konfigurieren.)

Das Spring Framework, gerade besonders (un)populär aufgrund von Lizenzänderungen des Herstellers SpringSource, ist für viele Java Enterprise Anwendungen Infrastrukturgrundlage.

Sei es für Dependency Injection, AOP, JDBC Templates oder Vereinfachung von Remoting – die Spring API macht nach erster Eingewöhnung die Arbeit wesentlich einfacher und vereinheitlicht die Nutzung verschiedener Technologien. Doch was, wenn man eine Snapshot Version verwenden möchte? Netterweise gibt es neben „selbst gebaut“ noch die Alternative eines bei Amazon S3 gehosteten Snapshot Repositories für Maven, wie man aus dem SpringSource Blog erfährt.

Das ganze funktioniert so, Maven Repositories um einen Eintrag ergänzen, Spring Version auf x.y.z-SNAPSHOT (z.B. 2.5.6-SNAPSHOT) setzen und den Rest erledigt Maven. Danke SpringSource, danke Maven!

So sieht der SpringFramework Snapshot Repository Eintrag im Maven dann aus:

<repository>
<id>spring-snapshot</id>
<name>Spring Portfolio Snapshot Repository</name>
<url>http://s3.amazonaws.com/maven.springframework.org/snapshot</url>
</repository>


Maven (bzw. Maven2) verfügt bekanntlich über expliziten Support für Module, die sich sehr einfach über ein parent pom konfigurieren lassen.

Sehr häufig findet sich in Foren und Newsgroups das „Problem“ dass das mvn site Kommando eine „falsche“ Verlinkung erzeugt. Das ist nicht ganz richtig – die Verlinkung stimmt, sobald man die Seite auch „deployt“, also in das endgültige Verzeichnis (auf einem Webserver) befördert. Weiterlesen »