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 šŸ˜‰

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.

CSV Export

At VersionEye you can setup a license whitelist to enforce a license policy. For each project there is a PDF Export, which contains the BoM (Bill of Materials). Now the same export is available as CSV as well. The links for the export are in the project detail view in the license tab.


The new CSV Export has the same format as the PDF Export. It contains the list of dependencies with the information if they violate the license whitelist or not. Here is a screenshot of an example.


The PDF/CSV Export also contains the current status of the license whitelist and the current status of the assigned component whitelist. That way the exported document is a complete snapshot of the current state of the project, license whitelist and component whitelist. That makes it easy to reproduce why a component is whitelisted or not.

Try out the CSV Export and let me know if you have any questions. Either here in the comments or on Twitter.

VersionEye SBT Plugin

The VersionEye API is becoming more and more popular. And there are more and more tools which integrate the VersionEye API. Specially in Java Enterprise the VersionEye Maven Plugin is very popular. Ā It can handle complex reactor builds with Maven. But the requirement to support SBT natively is growing as well. That’s why I would like to have an SBT Plugin for VersionEye similar to the VersionEye Maven Plugin.


The requirements for the plugin can be found here. I posted the link yesterday on Twitter and somebodyĀ from the community stepped up to work on this šŸ™‚ The project will remain 100% open source under the MIT license. I expect to get the first results in the next weeks. More help is always welcome šŸ˜‰

Project Settings Changes

The project setting at VersionEye just got an update. Up to now it was possible to select a secondary email address to which the project notifications should be send. This is removed now! It was a feature which less than 1% of all projects used. If only 0.83% of all projects are using a feature then it’s not worth maintaining the code for that.

Screen Shot 2015-08-13 at 16.39.28

Beside that the License Whitelist setting is removed from the settings area. Simply because it is already included in the license tab. No reason for redundancy.

The collaborators feature got an update as well. Now collaborators of a project can see ALL tabs and they haveĀ almost the same rights like the project owner. A collaborator can invite other collaborators. But he can not remove other collaborators from the project. That power has only the project owner and the admin (me). But he can remove himself from the project.

Screen Shot 2015-08-13 at 16.41.19

In the settings tab the collaborator only can set the period in which he would like to receive notifications about this project.

Screen Shot 2015-08-13 at 16.41.09

The other settings are only visible for the project owner and the admin. I’m not sure about this. Maybe all settings should be visible for all collaborators and then just log who changed what. What do you think? I’m looking forward for feedback.

Dependency & License Management

Last week I did a talk about Dependency & License Management at theĀ Eurostaff Connect(s) – Berlin Developer Group. I was not able to do the trip to Berlin, that’s why we did the talk remote via Skype screen sharing.


I recorded everything with ScreenFlow, but unfortunately the recording was without sound. That’s why I did the presentation again and recorded it this time with sound šŸ™‚ Here is the presentation on YouTube:

And here are the slides on SlideShare:

Feel free to ask questions here in the comments.

New Notification Emails

VersionEye is currently tracking ~500K open source libraries. Most of them are library projects you can find on different repository servers such as RubyGems, NPM, Packgist and so on. VersionEye is tracking meta information about these software packages, such as version, license, description and so on. The VersionEye database is accessible via the search field on the landing page.

Screen Shot 2014-12-09 at 17.13.10

You can follow each software package by clicking on the “Follow” button. As soon a new version of the software packages comes out you will receive an email notification from VersionEye. Don’t worry. It’s not an email bomb šŸ™‚ If you follow many packages and more than 1 of them has new releases for today, VersionEye will send you only 1 single email with a summary. This email format just changed recently. Now it looks like this:

Of course it contains a list of the software packages with the current version. And now in the updated version also the current license in the brackets.

If your VersionEye Account is setup with GitHub/Bitbucket and VersionEye is watching some of your GitHub/Bitbucket projects as well, the email will include a sublist with the projects where you are using the software package.

Let us know how you like this new email format.