Use maven profile to recompile vaadin widgetset #2

In a older post I describe my solution to handle VAADIN/GWT widgetset compilation with maven.

Today I  will share some changes to use GWT 2.4 with my solution.

The problem: after GWT compilation a new directory gwt-unitCache exists under the VAADIN directory. I don’t need this

I integrate this workaround in my profile:

<profile>
  <!-- Updates Vaadin widgetset definitions based on project dependencies -->
  <id>update-widgetset</id>
  <activation>
    <file>
      <missing>${basedir}/src/main/webapp/VAADIN/widgetsets/</missing>
    </file>
  </activation>
  <build>
    <plugins>
      <plugin>
        <groupId>com.vaadin</groupId>
        <artifactId>vaadin-maven-plugin</artifactId>
        <version>1.0.2</version>
        <executions>
          <execution>
            <phase>generate-resources</phase>
            <goals>
              <goal>update-widgetset</goal>
            </goals>
          </execution>
        </executions>
      </plugin>
      <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>gwt-maven-plugin</artifactId>
        <version>2.4.0</version>
        <configuration>
          <webappDirectory>${basedir}/src/main/webapp/VAADIN/widgetsets/</webappDirectory>
          <extraJvmArgs>-Xmx512M -Xss1024k </extraJvmArgs>
          <deploy>${project.build.directory}/gwt-tmp/</deploy>
          <soyc>false</soyc>
          <force>true</force>
          <strict>true</strict>
          <style>OBFUSCATED</style>
          <optimizationLevel>9</optimizationLevel>
        </configuration>
        <executions>
          <execution>
            <phase>generate-resources</phase>
            <goals>
              <goal>resources</goal>
              <goal>compile</goal>
            </goals>
          </execution>
        </executions>
      </plugin>
      <plugin>
        <!-- workaround for 
             http://code.google.com/p/google-web-toolkit/issues/detail?id=6397 -->
        <artifactId>maven-clean-plugin</artifactId>
        <version>2.4.1</version>
        <configuration>
          <filesets>
            <fileset>
              <directory>${basedir}/src/main/webapp/VAADIN/</directory>
              <includes>
                <directory>gwt-unitCache/**</directory>
              </includes>
              <followSymlinks>false</followSymlinks>
            </fileset>
          </filesets>
          <excludeDefaultDirectories>true</excludeDefaultDirectories>
        </configuration>
        <executions>
          <execution>
            <id>default</id>
            <phase>generate-resources</phase>
            <goals>
              <goal>clean</goal>
            </goals>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>
</profile>

Use maven profile to recompile vaadin widgetset

Today I will show you my maven profile to configure Vaadin widgetset recompilation.

The Vaadin wiki shows the basics … but I want widgetset update only if its necessary … so I moved the gwt/vaadin plugins in a profile and add a activation per file for this profile:

<profile>
   <!--
     Updates Vaadin widgetset definitions based on project dependencies
     Remove widgetset directory to trigger recompile:
       rm -Rf src/main/webapp/VAADIN/widgetsets/
   -->
   <id>update-widgetset</id>
   <activation>
     <file>
       ${basedir}/src/main/webapp/VAADIN/widgetsets/
     </file>
   </activation>
   <build>
     <plugins>
       <plugin>
         <groupId>com.vaadin</groupId>
         <artifactId>vaadin-maven-plugin</artifactId>
         <version>1.0.2</version>
         <configuration>
           <!-- if you don't specify any modules, the plugin will find them -->
         </configuration>
         <executions>
           <execution>
             <phase>generate-resources</phase>
             <goals>
               <goal>update-widgetset</goal>
             </goals>
           </execution>
         </executions>
       </plugin>
       <plugin>
         <groupId>org.codehaus.mojo</groupId>
         <artifactId>gwt-maven-plugin</artifactId>
         <version>2.3.0-1</version>
         <configuration>
           <!-- if you don't specify any modules, the plugin will find them -->
           ${basedir}/src/main/webapp/VAADIN/widgetsets/
           -Xmx512M -Xss1024k
           ${project.build.directory}/gwt-tmp/
           <soyc>false</soyc>
           <force>true</force>
         </configuration>
         <executions>
           <execution>
             <phase>generate-resources</phase>
             <goals>
               <goal>resources</goal>
               <goal>compile</goal>
             </goals>
           </execution>
         </executions>
       </plugin>
     </plugins>
   </build>
 </profile>

Bloxel 0.1.0 make progress

Now we have a simple open world algorithm, simple water effect, a spring DI integration (of course *g*), a game menu, a groovy console and some testcases And we using maven!

And more screenshots …

Intermodule Dependencies now better working in Maven 3

Found at 
http://www.sonatype.com/people/2010/12/whats-in-maven-3-0-for-users/

One of the other major improvements in Maven 3.0 is the resolution of inter-module dependencies from the current reactor build. In the past, it has been quite frustrating for users to find out that mvn install works but mvn verify sometimes fails to resolve artifacts that have just been built by a previous module, in particular when releasing a new version of their projects. Likewise, it’s hard to understand why an execution of maven-dependency-plugin:copy-dependencies succeeds to resolve artifacts from the reactor while the similar maven-dependency-plugin:copy goals fails.

As part of all the refactoring in Maven 3, a dependency resolution has been reworked to consistently check the reactor output. Apparently, the reactor output depends on the lifecycle phases that a project has completed. So if you invoke mvn compile or mvn test on a multi-module project, the loose class files from target/classes and target/test-classes, respectively, are used to create the required class path. As soon as the actual artifact has been assembled which usually happens during the package phase, dependency resolution will use this file. Last but not least, dependencies using version ranges can now be resolved from the reactor, too.

For this a short recap about reactor builds …

 parent-project (reactor)
   | ----  module-a
      | src/main/java/de/ahoehma/Core.java
      | mvn compile will create target/classes/de/ahoehma/Core.class
   | ----  module-b
      | use classes from module A
      | src/main/java/de/ahoehma/Use.java
      | Use have a dependcy to Core (module-b have a dependency to module-a)
      | mvn compile will create target/classes/de/ahoehma/Use.class

Let’s go into module-b and run mvn compile – a build error occured … can’t resolve dependency modul-a.

That’s clear … maven knows nothing about module-a right now. I can go into module-a and run mvn install to fix this “situation”.

After this I find a jar-file module-a.jar in the local maven-repository. Then the build in module-b will work. But install is not always possible … Think about API Changes, experimental code etc.  I don’t want this stuff in my local repo *g*.

For this I can run a reactor build … I go into parent and run mvn compile … that’s all. Maven will use the compile results from module-a during the build of module-b … magic

[INFO] [compiler:compile {execution: default-compile}]
[DEBUG] Using compiler 'javac'.
[DEBUG] Source directories: [F:\ws_sts\parent\module-b\src\main\java]
[DEBUG] Classpath: [F:\ws_sts\parent\module-b\target\classes
 F:\ws_sts\parent\module-a\target\classes]
[DEBUG] Output directory: F:\ws_sts\parent\module-b\target\classes
[DEBUG] Classpath:^
[DEBUG]  F:\ws_sts\parent\module-b\target\classes
[DEBUG]  F:\ws_sts\parent\module-a\target\classes
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[DEBUG] Source roots:
[DEBUG]  F:\ws_sts\parent\module-b\src\main\java
[INFO] Compiling 1 source file to F:\ws_sts\parent\module-b\target\classes
[INFO]
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO] ------------------------------------------------------------------------
[INFO] Unnamed - de.ahoehma:parent:pom:0.0.1-SNAPSHOT ........ SUCCESS [0.758s]
[INFO] Unnamed - de.ahoehma:module-a:jar:0.0.1-SNAPSHOT ...... SUCCESS [1.590s]
[INFO] Unnamed - de.ahoehma:module-b:jar:0.0.1-SNAPSHOT ...... SUCCESS [0.637s]
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 3 seconds
[INFO] Finished at: Wed Dec 22 20:27:57 CET 2010
[INFO] Final Memory: 20M/128M
[INFO] ------------------------------------------------------------------------

This works in maven 2 too!

Oberwald Rally

Ich habe heute ein kleines privates Projekt öffentlich zugänglich gemacht.

Das Projekt entstand im Rahmen unseres jährlichen Männertagstreffens (wir Leipziger HTWK Mappen feiern nicht nur einen Tag sondern gleich vier). Dieses Mal waren wir halt im schönen Oberwald. Der Tag war noch jung, ein paar Bier waren auch schon geleert … also was tun. Na dann einfach Mal etwas programmieren Ziel: “Rasende Roboter” programmieren, am besten gleich einen Algorithmus schreiben, der das Problem automatisch löst. Das Projekt beschäftigt sich also mit dem Thema “Ricochet Robots” (im dt. Rasende Roboter). Wie ich hier bereits schon schrieb, ist es eines meiner Lieblingsspiele

Das ganze Ding ist mittlerweile zu einem Eclipse PDE Projekt gereift … hier ein paar Screenshots …

Random Calculator View

Der RandomCalculator schiebt die 4 Roboter nach dem Zufallsprinzip über das Brett. Dabei kommt es ab und zu auch dazu, dass die Aufgabe (Roboter vom grünen Feld auf das rote Feld) gelöst wird

Graph Calculator View

Der GraphCalculator ist schon etwas “schlauer”, allerdings kann er nur den kürzesten Weg für einen Roboter berechnen.

Den Code gibts unter
https://code.google.com/p/oberwaldrally/
.

Feedback erwünscht!

Viel Spass beim Bot schreiben!

Howto define jetty port for integration tests

Today I found a simple hack to define the jetty-port for a web-application integration test via command line.

The problem was the defined “default” jetty port (here 8080) … on the build system this port was already bind … so the integration test always failed .

My first idea was to call maven with external system property “jetty.port” … (this worked already to start the web application on different ports):

mvn clean integration-test -Pintegration-test -Djetty.port=1234

The maven profile is here:

...
  <profile>
      <id>integration-test</id>
      <build>
        <defaultGoal>integration-test</defaultGoal>
        <plugins>
          <plugin>
            <artifactId>maven-surefire-plugin</artifactId>
            <executions>
              <execution>
                <id>integration-tests</id>
                <phase>integration-test</phase>
                <goals>
                  <goal>test</goal>
                </goals>
                <configuration>
                  <forkMode>once</forkMode>
                  <suiteXmlFiles>
                    <suiteXmlFile>src/test/resources/Integration-Suite.xml</suiteXmlFile>
                  </suiteXmlFiles>
                </configuration>
              </execution>
            </executions>
          </plugin>
          <plugin>
            <groupId>org.mortbay.jetty</groupId>
            <artifactId>maven-jetty-plugin</artifactId>
            <version>${jetty.version}</version>
            <executions>
              <execution>
                <id>start-jetty</id>
                <phase>pre-integration-test</phase>
                <goals>
                  <goal>run</goal>
                </goals>
                <configuration>
                  <daemon>true</daemon>
                  <connectors>
                    <connector implementation="org.mortbay.jetty.nio.SelectChannelConnector">
                      <port>${jetty.port}</port>
                    </connector>
                  </connectors>
                </configuration>
              </execution>
              <execution>
                <id>stop-jetty</id>
                <phase>post-integration-test</phase>
                <goals>
                  <goal>stop</goal>
                </goals>
              </execution>
            </executions>
          </plugin>
        </plugins>
      </build>
    </profile>

I think with this TestNG test this should work … (the base class ImportantUseCaseTest contains some @Test annotated test methods):

public class IntegrationTest extends ImportantUseCaseTest {
  @Override
  protected String getServerURL() {
    final String jettyPort = System.getProperty("jetty.port", "8080);
    return String.format("http://localhost:%s/webapp", jettyPort);
  }
}

But it doesn’t work

If I call maven with “-Djetty.port=1234″ the jetty starts on 1234 but the integration test runs on 8080.  Hmmm …

The solution was to change the surefire plugin configuration a little bit:

...
  <plugin>
     <artifactId>maven-surefire-plugin</artifactId>
     ...
     <configuration>
         ...
         <argLine>-Xmx512m -Djetty.port.integration=${jetty.port}</argLine>
     </configuration>

and the test class:

public class IntegrationTest extends ImportantUseCaseTest {
  @Override
  protected String getServerURL() {
    final String jettyPort = System.getProperty("jetty.port.integration", "8080);
    return String.format("http://localhost:%s/webapp", jettyPort);
  }
}

I guess that surefire with forkMode=once doesn’t pass the given system properties to the test jvm. Maybe with forkMode=never this problem not exists … but you can try this by yourself

Export maven war artifact as runnable jetty package

Today I will show you a way to export a <packaging>war</packaging> artifact as a runnable windows application.

The ingredients are:

• maven war artifact (i.e. our web application)
• embedded Jetty

A minimal web application’s pom looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>de.ahoehma</groupId>
  <artifactId>dummy-webapp</artifactId>
  <version>1.0.0-SNAPSHOT</version>
  <packaging>war</packaging>
</project>

Now we add some components to the artifact …

1. add the following profile to the pom.xml:

<profiles>
   <profile>
      <id>jetty-offline</id>
      <build>
        <plugins>
          <plugin>
            <artifactId>maven-assembly-plugin</artifactId>
            <version>2.2-beta-5</version>
            <configuration>
              <finalName>offline-dummy-webapp-${project.version}</finalName>
              <attach>false</attach>
              <descriptors>
                <descriptor>src/assembly/jetty-offline.xml</descriptor>
              </descriptors>
            </configuration>
            <executions>
              <execution>
                <id>make-assembly</id>
                <phase>package</phase>
                <goals>
                  <goal>single</goal>
                </goals>
              </execution>
            </executions>
          </plugin>
        </plugins>
      </build>
      <dependencies>
        <!-- logging ... -->
        <dependency>
          <groupId>commons-logging</groupId>
          <artifactId>commons-logging</artifactId>
          <version>1.1.1</version>
        </dependency>
        <dependency>
          <groupId>log4j</groupId>
          <artifactId>log4j</artifactId>
          <version>1.2.15</version>
          <scope>runtime</scope>
        </dependency>
        <!-- embedded jetty -->
        <dependency>
          <groupId>org.mortbay.jetty</groupId>
          <artifactId>jetty</artifactId>
          <version>${jetty.version}</version>
        </dependency>
        <dependency>
          <groupId>org.mortbay.jetty</groupId>
          <artifactId>start</artifactId>
          <version>${jetty.version}</version>
        </dependency>
        <dependency>
          <groupId>org.mortbay.jetty</groupId>
          <artifactId>jetty-util</artifactId>
          <version>${jetty.version}</version>
        </dependency>
        <dependency>
          <groupId>org.mortbay.jetty</groupId>
          <artifactId>jsp-2.1-jetty</artifactId>
          <version>${jetty.version}</version>
        </dependency>
      </dependencies>
      <properties>
          <jetty.version>6.1.23</jetty.version>
      </properties>
    </profile>
</profiles>

2. the assembly descriptor for src/assembly/jetty-offline is here:

<?xml version="1.0" encoding="UTF-8"?>
<assembly xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.1" 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.1 http://maven.apache.org/xsd/assembly-1.1.1.xsd">

  <formats>
    <format>dir</format>
  </formats>
  
  <dependencySets>
    <dependencySet>
      <!-- unpack the webapp as root application -->
      <scope>runtime</scope>
      <unpack>true</unpack>
      <outputDirectory>webapps/root/</outputDirectory>
      <includes>
        <include>de.ahoehma:dummy-webapp:war</include>
      </includes>
    </dependencySet>
    <dependencySet>
      <unpack>false</unpack>
      <outputDirectory>lib</outputDirectory>
      <useTransitiveFiltering>true</useTransitiveFiltering>
      <useStrictFiltering>true</useStrictFiltering>
      <includes>
        <include>org.mortbay.jetty:jetty</include>
        <include>org.mortbay.jetty:jetty-util</include>
        <include>org.mortbay.jetty:start</include>
        <include>org.mortbay.jetty:jsp-2.1-jetty</include>
        <include>commons-logging:commons-logging</include>
        <include>log4j:log4j</include>
      </includes>
    </dependencySet>
  </dependencySets>

  <fileSets>
    <fileSet>
      <directory>src/jetty/bin</directory>
      <outputDirectory>bin/</outputDirectory>
      <filtered>false</filtered>
    </fileSet>
    <fileSet>
      <directory>src/jetty/resources</directory>
      <outputDirectory>etc/</outputDirectory>
      <filtered>false</filtered>
    </fileSet>
  </fileSets>
  
</assembly>

See maven-assembly-plugin for more options …

3. src/jetty/bin contains a windows batch file:

 @echo off
 @set JVM_OPTS=-XX:MaxPermSize=256m -XX:PermSize=128m -Xms128m -Xmx512m
 (cd .. && java %JVM_OPTS% -jar lib/start-6.1.23.jar)

4. and at least the src/jetty/resources contains the file jetty.xml:

<?xml version="1.0"?>
<!DOCTYPE Configure PUBLIC "-//Mort Bay Consulting//DTD Configure//EN" "http://jetty.mortbay.org/configure.dtd">
<Configure id="Server" class="org.mortbay.jetty.Server">
    <Set name="ThreadPool">
      <New class="org.mortbay.thread.BoundedThreadPool">
        <Set name="minThreads">10</Set>
        <Set name="maxThreads">250</Set>
        <Set name="lowThreads">25</Set>
      </New>
    </Set>
    <Call name="addConnector">
      <Arg>
          <New class="org.mortbay.jetty.nio.SelectChannelConnector">
            <Set name="host"><SystemProperty name="jetty.host" default="localhost"/></Set>
            <Set name="port"><SystemProperty name="jetty.port" default="1976"/></Set>
            <Set name="maxIdleTime">30000</Set>
            <Set name="Acceptors">2</Set>
            <Set name="statsOn">false</Set>
            <Set name="confidentialPort">8442</Set>
      	    <Set name="lowResourcesConnections">5000</Set>
      	    <Set name="lowResourcesMaxIdleTime">5000</Set>
          </New>
      </Arg>
    </Call>
    <Set name="handler">
      <New id="Handlers" class="org.mortbay.jetty.handler.HandlerCollection">
        <Set name="handlers">
         <Array type="org.mortbay.jetty.Handler">
           <Item>
             <New id="Contexts" class="org.mortbay.jetty.handler.ContextHandlerCollection"/>
           </Item>
           <Item>
             <New id="DefaultHandler" class="org.mortbay.jetty.handler.DefaultHandler"/>
           </Item>
         </Array>
        </Set>
      </New>
    </Set>
    <Call name="addLifeCycle">
      <Arg>
        <New class="org.mortbay.jetty.deployer.ContextDeployer">
          <Set name="contexts"><Ref id="Contexts"/></Set>
          <Set name="configurationDir"><SystemProperty name="jetty.home" default="."/>/contexts</Set>
          <Set name="scanInterval">1</Set>
        </New>
      </Arg>
    </Call>
    <Call name="addLifeCycle">
      <Arg>
        <New class="org.mortbay.jetty.deployer.WebAppDeployer">
          <Set name="contexts"><Ref id="Contexts"/></Set>
          <Set name="webAppDir"><SystemProperty name="jetty.home" default="."/>/webapps</Set>
      	  <Set name="parentLoaderPriority">false</Set>
      	  <Set name="extract">true</Set>
      	  <Set name="allowDuplicates">false</Set>
        </New>
      </Arg>
    </Call>
    <Set name="stopAtShutdown">true</Set>
    <Set name="sendServerVersion">true</Set>
    <Set name="sendDateHeader">true</Set>
    <Set name="gracefulShutdown">1000</Set>
</Configure>

Now we are able to build a “offline version” of our web application:

 mvn package -Pjetty-offline

The result will be a directory target\distribution\offline-dummy-webapp-1.0.0-SNAPSHOT with the structure:

 bin/
    jetty_run.bar
 etc/
    jetty.xml
 lib/
    log4j-1.2.15.jar
    commons-logging-1.1.1.jar    
    servlet-api-2.5-20081211.jar
    start-6.1.23.jar
    jetty-6.1.23.jar
    jetty-util-6.1.23.jar
    ant-1.6.5.jar
    core-3.1.1.jar
    ecj-3.5.1.jar
    jsp-2.1-jetty-6.1.23.jar
    jsp-2.1-glassfish-2.1.v20091210.jar
    jsp-api-2.1-glassfish-2.1.v20091210.jar
 webapps/
    root/
       index.html
       css/
       images/
       META-INF/
       pages/
       WEB-INF/
       ...

To run the web application start the jetty_run.bat (i.e. open the dir with the explorer and double click the bat-file).

That’s it

This article was the first part if the tutorial … in the second part I will show you how to build a windows exe package with a runnable web application inside …

Yet another Maven discussion

I posted a comment to the Code Buzz Blog.

Concept to handle minimal and maximal tests in a maven project

In real world applications we have all too often external dependencies in test cases. Sometimes theses third party are not always available (i.e. remote webservices).

For continuous integration I want check a minimal set of tests but for my local development i want check a maximal set of tests. I want run my tests on command line (via maven) and in eclipse (via testng-plugin).

Here is my idea to do that …

My project super pom defines 2 profiles:

• test-min
  1. active by default
  2. exclude testng groups (online-tests, thirdparty-tests,…)
• test-max
  1. run a defined testng suite
  2. the suite defines a maximal set of test (all testng groups)

<profiles>
  <profile>
    <id>test-min</id>
    <activation>
      <activeByDefault>true</activeByDefault>
    </activation>
    <build>
      <plugins>
        <plugin>
          <artifactId>maven-surefire-plugin</artifactId>
          <inherited>true</inherited>
          <configuration>
            <excludedGroups>${excludedTestGroups}</excludedGroups>
          </configuration>
        </plugin>
      </plugins>
    </build>
  </profile>
  <profile>
    <id>test-max</id>
    <build>
      <plugins>
        <plugin>
          <artifactId>maven-surefire-plugin</artifactId>
          <inherited>true</inherited>
          <configuration>
            <suiteXmlFiles>
              ${basedir}/src/test/resources/Testsuite.xml
            </suiteXmlFiles>
          </configuration>
        </plugin>
      </plugins>
    </build>
  </profile>
</profiles>
<properties>
  <excludedTestGroups>online,integration,thirdparty</excludedTestGroups>
</properties>

Each subproject must define a testng src/test/resources/Testsuite.xml:

<!DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd">
<suite name="TestSuite for Foobar">
  <test name="Online Tests">
    <packages>
      <package name="de.foobar.*" />
    </packages>
    <groups>
      <run>
        <include name="online" />
      </run>
    </groups>
  </test>
  <test name="Integration Tests">
    <packages>
      <package name="de.foobar.*" />
    </packages>
    <groups>
      <run>
        <include name="integration" />
      </run>
    </groups>
  </test>
  <test name="Thirdparty Tests">
    <packages>
      <package name="de.foobar.*" />
    </packages>
    <groups>
      <run>
        <include name="thirdparty" />
      </run>
    </groups>
  </test>
  <!-- Each project can define MORE groups: i.e. "interactive" -->
  <test name="Other Tests">
    <packages>
      <package name="de.foobar.*" />
    </packages>
    <groups>
      <run>
        <exclude name="online" />
        <exclude name="integration" />
        <exclude name="thirdparty" />
        <!-- Each project can define MORE groups: i.e. "interactive" -->
      </run>
    </groups>
  </test>
</suite>

If the sub project defines more exclude groups (i.e. a additional “interactive” group) then the pom must overwrite the excludedTestGroups property:

<properties>
  <excludedTestGroups>online,integration,thirdparty,interactive</excludedTestGroups>
</properties>

To check the correct configuration of the two profiles we can use help:effective-pom:

mvn -Ptest-min help:effective-pom | less

<plugin>
  <artifactId>maven-surefire-plugin</artifactId>
  <configuration>
    <excludedGroups>online,integration,thirdparty,interactive</excludedGroups>
  </configuration>
</plugin>

mvn -Ptest-max help:effective-pom | less

<plugin>
  <artifactId>maven-surefire-plugin</artifactId>
  <configuration>
    <suiteXmlFiles>
      <suiteXmlFile>d:\foobar\src/test/resources/Testsuite.xml</suiteXmlFile>
    </suiteXmlFiles>
  </configuration>
</plugin>

Now I can run min/max tests for each project which depend on the above super-pom. The test-min is the default profile and would be used on the continuous integration system (i.e. TeamCity).

Try it

Maven https repository with self-signed ssl certificate

For a private project I try to use nexus behind apache and ssl. I used a self-signed certificate.

But each nexus repository request ends with a security exception:

[WARNING] repository metadata for: 'artifact org.apache.maven.plugins:maven-enforcer-plugin' could not be retrieved from repository: nexus-plugin-releases due to an error: Error transferring file: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target


I found many site for that problem and they describe always the same solution

import the self signed cert in your local truststore!

… here are the steps:

1. download the certificate
2. create a local truststore and import the certificat
3. call maven with the correct security properties

The import is simple  (java keytool):

keytool.exe -importcert
            -alias nexus-xxx
            -keystore xxx.jks
            -storepass secret
            -file xxx.crt

For maven I’m using a cygwin bash alias:

alias mvn_xxx='/cygdrive/d/maven-2.2.1/bin/mvn
-gs "d:/maven-2.2.1/conf/settings-xxx.xml"
-s "d:/maven-2.2.1/conf/settings-xxx.xml"
-Djavax.net.ssl.trustStore=d:/maven-2.2.1/conf/xxx.jks
-Djavax.net.ssl.trustStorePassword=secret'

I point the global config  (-gs) and the personal config (-s) to the same file to ignore other configuration from my default maven config file (i.e. common mirros settings / repositories etc.).

And at least here is my complete maven setting-nexus settings:

<?xml version="1.0" encoding="UTF-8"?>
<settings xmlns="http://maven.apache.org/settings/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd">

  <localRepository>D:\maven-repository-xxx</localRepository>

  <mirrors>
    <mirror>
      <id>xxx-nexus-snapshots</id>
      <mirrorOf>nexus-snapshots</mirrorOf>
      <url>https://nexus.xxx.com/content/groups/public-snapshots/</url>
    </mirror>
    <mirror>
      <id>xxx-nexus-snapshots</id>
      <mirrorOf>nexus-plugin-snapshots</mirrorOf>
      <url>https://nexus.xxx.com/content/groups/public-snapshots/</url>
    </mirror>
    <mirror>
      <id>xxx-nexus-releases</id>
      <mirrorOf>nexus-releases</mirrorOf>
      <url>https://nexus.xxx.com/content/groups/public/</url>
    </mirror>
    <mirror>
      <id>xxx-nexus-releases</id>
      <mirrorOf>nexus-plugin-releases</mirrorOf>
      <url>https://nexus.xxx.com/content/groups/public/</url>
    </mirror>
    <mirror>
      <id>xxx-nexus-releases</id>
      <mirrorOf>*</mirrorOf>
      <url>https://nexus.xxx.com/content/groups/public/</url>
    </mirror>
  </mirrors>

  <profiles>
    <profile>
      <id>xxx-nexus-mirror</id>
      <activation>
        <activeByDefault>true</activeByDefault>
      </activation>
      <repositories>
        <repository>
          <id>nexus-releases</id>
          <url>http://foobar</url>
          <releases>
            <enabled>true</enabled>
          </releases>
          <snapshots>
            <enabled>false</enabled>
          </snapshots>
        </repository>
        <repository>
          <id>nexus-snapshots</id>
          <url>http://foobar</url>
          <releases>
            <enabled>false</enabled>
          </releases>
          <snapshots>
            <enabled>true</enabled>
          </snapshots>
        </repository>
      </repositories>
      <pluginRepositories>
        <pluginRepository>
          <id>nexus-plugin-releases</id>
          <url>http://foobar</url>
          <releases>
            <enabled>true</enabled>
          </releases>
          <snapshots>
            <enabled>false</enabled>
          </snapshots>
        </pluginRepository>
        <pluginRepository>
          <id>nexus-plugin-snapshots</id>
          <url>http://foobar</url>
          <releases>
            <enabled>false</enabled>
          </releases>
          <snapshots>
            <enabled>true</enabled>
          </snapshots>
        </pluginRepository>
      </pluginRepositories>
    </profile>
  </profiles>

  <servers>
    <server>
      <id>xxx-nexus-releases</id>
      <username>foo</username>
      <password>bar</password>
    </server>
    <server>
      <id>xxx-nexus-snapshots</id>
      <username>foo</username>
      <password>bar</password>
    </server>
  </servers>

</settings>

You can replace xxx with your personal domain-alias.