Rust Support

Rust is a blazingly fast new language which guarantees thread safety! Our latest project, a command line tool to identify random components by their SHA values, is implemented in Rust. As we use Rust for our own purposes we want to track Rust dependencies of course 🙂 That’s why added support for Rust now! VersionEye is tracking more than 9K Rust packages from now and they are all available through our public search.

Screen Shot 2017-05-04 at 08.59.58

Beside that VersionEye can parse cargo.toml and cargo.lock files. If you are using cargo to manage your Rust dependencies then you can let VersionEye monitore those files to receive notifications about new releases of your dependencies.

Screen Shot 2017-05-04 at 09.09.45

The above screenshot shows a Rust project which is monitored directly on GitHub.

This integration is still very fresh. Please try it out and give us feedback!

VersionEye Maven Plugin 3.11.1

Version 3.11.1 of the VersionEye Maven Plugin is out and here are the change logs. This release brings a couple improvements and BugFix!


Assume you have a Maven multi module project with 3 modules. Now you add the VersionEye Maven Plugin to the parent pom and run mvn versioneye:create. That will create a new project with subprojects in VersionEye. Now on your CI system on each build you run maybe this goal: mvn versioneye:securityAndLicenseCheck. That will always update the VersionEye project with the current dependencies from your Maven project and check them for security vulnerabilities and license violations. Everything works so far.

Now you are adding a new Maven module to your Maven reactor build and the next execution of mvn versioneye:securityAndLicenseCheck will fail, because it will try to update an non existing module on the VersionEye server.

This bug is fixed now! Version 3.11.1 of the VersionEye Maven Plugin can handle newly added Maven modules. If a new module is added it will automatically create a new subproject for that on the VersionEye server.

Improved Merging

For Maven multi module projects one project is created for the parent pom and for each module a project is created on the VersionEye server and merged into the project for the parent pom. This merging process was working through the GAV coordinates of the parent pom. That was leading to problems if the same project was monitored twice on a VersionEye server. The new merge mechanism is independent from the GAV coordinates, it only relies on the project ID from the VersionEye API.

Support for Project License

The VersionEye Maven Plugin is resolving all dependencies locally and only sends a pom.json file to the VersionEye API, which contains only the needed information. Now this pom.json file also contains the license from the pom.xml file and the project license is displayed in the web interface.

Screen Shot 2017-01-12 at 13.31.55.png


Open Source Component Inventory

If you are working in a big company with many software projects it’s very likely that you are using many open source components as dependency. But how do you keep track of it? How many components are you using in different version of multiple projects? You don’t know? This are questions VersionEye can answer you in seconds.

If VersionEye is monitoring your projects you can take advantage of the “inventory” feature. Simply click on the “inventory” link in your organisation and VersionEye will show you ALL the open source components your organisation is using over all the projects which are monitored by VersionEye. That can look like this.

Screen Shot 2016-10-19 at 22.21.53.png

It’s long list of all the components and below each component you can see which of you projects are using it in which version. If a project is using an out-dated version of the component the line is marked yellow.

Here is another screenshot with some comments to the meaning.

Screen Shot 2016-10-19 at 22.21.53 2.png

That’s already pretty cool because this open source inventory list is generated in real time, it always shows you the current status of your projects. But the really cool thing is that you can filter the inventory by different criteria like:

  •  Teams
  • Language
  • Project Version
  • Duplicates

Let’s make an example. Assume you don’t wanna see the full list of components, you are only interested in open source components which are used in 2 or more different versions over different projects. In that case you would select “All teams”, “All languages”, “All versions”, “only duplicates” and hit the “Filter” button. The result would like similar to this.


In the example above you can see that the component “versioneye-core-j” is used in 2 different versions over 4 different projects.

Now let’s say you only want to see duplicate open source components in the “developers” team. For that you would select the team “developers” in the first field and hit the “Filter” button. Here is an example.


In the example above not ALL projects in the organisation have been analysed. In this example only the projects which belong to the “developers” team have been analysed and now we can see that testng is used in 2 different version over 2 Java projects and capybara is used in 2 different versions over 3 projects.

Now let’s say you want to see the open source dependencies of a team over all projects, but if a dependency is used by another team as well you want to see that as well. For that you would select for example “Team: developers”, “All languages”, “All versions”, “Show duplicates” and hit the “Filter” button.


Now all the dependencies from the “developers” team have been analysed and in this example we can see that the component “versioneye-maven-plugin” is used by 2 projects in the “developers” team AND in addition to that in the last 2 rows we can see that this dependency is used by 2 other projects as well which are in a complete different team.

I hope this new filter options are helpful for your daily work. Leave a comment here if you have feedback.

Projects with multi file support

In modern software development it is not uncommon that you use more than 1 package manager for a software project. Maybe you are using Ruby for the backend and JavaScript for the front end. In that case you would use 2 package managers. Bundler/Rubygems for the backend and maybe bower for the front end. You would have at last 3 files for describing your dependencies. A Gemfile and a Gemfile.lock for your backend and a bower.json file for your front end.

