Release 3.7.0 of the VersionEye Maven Plugin is out and it brings a couple cool new features!
Support for Organisations & Teams
If a new project is created, by default, it is attached to the user account who created the project. In the Web interface the project can be moved into an organisation and then a team can be assigned to it. Until now that was a lot of manual work. Now with this release it can be automated. The new version of the VersionEye Maven Plugin has 2 more configuration options. Now the organisation and the team can be defined directly in the plugin configuration, like in this example:
<plugins> <plugin> <groupId>com.versioneye</groupId> <artifactId>versioneye-maven-plugin</artifactId> <version>3.7.0</version> <configuration> <apiKey>API_KEY</apiKey> <organisation>versioneye</organisation> <team>BackendDevs</team> </configuration> </plugin> </plugins>
By creating the project with this command:
The project will be created at VersionEye and automatically assigned to the organisation, in this example to the organisation “versioneye”. And the team also gets assigned to the project, in the example above it would be “BackendDevs”. The organisation and team names are case sensitive! Please take care of that, otherwise it will not work!
This feature also assumes that the owner of the API key is part of that organisation and has the permissions to attach projects to that organisation and the permission to assign teams to projects! If that is not the case or the organisation doesn’t exist, the project still gets created, but then it belongs to the user who owns the API key. Just like the old behaviour!
Similar to the licenseCheck goal, there is a new goal “securityCheck”!
This goal checks how many of the project dependencies have known security vulnerabilities! If the count is greater than 0, this goal will exit with an non zero exit code! If you run this goal on a CI server, this will break the build if there are security vulnerabilities!
Similar to the securityCheck, this goal is checking security AND license violations!
If a dependency has a known security vulnerability OR a dependency is violating the license whitelist on the server, this goal will exit with an non zero exit code! Means, that will break your build if you run it on a CI server!
Try out this cool new features and leave a feedback comment here if you like 😉