SoftwareEntwicklung Beratung Schulung

A coders, hackers heaven.....Hm...I do not think so...

Apache Maven Shared Invoker Version 2.2 Released

| Comments

The Apache Maven team is pleased to announce the release of the Apache Maven Shared Maven Invoker, version 2.2

This API is concerned with firing a Maven build in a new JVM. It accomplishes its task by building up a conventional Maven command line from options given in the current request, along with those global options specified in the invoker itself. Once it has the command line, the invoker will execute it, and capture the resulting exit code or any exception thrown to signal a failure to execute. Input/output control can be specified using an InputStream and up to two InvocationOutputHandlers.

Important message for Windows users who want to invoke Apache Maven 3.3.1 and above:

Due to http://jira.codehaus.org/browse/MNG-5776 the start-script has been renamed from mvn.bat to mvn.cmd, which caused the previous versions of Maven Invoker to not being able to find the executable file anymore. This critical issue has been fixed in this release.

In the next release of the maven-invoker-plugin, which should be released soon, we’ll add this fix as well. In the meantime you can configure the plugin like this:

1
2
3
4
5
6
7
8
9
10
11
12
<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-invoker-plugin</artifactId>
  <version>1.9</version>
  <dependencies>
    <dependency> <!-- remove when using maven-invoker-plugin 1.10 -->
      <groupId>org.apache.maven.shared</groupId>
      <artifactId>maven-invoker</artifactId>
      <version>2.2</version>
    </dependency>
  </dependencies>
</plugin>

Announcement: End of Life of Maven 2.2.1 - Plugins / JDK Roadmap

| Comments

Dear Maven Users,

based on the End of Life of Maven 2.2.1 (a year ago) now the time has come to make the final releases of Apache Maven Plugins which support Maven 2.X.

If you continue to use Maven 2.2.1 or earlier you have to be aware of using an completely unsupported Maven version as well as unsupported Maven plugins for the future.

If you want to have access to new features and bug fixes it is really necessary to update to new Maven versions.

The next Maven version which will go the same way as Maven 2.2.1 will be Maven 3.0.5.

We have documented the final releases of plugins which support Maven 2.2.1 in relationship with JDK 1.5.

The complete list can be found here:

http://maven.apache.org/maven-2.x-eol.html

The next step on our roadmap is to lift all plugin versions to 3.0.0 to make clear those plugins will only work with Maven 3.0+ furthermore the Java minimum requirement will be lifted to JDK 1.6 as well.

No “rule” without exceptions. Here they come:

  • maven-site-plugin (Version 3.4) See the docs of the plugin for usage in Maven 2.X

  • maven-compiler-plugin (Version 3.2) which works with Maven 2.2.1.

  • maven-plugin-plugin (Version 3.4) which works with Maven 2.2.1

  • maven-pmd-plugin (Version 3.4) which works with Maven 2.2.1 but needs JDK 1.6

The following plugins already have the Maven 3.0+ requirement:

  • maven-scm-publish-plugin (Version 1.1)
  • maven-shade-plugin (Version 2.3)

Currently the plan is to make those plugins which are already at 3.X being lifted to version 3.5.0 for Maven 3.X only:

  • maven-site-plugin (Version 3.5.0)

  • maven-compiler-plugin (Version 3.5.0)

  • maven-plugin-plugin (Version 3.5.0)

  • maven-pmd-plugin (Version 3.5.0)

All other plugins will get a version 3.0.0 to identify Maven 3.X only plugins and the JDK minimum will be 1.6.

Example: So to make things more clearer here is an example:

Currently we have the maven-clean-plugin with version 2.6.1.

This plugin supports Maven 2.2.1 and JDK 1.5 minimum.

This plugin will get a new major release with version 3.0.0 which has the Maven minimum 3.0 AND Java minimum 1.6.

Kind regards – The Apache Maven Team

Apache Maven CheckStyle Plugin Version 2.15 Released

| Comments

The Maven team is pleased to announce the release of the Apache Maven Checkstyle Plugin, version 2.15.

Generates a report on violations of code style and optionally fails the build if violations are detected.

You should specify the version in your project’s plugin configuration:

1
2
3
4
5
<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-checkstyle-plugin</artifactId>
  <version>2.15</version>
</plugin>

Apache Maven DOAP Version 1.2 Released

| Comments

The Apache Maven team is pleased to announce the release of the Apache Maven DOAP Plugin, version 1.2.

The DOAP Plugin is used to generate a compliant Description of a Project (DOAP) file from a POM. The main goal is to be able to provide DOAP files for Semantic Web systems that use them as primary input but that would also alleviate the burden of maintaining two sets of metadata.

1
2
3
4
5
<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-doap-plugin</artifactId>
  <version>1.2</version>
</plugin>

Apache Maven 3.3.1 Features

| Comments

