Billing per Organisation

Another big refactoring is finished. Up to now the subscription model at VersionEye was bound to a personal user account. That caused especially confusion in the context of organisations. As all projects are organised in organisations now, it makes sense to do the whole billing per organisation as well. Now every organisation has his own plan, billing address and payment history.


The section for plan, billing address and payment history is only accessible for the owners / admins of the organisation. Every user who is in the “Owners” team can change the plan and billing address of the organisation.

This refactoring especially makes sense for companies because they have now a really good representation of their organisation at VersionEye. They pay for the number of private projects + API calls and they can invite as many collaborators as they want.

The plan / subscription model is not available anymore for users. All plans and projects have been migrated to organisations.

API Key for Organisations

Up to now, every user could generate an API Key for the VersionEye API and every key was attached to a real user in VersionEye. Many teams asked how they should handle an API Key for Jenkins, TravisCI, CodeShip, CircleCI or any other CI system where a VersionEye plugin is used at build time. So far a completely new user was created and added to the corresponding team and the API key of that user was used at the CI system to communicate with the VersionEye API. That was kind of a workaround because nobody wanted to share their personal API key on a server.

Now every organisation at VersionEye has a separate API key!


This API key is NOT attached to a real user in VersionEye. That means it can not be used to login to the web application. This API key is visible for the organisation owners only! With the API key of an organisation, all CRUD operations for projects inside of the corresponding organisation can be performed.

That way it’s even easier and more secure to use the VersionEye API. If you have questions to this new feature feel free to leave a comment here.

Organisation by default

VersionEye allows you to organise your projects in organisations and teams. Up to now, this was an optional feature. By default, if you created a new project in VersionEye it was attached to your user profile and optional you could transfer the project to an organisation if desired. That caused some confusion, especially because the cool features like license whitelist, component whitelist and teams are only available in an organisation. That means that by default a new user doesn’t get this cool features to see.

Now organisation is turned on by default. For every new user who signs up  a new organisation is created and after the login the user is redirected to the projects inside his/her organisation. If a user is part of multiple organisations the first one is picked where the user is in the owners team. Of course you can switch your organisation every time through the “Organisations” main menu.

Screen Shot 2016-07-15 at 13.52.31

In the “Projects” main menu all projects overall organisations can be viewed, but the side menu disappeared from the left side. That’s not a bug. That’s by purpose. New projects can be created now from inside of an organisation only. That way every new project is attached to an organisation.

For all the existing users who are not yet part of an organisation we created a new organisation which has the name of the user with the prefix “_orga”. Beside that all projects who has been attached to user profiles have been migrated into the corresponding organisation. By now ALL projects belong to an organisation object in VersionEye. If something went wrong at this migration please contact the support at

Showing sync status in VersionEye Enterprise

If you start your own instance of VersionEye, like described here, your locale VerisonEye database is empty. If you create a new project in your locale VersionEye then all the project dependencies are displayed as UNKNOWN, because the database is empty. In the background, your locale instance will start fetching the missing meta information from the public VersionEye API and store it in the locale database. After the sync process is finished the project will be reparsed and the open source dependencies are displayed correctly with the current versions and licenses.

Up to now, there was no feedback in the UI about this background process. Now in the project detail view a sync box shows up which shows the status of the sync process.

Screen Shot 2016-07-12 at 17.58.12

Now the background process is visible and it even shows which dependencies are synced currently. Depending on the number of the dependencies this sync process can take a couple minutes.


New Team Permission

VersionEye has a concept of Organisations & Teams. That is specially useful for bigger teams and corporations. Up to now only the owners of an organisation could add new members to a team. But sometimes you want to enable everybody in the team to add new team members to the team. Now that is possible! On the organisations detail page there is a new checkbox for that.


If that new checkbox is checked, every team member can add new team members to his/hers team without being an owner of the organisation.


We hope this new feature is valuable for you.

VersionEye Maven Plugin – Transitiv Dependencies

Version 3.10.0 of the popular VersionEye Maven Plugin is out! This new release brings a new feature to the plugin. Now with this optional configuration parameter:


he plugin will resolve ALL direct AND transitive dependencies and send all of them to the VersionEye API. By default this is turned off. If this new option is turned of the plugin will only send the direct dependencies to the VersionEye API and the result might look similar to this one.


If the transitivDependencies option is turned on the scopes are ignored. The plugin will create 2 scopes, 1 for the direct dependencies and 1 for the transitive dependencies. The result will look similar to this one:


This configuration option also has some implications to other configuration options. If transitiveDependencies is true then the configurations optionsignoreDependencyManagement and skipScopes are ignored.

Try out this new release and feel free to open a ticket on the GitHub repository if you find any issues.

Auto merge for Git projects

Nowadays modern software projects are using multiple package managers at the same time. It’s very common to use for frontend dependencies and NPM for dependencies on the server side. So it comes that the same Git repository contains a bower.json and a package.json file. Both can be monitored by VersionEye. Up to now if the switch was flipped in our Git interface that created always a sperate project at VersionEye and there was a manual step involved to merge the 2 projects to 1 logical project.

Screen Shot 2016-06-29 at 15.09.17.png

The new behavior is that VersionEye is checking if there is already an existing project for the corresponding user from the same SCM provider, same repository and same branch. If all that is true the new project will be merged automatically into the existing one. The 2 flipped switches from above would result into a project with 1 child project like here:

Screen Shot 2016-06-29 at 15.09.50

Of course a subproject can be unmerged again into a separate project. But most of the time this behavior makes sense.