VersionEye Maven Plugin 3.7.0

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:


By creating the project with this command:

mvn versioneye:create

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”!

mvn versioneye: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!

mvn versioneye:securityAndLicenseCheck

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 ;)



Changes for the VersionEye API

The VersionEye API just got even better. There are 2 new features available!

Security Vulnerability

The endpoint to fetch a project as JSON via HTTP GET request has a new attribute “sv_count” now. That stands for “security vulnerability count”. This number displays how many known security vulnerabilities exists in the project. This number should always be 0. If it’s bigger than 0 you have a problem!


This number can be used from API AddOns to break the build on a CI system if there are some security vulnerabilities! The VersionEye Maven Plugin has already implemented that!

Better support for organisations & teams

Now a project can be attached to an organisation AND a team at creation time! The endpoint for creating a new project at VersionEye has 2 new parameters now, the “orga_name” and “team_name” parameters!


With this 2 new parameters you can define the Organisation and Team which the project should be attached to! Both parameters are case sensitive! If an “orga_name” is defined without a team, the “Owners” team will be selected automatically!

The API will check the permission of the API key of course. If the API Key (User) isn’t part of the defined organisation or doesn’t has permission to assign projects to that organisation then the project still will be created, but not assigned to the organisation. In that case the project will belong to the user which owns the API key.

The VersionEye Maven Plugin is supporting this 2 new attributes already.


API Breaking Change! Project_Key -> Project_ID

There is a little breaking change in the VersionEye API. Up to know it was possible to use “Project_Key” AND “Project_ID” for the Project endpoints. The “Project_Key” was a unique project identifier inside of a user account. For example “npm_package_json_1″ or “gradle_build_gradle_1“. At the beginning of the project that looked like a good idea. But it wasn’t. Because nobody is typing project_keys by hand. It’s something you receive from the API and you copy & paste it into some kind of config file, depending on the tool you are using. And because it only lives in config files the Project ID is just as good for that use case. Maintaining the Project Key in the code base, means a lot of redundancy. And since the organisations & teams have been introduced, projects don’t belong necessarily to a single user anymore. That’s why the Project Key was removed from the code base and from the API. 

Organisations & Teams

A big new feature was released today! The organisations & teams feature. It is replacing the “collaborations” feature. The “collaborations” feature didn’t worked out very well. It was too difficult and too time consuming to ad collaborators to the project. You had to fill the collaborators list for each project separately. That was just a lot of repeating work and many users asked for a “Team” feature, where you can define a Team once and assign a Team to a project. The new release today goes even one step further.


Now VersionEye has a concept of organisations, just like GitHub. Now projects can belong to an organisation, instead of to a single user. An organisation can have multiple teams, license whitelists, component whitelists and projects. A user can create/belong to multiple organisations.

Screen Shot 2015-11-29 at 17.20.35

The license and component whitelists are now only available through organisations. That way it’s easier to share them with other team members.


Every organisation has by default at least 1 team. The “Owners” team. The users in the “Owners” Team are the administrators of the organisation. They can:

  • edit the organisation detail informations
  • create/delete teams
  • add users to a team
  • remove users from a team
  • create/edit/delete license whitelists
  • create/edit/delete component whitelists
  • create/edit/delete projects inside of the organisation
  • transfer project ownership to the organisation

They can not:

  • delete the “Owners” team
  • delete the last user/member in the “Owners” team. There must be always at least 1 member in that team.

Members of other teams can:

  • remove them self from the list
  • edit/delete projects which are assigned to the team.
  • see all projects inside of the organisation

They can not:

  • edit the organisations detail informations
  • create/delete teams
  • add new members to a team
  • remove other members from a team
  • create/edit/delete license whitelists
  • create/edit/delete component whitelists
  • transfer project ownership to the organisation

Transfer a project to an organisation

If you want to work on a project with multiple team members it makes sense to transfer the project to an organisation and assign a team to the project. First of all you have to create an organisation. If you do so, you are automatically added to the “Owners” team of that organisation. Now you can transfer a project to the newly created organisation. Just go the project detail page to the settings tab. At the bottom you will see a select input field with all organisations where you have admin rights.

Screen Shot 2015-11-29 at 17.35.07.png

