Tag: Maven

Version 3.5.0 of the VersionEye Maven Plugin is out. It offers another configuration option to skip certain dependencies with a defined scope.

By default the VersionEye Maven Plugin is resolving ALL dependencies and sending ALL dependencies to the VersionEye API. The VersionEye Server is then checking the dependencies and is sending out emails. But sometimes you get notifications for a dependency which is under test scope or provided scope. Something you don’t really ship with your application. Ideally you want VersionEye to ignore those dependencies. Now you can configure which scopes should be skipped by the plugin. Simply add this line to your plugin configuration.

<skipScopes>test,provided</skipScopes>

The line above will ignore all dependencies which have test or provided scope.

Just released version 3.2.1 of the VersionEye Maven Plugin.

This version is a patch release! If you run “mvn versioneye:create" in a multi module project on the parent it might be that the parent pom.xml doesn’t has any dependencies. The default behaviour of VersionEye is to skip projects with 0 dependencies. In a multi module project this behaviour causes the error that the submodules can’t be merged into the parent project, because the parent was skipped because it has 0 dependencies.
This Bug is fixed now!

This week version 3.2.0 of the VersionEye Maven Plugin was released!

You need the VersionEye Maven Plugin if you want to track multi module builds with VersionEye. The plugin runs inside your Maven build lifecycle and resolves all dependencies & variables natively with the maven-core project. It is the best way to track Maven projects on VersionEye!

You can use the plugin by simply adding this code snippet to your pom.xml file.

<build>
  <plugins>
    <plugin>
      <groupId>com.versioneye</groupId>
      <artifactId>versioneye-maven-plugin</artifactId>
      <version>3.2.0</version>
      <configuration>
        <apiKey>MY_SECRET_API_KEY</apiKey>
      </configuration>
    </plugin>
  </plugins>
</build>

You can find more information about the API Key here.

The current version brings many small improvements and much more configuration options! Find here the change logs. I want to point out 2 changes.

Scopes

The plugin resolves ALL dependencies & variables locally and creates a pom.json document, with all the relevant information for VersionEye, and sends it to the VersionEye API. Now the scopes of the dependencies are send to the server as well! And in the Web interface the dependencies are divided by scopes.

Set parent project explicitly

Executing “mvn versioneye:create” on a multi module project will merge all submodules into the parent project on the server, by default. By default the parent project is determined from the pom.xml. Here is an example. The maven project on GitHub has a parent pom.xml file in the root and a couple submodules. The pom.xml files of the submodules reference as parent the pom.xml file in the root directory.

This is kind of normal. Many multi module projects have this structure. Executing the VersionEye Maven Plugin on this project would create a single project on VersionEye and each module would be a “subproject” on VersionEye. The advantage of this is that you have everything in one single view and the numbers for dependencies and licenses are summed up over all submodules. It looks like this:

If you wish to remain each submodule as separate project on VersionEye you can turn of the merging with this line in the plugin configuration:

<mergeAfterCreate>false</mergeAfterCreate>

This is all kind of default. But what happens if one of your submodules references a parent project which is in a complete different git repository? It’s not part of the current maven build. And maybe the referenced parent project is even not available at VersionEye. In that case the merging would fail because VersionEye tries to merge an existing project into a non existing project. In this case you could turn of the merge with the configuration above. That would be a quick fix.

But what if you want to merge each submodule into the maven project which is described with the pom.xml in the root directory? That is not the parent which is set as parent in the submodules pom.xml. But maybe you still want to enforce this logical structure on VersionEye! With the current version of the plugin you can enforce into which project on VersionEye the submodules should be merged, by simply setting the parent GA explicitly in the plugin configuration.

<parentGroupId>your.parent.groupid</parentGroupId>
<parentArtifactId>your.artifactid</parentArtifactId>

This is not a theoretical case. It’s a real problem which happened to some VersionEye users. With the current version of the plugin this problem is solved now!

Let me know if you have questions to this. I’m happy to help!