The new Maven 3.3.1 Release is just out. Let us take a deeper look into the new features/improvements:

  • The first and most important thing is that Maven 3.3.1 needs JDK 1.7.

  • In our days it becomes more and more important to be able to use different JDK to be used by Maven itself and which is used to compile/test your production code. This concept is know under the name Toolchains which is unfortunately not very well-known.

    The handling of the toolchains.xml file has been adjusted with the handling of settings.xml which means it will be searched within the ${maven.home}/conf/ folder and furthermore within the ${user.home}/.m2/ folder.

    For a better understanding and as an example of the toolchains.xml file has been added to the Maven distribution.

    Maven has been improved to read the toolchains.xml file during initialization instead of waiting till maven-toolchains-plugin will read it.

  • Core Extension mechanism has been improved to make it simpler to use.

    The old way (up to Maven 3.2.5) was to create a jar (must be shaded if you have other dependencies) which contains the extension and put it manually into the ${MAVEN_HOME}/lib/ext folder. This means you had to change the Maven installation. The consequence was that everyone who likes to use this needed to change it’s installation and makes the on-boarding for a developer much more inconvenient. The other option was to give the path to the jar on command line via mvn -Dmaven.ext.class.path=extension.jar. This has the drawback giving those options to your Maven build every time you are calling Maven. Not very convenient as well.

    From now on this can be done much more simpler and in a more Maven like way. So you can define an ${maven.projectBasedir}/.mvn/extensions.xml file which looks like the following:

1
2
3
4
5
6
7
8
<extensions xmlns="http://maven.apache.org/EXTENSIONS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/EXTENSIONS/1.0.0 http://maven.apache.org/xsd/core-extensions-1.0.0.xsd">
  <extension>
    <groupId/>
    <artifactId/>
    <version/>
  </extension>
</extensions>

Now you can simply use an extension by defining the usual maven coordinates groupId, artifactId, version as any other artifact. Furthermore all transitive dependencies of those extensions will automatically being downloaded from your repository. So no need to create a shaded artifact anymore.

An other advantage is that the ${maven.projectBasedir}/.mvn/ directory is located in the root of your Maven project and in conseuqence is part of your project which means you will check it in along with your project. So everyone who checks out your project automatically can use the extensions.

  • Project specific jvm and command line otions

    It’s really hard to define a general set of options for calling the maven command line. Usually this will be solved by putting this options to a script but this can now simple being done by defining ${maven.projectBasedir}/.mvn/maven.config file which contains the configuration options for the command line. For example things like -T3 -U --fail-at-end. So you only have to call maven just by using mvn clean package instead of mvn -T3 -U --fail-at-end clean package and not to miss the -T3 -U --fail-at-end options. The ${maven.projectBasedir}/.mvn/maven.config is located in the ${maven.projectBasedir}/.mvn/ folder which is in the root of a multi module build. This folder is part of the project and will be checked in into your version control. This results in being picked by everybody who checks out the project and no need to remember to call this project via mvn -T3 -U --fail-at-end clean package instead of mvn clean package.

    In Maven it is not simple to define JVM configuration on a per project base. The existing mechanism based on an environment variable MAVEN_OPTS and the usage of ${user.home}/.mavenrc is an other option with the drawback of not being part of the project.

    Starting with this release you can define JVM configuration via ${maven.projectBasedir}/.mvn/jvm.config file which means you can define the options for your build on a per project base. This file will become part of your project and will be checked in along with your project. So no need anymore for MAVEN_OPTS, .mavenrc files. So for example if you put the following JVM options into the ${maven.projectBasedir}/.mvn/jvm.config file

1
-Xmx2048m -Xms1024m -XX:MaxPermSize=512m -Djava.awt.headless=true

you don’t need to remember of using this options in MAVEN_OPTS or switching between different configurations.

If you call a plugin directly from command line like the following:

1
mvn exec:java

The configuration which is used here can be defined in your pom by using an execution id default-cli.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
<project...>

  <build>
    <plugins>
      <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>exec-maven-plugin</artifactId>
        <version>1.3.2</version>
        <executions>
          <execution>
            <id>default-cli</id>
            <configuration>
              <mainClass>com.soebes.test.First</mainClass>
            </configuration>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>
</project>

Starting with this Maven release you can now define several configuration for different executions on command like the following:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
<project...>

  <build>
    <plugins>
      <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>exec-maven-plugin</artifactId>
        <version>1.3.2</version>
        <executions>
          <execution>
            <id>default-cli</id>
            <configuration>
              <mainClass>com.soebes.test.First</mainClass>
            </configuration>
          </execution>
          <execution>
            <id>second-cli</id>
            <configuration>
              <mainClass>com.soebes.test.Second</mainClass>
            </configuration>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>
</project>

So if you like to use the configuration given with the execution id: second-cli this can be done like this:

1
mvn exec:java@second-cli

So now you can define more than one configuration for command line executions.