VersionEye Maven Plugin 3.2.1

Just released version 3.2.1 of the VersionEye Maven Plugin.

This version is a patch release! If you run “mvn versioneye:create" in a multi module project on the parent it might be that the parent pom.xml doesn’t has any dependencies. The default behaviour of VersionEye is to skip projects with 0 dependencies. In a multi module project this behaviour causes the error that the submodules can’t be merged into the parent project, because the parent was skipped because it has 0 dependencies.
This Bug is fixed now!

VersionEye Maven Plugin 3.2.0

This week version 3.2.0 of the VersionEye Maven Plugin was released!

You need the VersionEye Maven Plugin if you want to track multi module builds with VersionEye. The plugin runs inside your Maven build lifecycle and resolves all dependencies & variables natively with the maven-core project. It is the best way to track Maven projects on VersionEye!

You can use the plugin by simply adding this code snippet to your pom.xml file.

<build>
  <plugins>
    <plugin>
      <groupId>com.versioneye</groupId>
      <artifactId>versioneye-maven-plugin</artifactId>
      <version>3.2.0</version>
      <configuration>
        <apiKey>MY_SECRET_API_KEY</apiKey>
      </configuration>
    </plugin>
  </plugins>
</build>

You can find more information about the API Key here.

The current version brings many small improvements and much more configuration options! Find here the change logs. I want to point out 2 changes.

Scopes

The plugin resolves ALL dependencies & variables locally and creates a pom.json document, with all the relevant information for VersionEye, and sends it to the VersionEye API. Now the scopes of the dependencies are send to the server as well! And in the Web interface the dependencies are divided by scopes.

Screen Shot 2015-02-25 at 11.13.50

Set parent project explicitly

Executing “mvn versioneye:create” on a multi module project will merge all submodules into the parent project on the server, by default. By default the parent project is determined from the pom.xml. Here is an example. The maven project on GitHub has a parent pom.xml file in the root and a couple submodules. The pom.xml files of the submodules reference as parent the pom.xml file in the root directory.

Screen Shot 2015-02-25 at 11.23.13

This is kind of normal. Many multi module projects have this structure. Executing the VersionEye Maven Plugin on this project would create a single project on VersionEye and each module would be a “subproject” on VersionEye. The advantage of this is that you have everything in one single view and the numbers for dependencies and licenses are summed up over all submodules. It looks like this:

Screen Shot 2015-02-25 at 11.35.59

If you wish to remain each submodule as separate project on VersionEye you can turn of the merging with this line in the plugin configuration:

<mergeAfterCreate>false</mergeAfterCreate>

This is all kind of default. But what happens if one of your submodules references a parent project which is in a complete different git repository? It’s not part of the current maven build. And maybe the referenced parent project is even not available at VersionEye. In that case the merging would fail because VersionEye tries to merge an existing project into a non existing project. In this case you could turn of the merge with the configuration above. That would be a quick fix.

But what if you want to merge each submodule into the maven project which is described with the pom.xml in the root directory? That is not the parent which is set as parent in the submodules pom.xml. But maybe you still want to enforce this logical structure on VersionEye! With the current version of the plugin you can enforce into which project on VersionEye the submodules should be merged, by simply setting the parent GA explicitly in the plugin configuration.

<parentGroupId>your.parent.groupid</parentGroupId>
<parentArtifactId>your.artifactid</parentArtifactId>

This is not a theoretical case. It’s a real problem which happened to some VersionEye users. With the current version of the plugin this problem is solved now!

Let me know if you have questions to this. I’m happy to help!

Improved Crawlers for Maven – jCenter, Atlassian, Adobe

VersionEye is crawling a bunch of repositories like RubyGems, NPMRegistry, Packagist and many more. For Java we crawled for long time only search.maven.org. Simply because it provides an maven index to download and that makes it really easy to get the data into our database! Other maven repositories don’t provide a maven index and that means we need to do some heavy xml parsing! Simply doubling the number of our EC2 instances is not an option because currently we don’t swim in Money! In the last weeks we worked hard on performance improvements for the non-maven-index maven crawlers. And because the work was successful we are happy to announce that VersionEye supports this maven repositories as well:

Now VersionEye tracks 123K Java projects with 1.37 million artefacts!

VersionEye Maven Plugin 3.1.1

Version 3.1.1 of the VersionEye Maven Plugin is out. It brings improvements for multi module projects and a better handling of error messages.

  • Better error messages: Until now the plugin did not handle error messages from the server. If the API was not available the build just failed with a random Exception. The current version handles the response code from the API. If the server responds with an error message it will be displayed in the command line as well!
  • Multi Module Builds: In a multi module project the plugin created a separate project for each module. This behaviour changed in this version. Since VersionEye supports projects with multiple files the plugin creates always only 1 single project! If it is a multi module project, each module is a “subproject” in the VersionEye project.

You can find the source code on GitHub: https://github.com/versioneye/versioneye_maven_plugin.

Give it a try and let us know what you think.

Merge Projects via the VersionEye API

Round about one month ago we released a new feature which supports multiple files in one project. That is useful for almost every modern software project. Some package managers, such as Bundler, Composer, CocoaPods and others, generate anyway 2 files per project. Beside that many modern software projects are splittet up in frontend and backend. And many times there are different technologies and different package managers involved to handle the open source dependencies. That’s why it makes a lot of sense for VersionEye to support multiple files per project.

