SoftwareEntwicklung Beratung Schulung

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

Apache Maven Surefire Plugin Version 2.20 Released

| Comments

The Apache Maven team is pleased to announce the release of the Apache Maven Surefire Plugin, version 2.20.

The release contains 70 bug fixes. Again we received contributions from the community in form of bug reports and bug fixes.

Thank you and keep them coming!

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-surefire-plugin</artifactId>
  <version>2.20</version>
</plugin>

or for failsafe:

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

or for surefire-report:

1
2
3
4
5
<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-surefire-report-plugin</artifactId>
  <version>2.20</version>
</plugin>

Apache Maven Archetype Plugin 3.0.1 Released

| Comments

The Apache Maven team is pleased to announce the release of the Apache Maven Archetype Plugin, version 3.0.1.

In short, Archetype is a Maven project templating toolkit. An archetype is defined as an original pattern or model from which all other things of the same kind are made. The names fits as we are trying to provide a system that provides a consistent means of generating Maven projects. Archetype will help authors create Maven project templates for users, and provides users with the means to generate parameterized versions of those project templates.

http://maven.apache.org/archetype/maven-archetype-plugin/index.html

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-archetype-plugin</artifactId>
  <version>3.0.1</version>
</plugin>

You can download the appropriate sources etc. from the download page.

Apache Maven 3.5.0 Release

| Comments

The Apache Maven team would like to announce the release of Apache Maven 3.5.0.

You can download the appropriate sources etc. from the download page.

Notable changes

  • ANSI colors added to the console output
  • Fix various bugs in mvn scripts regarding spaces, quotations, special characters, etc. also in combination with .mvn/ -files
  • Switch from Eclipse Aether to Maven Artifact Resolver

What happened to Maven 3.4.0?

After Maven 3.3.9 was released, the Eclipse Aether project was retired and the code base was migrated to the Apache Maven project.

The original goal for the 3.4.0 release was to replace Aether with the exact same code after migration to the Apache Maven project and then proceed with bug fixes to the resolver code as well as other areas of Maven.

The migration of the code between the two foundations took longer than expected and as a result there were other changes committed to Maven core that were outside the scope of intent for 3.4.0.

In order to refocus on the original intent for 3.4.0, the decision was taken to revert the Maven core history to the point of the 3.3.9 release and merge in the desired changes one at a time.

Because there had been a lot of communication about different features being delivered and bugs fixed in Maven 3.4.0 and the new history may not contain them in the first release, the decision was taken to forever burn the 3.4.x release line.

More detail on this decision can be read in the mailing list archive1.

Maven: POM Files Without a Version in It?

| Comments

In Maven 3.2.5 a feature has been introduced to be able to define a version of a Maven project via properties ${revision}, ${sha1} and ${changelist} which unfortuantely had some issues. Those issues have been fixed with Maven 3.5.0-beta-1 and now you can define the version of a project by using the following properties: ${revision}, ${sha1} and ${changelist}. The example below will show one usage of this:

1
2
3
4
5
6
7
8
9
10
11
12
  ..
  <parent>
    <groupId>com.soebes.smpp</groupId>
    <artifactId>smpp</artifactId>
    <version>2.2.1</version>
  </parent>

  <groupId>com.soebes.examples.j2ee</groupId>
  <artifactId>parent</artifactId>
  <version>${revision}</version>
  <packaging>pom</packaging>
  ..

For the simplicity of this example I use only ${revision} but in practice you could combine the different properties.

The above is a parent of a larger multi module build which contains serveral childs which look like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
  <modelVersion>4.0.0</modelVersion>

  <parent>
    <groupId>com.soebes.examples.j2ee</groupId>
    <artifactId>parent</artifactId>
    <version>${revision}</version>
  </parent>

  <artifactId>service</artifactId>
  <dependencies>
    <dependency>
      <groupId>com.soebes.examples.j2ee</groupId>
      <artifactId>service-client</artifactId>
      <version>${project.version}</version>
    </dependency>
    ...

   ..

Based on the above you can now build your project simply by using the following:

1
mvn -Drevision=1.0.0-SNAPSHOT clean package

So there is no need to change the pom files and check them in. But there exists a drawback. You need to define the -Drevision=... for each call of Maven which is not very convenient.

Starting with Maven 3.3.1 you can configure Maven command line parameters in a .mvn/maven.config file which could contain the version definition like this:

1
-Drevision=1.0.0-SNAPSHOT

So with Maven 3.3.1+ you can now simply call Maven via:

1
mvn clean package

More convenient?

Hm… wait a second. What if i like to create a different version? Yes you need to change the .mvn/maven.config file and you should of course checkin the change into your vcs.

No. This is not really needed, but recommended. You can overwrite the version which is defined in the .mvn/maven.config via command line like this:

1
mvn clean package -Drevision=2.0.0-SNAPSHOT