Up to now a project on VersionEye was always a representation of 1 single file. For example the Gemfile. So if you wanted to monitor all 3 files you had to have 3 projects on VersionEye. Now a project on VersionEye can have multiple files!

Screen Shot 2014-12-23 at 11.21.47
If you click on a Gemfile in our GitHub integration, VersionEye will check if there is a corresponding Gemfile.lock in the same directory. If so, it will parse that Gemfile.lock as well and create a new project with 2 files.

In the dependency tab, the corresponding files are displayed above the dependency table. In this example the Gemfile is selected and we see the dependencies of the Gemfile. By clicking on the Gemfile.lock we can switch to the dependencies of the Gemfile.lock. It’s all in the same project view.

The overall numbers in the head of the page are summed up from all files in the project. That means over the 2 files there are 58 unique dependencies and 33 of them are out-dated. Also the dependency badge is summed up over all files. The dependency badge only turns green if ALL dependencies in ALL files are up-to-date.

But that’s not all. How do we get the bower.json file into this project? Let’s assume the bower.json file is already a seperate project on VersionEye. Now we can merge projects into each other. This is how it works. Let’s navigate to the desired project we would like to merge into our Ruby project. Navigate to the “settings” tab. Here there is a new input field which looks like this:

Screen Shot 2014-12-23 at 12.13.53
Here we can pick a “parent” project to merge in. By clicking on the merge button the current project will be merged as subproject into the selected project.

VersionEye-Multi-3Now we have a project with 3 files. Gemfile, Gemfile.lock and a bower.json file. The overall numbers are updated. Overall 3 files we have 59 dependencies and 33 are out-dated.

Under the file names there is a link “unmerge bower.json”. By clicking on that link the bower.json can be unmerged from this project. That means it will be removed from this project and be again a seperate project.

Pretty cool! Right? This is just the first step. In the next update we will bring this feature to the API and to the plugins as well 😉

Let us know what you think about this feature, either here in the comments or on Twitter.

New Project Notification Emails

Up to now VersionEye sent out one notification email for each of your projects. That was not the best solution, specially for power users with 100+ projects because they got A LOT of emails. The new version only sends out 1 single email with a summary.

Assume you have 100 projects in VersionEye. 50 of them are monitored daily, and the other 50 are monitored weekly. In that case you receive now every day just 1 single email with a summary about your daily monitored projects. That looks similar like this one here.

Screen Shot 2014-11-25 at 18.03.19
The Dependencies column shows how many dependencies in the project are out-dated and how many are unknown. The Licenses column shows how many dependencies violet the license whitelist and for how many dependencies VersionEye doesn’t know the license.

By clicking on the project name you come to the project detail page on VersionEye, where you can see all dependencies of the project with more details.

Now you get less emails and a better oveview.

New license crawler finds licenses in git repositories

VersionEye is crawling a whole bunch of package managers + some GitHub Repositories. Many open source libraries provide their license directly within the package manager. On the license information is even mandatory. If somebody submits a new package and the license information is not included in the pom.xml file the package will be declined and not published. That’s a good thing! Unfortunately at most other package managers the license is not mandatory and so it comes that we have many open source libraries in our database without a license 😦


But many projects on GitHub provide a LICENSE file. Other projects copy & paste the license text directly into their README page. That’s why I developed a new crawler which is looking for a LICENSE file in the root of a git repository. If some kind of LICENSE file was found the crawler tries to recognize the license text. Is it an MIT text, a GPL 3 text or some other license text? If the crawler recognizes the license text it saves the information into the VersionEye database. Otherwise not.
If there is no LICENSE file the crawler tries to find some license text directly in the REAMDE file. If the crawler couldn’t find anything it skips the repo and goes on to the next one.

The license crawler doesn’t crawl whole GitHub. It crawls only git repositories of open source packages which are already in the VersionEye database and have a corresponding link to GitHub. It basically completes meta data to already existing open source packages in the database. And right now there are 463.873 open source libraries in the VersionEye database.


In the past couple days the license crawler was able to find license information for 22.694 open source libraries. 5.684 of this open source libraries are JavaScript libraries registered on Bower, without any license information. One popular example is angular-mocks. The repository provides a bower.json file without a license! The license text of angular-mocks is directly embedded into the file. VersionEye found & recognized the license as MIT and displays it now on the corresponding VersionEye page. There are many more examples like this one.

Next Step

These works already pretty good. But the next logical step is to write a crawler which recognizes licenses in source code. That requires a bit more computing power and a bit more time to write it. Nothing for 2014. But a good goal for 2015 😉

VersionEye Maven Plugin 3.1.0

The VersionEye Maven Plugin is build for big multi module projects. If you have a big Maven project with a parent pom.xml and some modules, the VersionEye Maven Plugin is the tool of the choice to keep them up-to-date. We just released version 3.1.0 with many small improvements and some new features.

Multi-Module Projects

If you wanna see how to use the VersionEye Maven Plugin to setup a multi module project on VersionEye, check out this video on YouTube.


Now version 3.1.0 has support for Proxies. If your run your maven goals behind a proxy server, you can set “ProxyHost”, “ProxyPort”, “ProxyUser” and “ProxyPassword” now. Here is the code snippet for the pom.xml file.