In the Web Interface you can merge already existing projects into another project. And of course you can “unmerge” them if you like. Now this 2 functions are available via the API as well.

Screen Shot 2015-02-05 at 11.42.12

Assume you have 2 projects with each 1 file. A Java project (ID: 222) with a simple pom.xml file for your backend and a JavaScript project (ID: 333) with a bower.json file. But actually it’s the same project and you would like to merge them on VersionnEye to have everything together in one single view. With this call on the API you would merge them:

/api/v2/projects/222/merge/333?api_key=YOUR_API_KEY

In that case the Java project would be the parent and the JavaScript project would be the child. If you merge them the first time the order doesn’t madder. The other way around would work the same way.

If you would like to split the 2 projects again you could do it with this call:

/api/v2/projects/222/unmerge/333?api_key=YOUR_API_KEY

Easy! Right?

There is even a third new endpoint. This one:

Screen Shot 2015-02-05 at 11.55.14

This endpoint is specially for the VersionEye Maven Plugin. On a multi module project the VersionEye Maven Plugin gets executed several times and there are multiple lifecycle runs involved. Because of the maven architecture the VersionEye Maven Plugin doesn’t know always the VersionEye ID of the parent project. That’s why this endpoint got introduced, to identify the parent by groupId and artifactId. These 2 coordinates are always available in the Maven lifecycle.

Try out the new Endpoints and leave a comment if you have questions.

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.

Proxy

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.

<build>
  <plugins>
    <plugin>
      <groupId>com.versioneye</groupId>
      <artifactId>versioneye-maven-plugin</artifactId>
      <version>3.1.0</version>
      <configuration>
        <proxyHost>127.0.0.1</proxyHost>
        <proxyPort>8888</proxyPort>
        <proxyUser>proxy_hopsi</proxyUser>
        <proxyPassword>dont_tell_anybody</proxyPassword>
      </configuration>
    </plugin>
  </plugins>
</build>

Scala SBT Support

We just added another package manager to our list. Now VersionEye supports Scala SBT. Now VersionEye can monitor your build.sbt file on GitHub or Bitbucket and notify you about out-dated dependencies in your Scal project.

All you need to do is, login to VersionEye with your existing GitHub/Bitbucket account and navigate to your repository. Simply flip the switch beside your build.sbt file you would like to monitor.

Screen Shot 2014-09-15 at 10.50.42

After the file was parsed successfully the name turns into a link. Simply click on the link to see the out-dated dependencies.

Screen Shot 2014-09-15 at 10.51.02

Now you can see immediately which of your dependencies are out-dated and what would be the newest version number. By default VersionEye checks your project once a week and notifies you about out-dated dependencies in your project via email. Of course you can change the frequency in the settings.

But even better, if you click on the link “Visual Dependencies” VersionEye shows you ALL your transitive dependencies as JavaScript wheel.

Graph

As bigger the graph is, as more complex your project is. Try to keep it small 😉

The Scala SBT support is quiet young. Please let me know how it works for you. Your feedback is highly appreciated.

Integration for Pentaho

Pentaho is a comprehensive Platform for Data Integration & Business Analytics. They are quiet popular in the Java Community and used by big companies like Telefonica & Lufthansa. 

pentaho-logo-cmyk

They are hosting their own Maven Repository here: http://repository.pentaho.org/artifactory/pentaho. We just added this repository to our Crawling Framework. 480 Pentaho Java Packages are now are now available at VersionEye! We crawl the Repository once a day. You can follow the packages and you will get notified about new versions via Email. And of course the packages are now known in your Maven/Gradle projects as well! 

By the way. The Pentaho World 2014 Conference is at October 8 – 10. For the next 2 weeks they offer an Early Bird Pricing! Check it out here

VersionEye started its first Meetup group “Geek2Geek”

ImageGeek2Geek is a monthly Berlin Tech Talk. Our goal is to bring software developers with a diverse background together. We noticed that the coding community is often isolated, meaning that PHP devs. are only going to PHP UG’s and Java devs. solely to Java UG’s

However, we believe that we could achieve great things if we connect. If you’re a open source developer, start-up, techie, or geek using Java, Ruby, Python, Node.JS, PHP, JavaScript, R or Clojure, this group is for you!

Our first meetup is on July 23, 2013 and we’re pleased to announce that the speakers for our first Geek2Geek meetup are Christoph Beckmann from KaufDA and Tobias Balling from BLINKIST. This time we will focus on “IT infrastructure for DevOps”.

Christoph Beckmann
Christoph is team lead at KaufDA. He’s developing preferably with the Grails framework and is a DevOp expert. Over the past 2 1/2 years he has helped build the international KaufDA IT team. Previously, he gained experience at a consulting firm in Cologne and founded Germany’s first toilet search engine. Christoph will show how KaufDA manages its infrastructure with puppet in 5 countries.

Tobias Balling
Tobias is CTO at BLINKIST. He’s is currently thinking about the perfect presentation topic. So, more details are coming soon!

Thanks to VersionEye, snacks and beer are available for free, while supplies last. We’re looking forward to meeting you!