What kind of alternatives exist? You can of course define your version of your project as a property within your pom file itself.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
  ..
  <parent>
    <groupId>com.soebes.smpp</groupId>
    <artifactId>smpp</artifactId>
    <version>2.2.1</version>
  </parent>

  <groupId>com.soebes.examples.j2ee</groupId>
  <artifactId>parent</artifactId>
  <version>${revision}</version>
  <packaging>pom</packaging>
  ..
  <properties>
    ...
    <revision>2.5.0-SNAPSHOT</revision>
  </properties>

So this means you do not need to have a supplemental file in your project (like .mvn/maven.config) if you not already have. Also for this property means you can overwrite it via command like this:

1
mvn clean package -Drevision=1.8.67-SNAPSHOT

Deployment

But now let us come to an important point of this whole story. What happens if you do an deploy of such things via:

1
mvn clean deploy -Drevision=1.8.67-SNAPSHOT

The result in your repository will be having pom files which contain ${revision} which is simply not correct and can cause other issues.

How to solve this problem? This can simply being achieved by using the flatten-maven-plugin and adding the following part to your pom file:

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
27
28
<build>
  <plugins>
    <plugin>
      <groupId>org.codehaus.mojo</groupId>
      <artifactId>flatten-maven-plugin</artifactId>
      <version>1.0.0</version>
      <configuration>
        <updatePomFile>true</updatePomFile>
      </configuration>
      <executions>
        <execution>
          <id>flatten</id>
          <phase>process-resources</phase>
          <goals>
            <goal>flatten</goal>
          </goals>
        </execution>
        <execution>
          <id>flatten.clean</id>
          <phase>clean</phase>
          <goals>
            <goal>clean</goal>
          </goals>
        </execution>
      </executions>
    </plugin>
  </plugins>
</build>

By using the above you can now simply do a deploy via:

1
mvn clean deploy -Drevision=1.8.67-SNAPSHOT

and the resulting pom file within the repository will correctly contain the resolved version 1.8.67-SNASPHOT.

This makes it easy to change the version from within a CI/CD tool. For example in Jenkins you can add a parameter like this:

1
mvn clean package -Drevision=1.0-${BUILD_NUMBER}-SNAPSHOT

Or make more sophisticated combinations of the properties ${revision}, ${sha1} and ${changelist}.

Conclusion

In the end you are not able to completely ban the versions from your pom file but nearly 100% which means you do not need to repeat it in each of your parent entries in a multi module build.

Furthermore you have saved a lot of issues related to merge conflicts within branches in Maven builds caused by the different version number for the different branches, cause the version can simply being defined by the CI/CD solution or manually from command line.

Mojo Mock Repository Manager Plugin Version 1.1.0 Released

| Comments

Hi,

The MojoHaus team is pleased to announce the release of the Mock Repository Manager Maven Plugin version 1.1.0.

The Mock Repository Manager Plugin is used when you want to test Maven plugins against specific sets of dependencies in a repository.

To get this update, simply specify the version in your project’s plugin configuration:

1
2
3
4
5
<plugin>
  <groupId>org.codehaus.mojo</groupId>
  <artifactId>mrm-maven-plugin</artifactId>
  <version>1.1.0</version>
</plugin>

Release Notes – Mojo’s Mock Repository Manager – Version 1.1.0

Enjoy,

The MojoHaus team.

Apache Maven Version 3.5.0-beta-1 Released

| Comments

The Apache Maven team would like to announce the release of Maven 3.5.0-beta-1.

NOTE: This is an BETA release. There is the potential that features may be removed between this release and the first GA release in the 3.5.x release line. Please consult the Known Issues section below before use

You can download the appropriate sources, etc. from the archives section on the download page as Maven 3.3.9 is still the recommended GA release

https://archive.apache.org/dist/maven/maven-3/3.5.0-beta-1/

Known Issues

The following issues were identified during release testing of this ALPHA release but have not been deemed as release blockers:

  • MNG-6190 – maven-resolver-provider’s DefaultArtifactDescriptorReader has mismatched constructor and initService methods (this issue does not affect normal usage of Maven)
  • MNG-6191mvn -f complains about illegal readlink option under macOS
  • MNG-6192 – The distribution zip file has unordered entries and some tools – most notably Maven wrapper – will fail to unzip the distribution

Why not Maven 3.4.0?

After Maven 3.3.9 was released, the Eclipse Aether project was retired and the code base was migrated to the Apache Maven project.

The original goal for the 3.4.0 release was to replace Aether with the exact same code after migration to the Apache Maven project and then proceed with bug fixes to the resolver code as well as other areas of Maven.

The migration of the code between the two foundations took longer than expected and as a result there were other changes committed to Maven core that were outside the scope of intent for 3.4.0.

In order to refocus on the original intent for 3.4.0, the decision was taken to revert the Maven core history to the point of the 3.3.9 release and merge in the desired changes one at a time.

