Today we released the VersionEye Maven Plugin 3.10.2. This patch release is fixing a bug which occurred on big multi module projects, where sometimes the project_id couldn’t be found. Beside that the logging is improved. Now the plugin will log out at which places it is looking for the project_id. That way it’s easier do debug if something goes wrong.
VersionEye had already support for 12 package managers and now we are adding Nuget, the package manager for the .NET platform from Microsoft! As Microsoft Windows is all about continuous updating, Microsoft will like VersionEye very much, because VersionEye is continuous updating for .NET packages 🙂
With fixed releases and snapshots together VersionEye is currently monitoring more than 70K open source .NET packages on Nuget. Here are the numbers from .NET / Nuget compared with package managers from other languages.
The above chart can be viewed on the VersionEye statistic page and is updated once a week. The numbers representing projects in official package mangers. Random OS projects on GitHub/Bitbucket are not taken into the calculation! Currently the C# .NET community has less open source packages than the Python, Ruby, PHP, Java or Node.JS community. As Microsoft changed their open source strategy a couple months ago, this might change in future. But this is the status quo!
Every .NET package has his own page at VersionEye, like this one for example.
Now you can follow any .NET package at VersionEye and you will receive an email notification as soon a new release for that package is available. But that’s not all. VersionEye is showing the most important KPIs to the package in the right upper corner. KPIs like average release time, external references, the license of the package and a dependency badge which can be integrated into README pages at GitHub, GitLab and Bitbucket.
VersionEye is also creating author profiles for the contributors of the open source libraries. By clicking on an author icon on a package detail page the author page shows up. Like this one for example.
On the author page you can see to which other .NET packages the author contributed to and what his/her keywords are. The keywords are clickable as well. This is for example the keyword page for JSON.
The keyword page can be filtered down by language and now C# is on the filter as well.
But the coolest feature is that VersionEye can monitor a Nuget project in your Git repository and notify you about out-dated dependencies and license violations. Now VersionEye can monitor project.json and *.nuspec files on GitHub, Bitbucket and Stash.
For monitoring one of this files, simply flip the switch in our Git integration view. The project report looks like that.
It’s that easy to get notified about out-dated dependencies and license violations 🙂 Projects like this one can be created and update via the VersionEye API as well. There already many native VersionEye plugins for build tools and package managers like Maven, SBT, Gradle and NPM which are using the VersionEye API. I’m looking forward to see some native VersionEye plugins for the .NET platform as well 🙂
2 Things are still not finished for the .NET integration and are still ongoing.
- Release Dates: On some packages you will see “Release 116 years ago”. Of course that is wrong 🙂 On some packages the release date was not set correctly. Currently a background job is running which is fetching the release dates from an alternative source.
- License Names: The Nuget API doesn’t expose license names, only links to licenses. Currently we are working on it to resolve the links to meaning full names. For a couple thousand packages this is already done but for the majority this process is still ongoing.
The .NET integration in VersionEye is pretty fresh. We rely on your feedback! Please test it and let us know if something is wrong. You can reach us on Twitter or simply open a ticket at GitHub. By the way. VersionEye itself is open source. Pull requests are welcome 😉
Now VersionEye has support for Chef! VersionEye is crawling supermarket.chef.io at least once a day and is able to monitor your Berksfile, Berksfile.lock and metadata.rb file on GitHub, Bitbucket or Stash.
If you are an Ops or DevOps working with Chef, feel free to try out this new feature. Feedback is very welcome 🙂
By clicking on the feedback icon a modal dialog appeared where you could send a message to the VersionEye Team. We received your feedback as email and it was not visible to anybody else. Many times we received a bug/feature report multiple times. Simply because many users found the same issue.
A couple days ago we changed the behaviour of the feedback icon. Instead of opening a modal dialog it redirects the user to the ticket system on Bitbucket.
Why Bitbucket? Why not GitHub?
The code for VersionEye is splittet up in over 10 git repositories. For long time we hosted everything on GitHub and we used internal the GitHub ticket system for ourselves. There are 2 reasons why we moved some repositories to Bitbucket.
- On Bitbucket you can make the ticket system public and at the same time keep the source code private.
- The Ticket system on Bitbucket is a little bit more advanced. Specially the “vote” feature is very useful for communities. That way users can vote for a ticket and we can sort the tickets by votes. That is very useful for new feature requests. Now we don’t have to guess anymore which feature to implement first. We simply implement the features first with the most votes!
We still have code on GitHub and we are still paying customers of GitHub. Simply because the performance of GitHub is better. A ‘git push’ or ‘git checkout’ works on GitHub always a couple seconds faster than on Bitbucket. With git you can have multiple backends without a problem 🙂 That’s why we all love git!
We hope you will embrace our new open ticket system and we will see many features requests and votes in future 😉
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!
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:
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.
Gradle is becoming more and more popular and we are getting more and more emails to our Gradle support. If you work with Gradle you define your dependencies usually in a “build.gradle” file. A dependency definition can look like this:
compile group: 'org.apache.pdfbox', name: 'pdfbox', version: '1.8.5'
This definition works since longer with VersionEye. What didn’t worked was for example this:
// compile group: 'com.artofsolving', name:'jodconverter', version:'2.2.1'
If you commented out a line in your gradle file VersionEye parsed it anyway. Since today this is fixed!
Another cool feature in Gradle is that you can define variables. For example to hold version numbers. Here are some variable definitions:
project.ext.hibernateCoreVersion = '4.1.9.Final' project.ext.jerseyVersion = '1.17' project.ext.springDataJpaVersion = '1.4.1.RELEASE'
And here is another way to define dependencies as Arrays:
[group: 'org.hibernate', name: 'hibernate-core', version: hibernateCoreVersion], [group: 'org.hibernate', name: 'hibernate-entitymanager', version: hibernateCoreVersion],
In the above example you can see that instead of using a static version number, we use the variable we defined before. This variable declaration and defining dependencies in an Array is now supported by VersionEye as well!
Gradle VersionEye Plugin
Beside the improved support for Gradle files we recommend to use the Gradle VersionEye Plugin. It resolves the dependencies locally and is well suited for more complex Gradle build files, for example with submodules. The plugin sends the locally resolved dependencies to the VersionEye API to create/update a project on VersionEye. Our Enterprise clients are using this (Or the Maven) Plugin to keep their projects up-to-date.
You can run the plugin every night on your CI System to update the corresponding VersionEye project with the current dependencies. VersionEye will check the dependencies and send out notification emails if some dependencies are out-dated.
Let me know if you have questions to this. Either here in the comments or on Twitter.