Simply select the organisation which should be the new owner of the project and click the “Transfer” button. If you go back to the project list view where you can see all your projects, you will notice that the project disappeared. Above the project list there is a filter. The first input field is the organisation filter. By default your personal account is pre selected. But here you can select and filter for an organisation you belong to. That way you will see only projects from that organisation.


Create a Team

A team is a collection of users inside an organisation which work on the same projects. Navigate to the “Team” page inside your organisation and create as many teams as you want.


Click on the team name to add some team members. Simply start typing the username or full name of a user and you will get some autocompletion with existing users.


Every new member of the team will receive an email notification that he was added to your team/organisation.

Now navigate to a project which you transferred already to the organisation. In the settings tab at the bottom a list of all teams of the organisation will show up. Simply select the team you would like to assign to the project and click the “transfer” button.


All the team members will receive the email notifications to the project. They all can edit the project settings and use their own API key to update the project via the API.


The API was updated as well. If a project is created through the API it can be assigned to an organisation at creation time.


The “orga_name” is optional. If it matches with an existing organisation name and the users API key has admin permissions for that organisation, the project will be assigned to that orga. Otherwise the project belongs to the user which is creating the project.

The other changes of the API are transparent for the users.

What is missing

Delivering this “Organisations/Teams” feature was a big refactoring. A lot of code had to be touched for that and the work is still not 100% done. 3 important things are still missing:

  1. Payment/Billing: Currently the organisation itself can’t have a subscription/plan. This is coming soon. The final goal is that an organisation can subscribe to plan and the whole billing is happening through an organisation, just like at GitHub.
  2. Creating Projects: If you create a new project via the API you can assign it directly to an organisation. This doesn’t work in the web interface yet. If you create a new project through the UI it always belongs to your user account and you have to transfer the project to an organisation if you want to have it in an organisation.
  3. OAuth: If a project was created through an OAuth process, for example from GitHub, Bitbucket or Stash, VersionEye needs OAuth credentials to update the project regularly. As the organisation doesn’t have OAuth credentials itself VersionEye randomly picks a team member of the project and assumes that the team member has the right OAuth credentials to update the project. In future it will be possible to pick a team member which should be used for OAuth update operations.


This is a big new feature and many users and companies asked for it. Please test it and give constructive feedback. I would like to know how well it works for you and what else (beside the 3 points above) is missing to make it super awesome. You can leave a comment here, mention VersionEye at Twitter and simply shoot me an email.

Security Alerts for Java & Python

A couple months ago VersionEye started to track security vulnerabilities for PHP packages. A couple weeks ago the feature was rolled out for Ruby & Node.JS dependencies as well. And now it’s rolled out for Java & Python!

Now you will see the security tab in your Java & Python projects as well. Just like in the example here.


If you click on the dependency link above you will come to the package detail page where more details to the security issues are visible.


If your project dependencies are affected the dependency badge turns to “insecure”, showing everybody that some of the dependencies have security issues.

The security feature is available via the VersionEye API as well. You can filter by language and prod_key. Feel free to build your own integration on it :)


VersionEye notifies you about security vulnerabilities independently from the version & license notifications. The security notification emails are going out on each Tuesday.

Currently VersionEye is crawling 6 different security sources for this feature. For Java & Python we are using the victims db, which claims to have 0 false positives. Please contribute to this db if you know about a Java or Python security vulnerability and help to make the world a safer place.

Do you know more good security databases which you would like to see integrated with VersionEye? If so contact me on Twitter please.

Security Alerts for Ruby Gems

Since a couple weeks VersionEye shows security issues for PHP projects. Now this feature works the same way for NodeJS and Ruby packages. If VersionEye is monitoring a Gemfile for you, then you will see the “Security” tab in the project view. Just like here in this example.


In the “Security” tab all known security vulnerabilities are listed for your 3rd party dependencies. If there is a security issue the dependency badge turns red! By clicking on the package name the package detail page comes up with a more detailed description of the security vulnerability.


On the detail the page a detailed description of the security vulnerability shows up and a link to the original source. That way it’s easy to reproduce the security vulnerability.

Now there is now reason not to use VersionEye. You get notifications about:

  • out-dated dependencies
  • license violations
  • security vulnerabilities

This feature is pretty new, but already good tested through the PHP community. Your feedback is anyway welcome either here in the comments or on Twitter.