Because there had been a lot of communication about different features being delivered and bugs fixed in Maven 3.4.0 and the new history may not contain them in the first release, the decision was taken to forever burn the 3.4.x release line.

More detail on this decision can be read in the mailing list archive.

Release Notes – Maven – Version 3.5.0-beta-1

Bugs:

  • MNG-5895 – Problem with CI friendly usage of ${..} which is already defined via property in pom file.
  • MNG-6057 – Problem with CI friendly usage of ${..} reactor order is changed
  • MNG-6090 – CI friendly properties break submodule builds
  • MNG-6170 – NPE in cases using Multithreaded -T X versions:set -DnewVersion=1.0-SNAPSHOT
  • MNG-6173 – MavenSession.getAllProjects() should return all projects in the reactor
  • MNG-6176 – Javadoc errors prevent release with Java 8
  • MNG-6177 – The —file command line option of the Windows and Unix launchers does not work for directory names like “Spaces & Special Char”
  • MNG-6180 – groupId has plain color when goal fails
  • MNG-6181 – HttpClient produces a lot of noise at debug loglevel
  • MNG-6183 – Dependency management debug message corrections.

Improvements:

  • MNG-6078 – Can’t overwrite properties which have been defined in .mvn/maven.config
  • MNG-6115 – Add Jansi native library search path to our start scripts to avoid extraction to temp file on each run
  • MNG-6179 – Remove unused prerequisites
  • MNG-6189 – WARN if maven-site-plugin configuration contains reportPlugins element

New Feature:

  • MNG-6182 – ModelResolver interface enhancement: addition of resolveModel( Dependency ) supporting version ranges

Enjoy,

  • The Apache Maven team

Asciidoctor Maven Plugin Version 1.5.5 Released

| Comments

This release aligns the maven plugin version to the latest version of AsciidoctorJ v1.5.5, and in turn Asciidoctor v1.5.5.

Thanks to all contributors! Improvements

Upgraded AsciidoctorJ version to 1.5.5, see AsciidoctorJ and Asciidoctor respective release notes for more details Upgraded JRuby to 1.7.26, note that using AsciidoctorJ-pdf v1.5.0-alpha.14 requires JRuby 9.1.8.0

  • #270 docinfo files are now excluded by default (@ge0ffrey)
  • #267 Enabled configuration of sourcemap, catalog_assets and template_cache options
  • #255 Added compatibility for AsciidoctorJ 1.6.0 extensions (@robertpanzer)
  • #253, #251, #247, #245, #243, #241 Many improvements and fixes in the maven plugin configuration, dependencies and build process (special thanks to @khmarbaise for his patience)
  • #227 Upgraded Netty and other project dependencies for Java9 compatibility (@Sanne)
  • #226 Added resource filtering option (choosing which resources to copy to target), see new ‘resources’ configuration option for details
  • #218 Improved how AsciidoctorJ is created for v1.6.0 compatibility (@mattadamson)
  • #223 Added Chinese version of the README (@diguage)
  • #209 Added support for command line options, see command-line-configuration for details Many, many documentation improvements (@ge0ffrey, @leif81, @dashorst)
  • #198 Improved behaviour when source directory is not found for multi-module configurations, instead of failing, plugin with now finish and show an informatime message (@Stummi)

Bug fixes

  • #252 Fixed an issue that disabled source-highlighting
  • #216 Fixed property name in ‘zip’ mojo (@ghusta)
  • #153 Fixed an issue that prevented GitHub urls from being included

Release Meta

Released on: 2017-03-17

Released by: @abelsromero

Soundtrack: Warszawa (Porcupine Tree)

Mojo Mock Repository Manager Plugin Version 1.0.1 Released

| Comments

Hi,

The MojoHaus team is pleased to announce the release of the Mock Repository Manager Maven Plugin version 1.0.1.

The Mock Repository Manager Plugin is used when you want to test Maven plugins against specific sets of dependencies in a repository.

To get this update, simply specify the version in your project’s plugin configuration:

1
2
3
4
5
<plugin>
  <groupId>org.codehaus.mojo</groupId>
  <artifactId>mrm-maven-plugin</artifactId>
  <version>1.0.1</version>
</plugin>

Release Notes – Mojo’s Mock Repository Manager – Version 1.0.1

Enjoy,

The MojoHaus team.

MojoHaus Exec Maven Plugin Version 1.6.0 Released

| Comments

The Mojo team is pleased to announce the release of the Exec Maven Plugin version 1.6.0.

The plugin helps with execution of system and Java programs.

To get this update, simply specify the version in your project’s plugin configuration:

1
2
3
4
5
<plugin>
  <groupId>org.codehaus.mojo</groupId>
  <artifactId>exec-maven-plugin</artifactId>
  <version>1.6.0</version>
</plugin>

The Release Notes are available via GitHub Issue Tracker

Enjoy,

The MojoHaus Team.