Support for Teams

This release brings support for Tams.

• Teams: Now in the configuration part of the plugin the team can be set like this for example backend_devs. This "team" tag only works in combination with the "organisation" tag. The team which is defined here must exist in the "organisation"! By running mvn versioneye:create the new created project at VersionEye will be attached to the organisation and team which is defined in the organisation and team tag. This feature assumes that the API key which is used for this operation belongs to the organisation and has the rights to assign projects to the organisation and the team.
• versioneye:securityCheck: This new goal works similar to the "licenseCheck" goal. If a dependency has a known security vulnerability this goal will break the build!
• versioneye:securityAndLicenseCheck: This new goal will break the build if there are some known security vulnerabilities OR if there is license violation!

Support for organisations

This release brings 3 new configuration options for creating a project.

• Organisations: Now in the configuration part of the plugin the organisation can be set like this for example <organisation>versioneye</organisation>. By running mvn versioneye:create the new created project at VersionEye will be attached to the organisation which is defined in the organisation tag. This feature assumes that the API key which is used for this operation belongs to the organisation and has the rights to assign projects to the organisation.
• Visibility: The visibility tag in the configurations controls the visibility of the project at VersionEye. It can be set to private like this <visibility>private</visibility> or public like this <visibility>public</visibility>. If it is not set the project visibility is fetched from the server settings on the VersionEye server.
• Name: There is already a nameStrategy tag to control the name of the project at VersionEye, but now with the name tag the name value can be set explicitly like this for example: <name>NameOfTheProjectAtVersionEye</name>.

Fixing Nullpointer for SkipScopes

Fixed #43

skipScopes

This version offers a new configuration option skipScopes. With skipScopes you can define which scopes should be ignored by this plugin. Sometimes you don't want to track dependencies under test or provided scope. Now you can add this line to your plugin configuration to ignore these scopes:

<skipScopes>test,provided</skipScopes>

The default value of this configuration property is null. By default ALL scopes are handled by this plugin.

Track Plugins

This release contains 2 new features and 1 improvement.

• plugins: Plugins who are explicitly defined in the pom.xml file are now handled just like regular dependencies. They get submitted to the VersionEye API with the "plugin" scope and the appear in the regular project view on VersionEye.com.
• dependencyManagement:dependencies: Until now this plugin only tracked dependencies under "dependencies". With this release dependencies under "dependencyManagement" are tracked as well!
• licenseCheckBreakByUnknown: The goal "versioneye:licenseCheck" breaks the build if there is a license violation. Now there is a new property for the configurations section called "licenseCheckBreakByUnknown". If that property is true the goal "versioneye:licenseCheck" will break the build if there is a license violation OR if there is a component without any license information! By default this property is false.

New goal licenseCheck

On VersionEye a license whitelist can be assigned to each project. VersionEye will check if the licenses of the dependencies are on the license whitelist. If that is not the case the dependencies are marked red. Now there is a new goal which will break the build if there is a license violation:

mvn versioneye:licenseCheck

This goal is meant to be executed on each build on a CI Server.

Allow projects with zero dependencies

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!

More configuration options

This release contains many configuration options for the plugin!

• mergeAfterCreate: Fixed #37. Executing mvn versioneye:create on a multi module project will merge all submodules into the parent project on the server, by default. With the configuration option mergeAfterCreate the default behaviour can be turned off. If mergeAfterCreate is false each submodule on the multi module project will remain a separate project at VersionEye.
• Set parent project explicitly: Fixed #38. 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. Now parent project in which the submodules should be merged, can be set explicitly with parentGroupId and parentArtifactId. That way the sub modules can be merged in any Java project at VersionEye.
• Scopes: Fixed #39. Now the scopes of the dependencies are send to the API as well and in the project detail view on the server the dependencies are splitted up by scopes like here
• nameStrategy: Fixed #40. Executing mvn versioneye:create creates a new project on VersionEye. The name of the new project is the value from the name attribute in the pom.xml file. Now there are 2 more name strategies available. By setting the configuration option nameStrategy to GA the name of the new project will be the groupId/artifactId pair. Or set the value to artifact_id to take the artifactId as project name.

Merge Multi Module Builds

This release contains 2 backwards compatible changes:

• Better error messages: Until now the plugin did not handle error messages from the server. If the API was not available the build just failed with a random Exception. The current version handles the response code from the API. If the server responds with an error message it will be displayed in the command line as well!
• Multi Module Builds: In a multi module project the plugin created a separate project for each module. This behaviour changed in this version. Since VersionEye supports projects with multiple files the plugin creates always only 1 single project! If it is a multi module project, each module is a "subproject" in the VersionEye project.

3.1.0 with Proxy support

This release contains many small improvements and a much better documentation.

• Proxy support:
  • Now the plugin can be configured for a proxy. Checkout the proxy section in the README.
• mvn versioneye:create:
  • By default this goal creates/updates a versioneye.properties file. The creation of the file can be skipped with this line in the configuration <updatePropertiesAfterCreate>false</updatePropertiesAfterCreate>.
  • Now the goal can handle pom.xml files with no dependencies. Until now the goal exited with an exception if it couldn't find dependencies. That was specially in multimodule projects a show stopper because it stopped the whole life cycle. The current version will just skip projects with 0 dependencies and continue.
• mvn versioneye:update:
  • Just as mvn versioneye:create this goal can handle pom.xml files with 0 dependencies.
  • Until now this goal always updated the versioneye.properties file. That was unnecessary because an update doesn't change the project_id or API Key. The current implementation doesn't touch the versioneye.properties file.
• Error messages:
  • Some error messages have been misleading because exceptions haven't been propagated to the top. The current implementation logs Exceptions directly to the default output, which makes debugging much easier.
• Info messages:
  • The info messages have been completely refactored and the plugin outputs now the dependencies which will be processed in the corresponding goal.
• Documentation:
  • The documentation was updated with more examples in many sections.