Bio Shlomi Ben Haim is the CEO of JFrog. He is responsible for the company’s business and corporate development, strategic partnerships ecosystem and execution. Baruch Sadogursky, joined JFrog from the BMC Software Incubator team as the Developer Advocate following years of working alongside JFrog’s founding team.
Software is changing the world; QCon aims to empower software development by facilitating the spread of knowledge and innovation in the enterprise software development community; to achieve this, QCon is organized as a practitioner-driven conference designed for people influencing innovation in their teams: team leads, architects, project managers, engineering directors.
Shlomi:I’m Shlomi Ben-Haim of JFrog, I’m JFrog’s CEO for the last four years - one of the cofounders. Together with Frederic Simon and Yoav Landman we founded JFrog in 2008.
Shlomi: It really depends. We started the company with an open-source tool, so we have 15,000 open-source installations, including huge companies. But professional servers that we sell and key customers that we use are customers like LinkedIn, Netflix, Oracle, VMware and a bunch of them; all of them are detailed on our website. We are very proud of this list.
Baruch: I’m Baruch, I’m a developer advocate with JFrog. I work with the founding team of JFrog for seven years now. We all started in the Services Company and now we are all in JFrog and enjoying each other.
Baruch: We have two projects - both of them are very major for us. Artifactory was just there first. Artifactory has been there since 2006 and the other one, which is Bintray, is brand new, we released it a couple of months ago and are just at the beginning.
Baruch: Artifactory is a Binary Repository. Think about source control which is for the sources, but for Binaries not for source files. As a source control is very well suited for managing sources, Binary Repository is very well suited for managing Binaries.
Baruch: Git and Subversion are very good examples for something that people stored the Binaries and doing the wrong thing - for different reasons. Subversion stores the files by using diffs. Because the source files are text, they stack diffs one upon another and then they can analyze the diffs to get the complete picture of the source file. Binaries are totally different. First of all, they are not diffable; they are just BLOBS. They are just big pieces of Binaries which cannot be diffed, so Subversion cannot stack them one upon another. Versioning is also different because when you save different versions of the same source file, it has the same name and you just store the differences. When it comes to Binaries, each and every Binary with a different version has its own name; the version is on the name. So you end up with a huge Repository of files with the history one, which actually represent the same file with different history; it just doesn’t match.
With Git the story is a little bit different because Git doesn’t do the diff stuff; they save the file as a whole. But Git is a distributed platform, a distributed version control. Being distributed means that each and every developer machine has an own full Repository, which means that if you have a big Repository with your Binaries, each and every machine will have all the Binaries, even if it needs only part of it; and usually that is case. So we actually end up with thousands of huge Binaries on each and every machine and it’s not what you want. So the source systems, the source version controls are great; Subversion and Git both are very good tools, but just for another purpose.
Baruch: I’d like to start with saying that Sonatype Nexus is a good tool. It does its job, it’s a very decent Binary Repository, but we have our differences mostly in the place where it comes to integration with other tools. Sonatype guys has a very vast experience with Maven ecosystem. The guys behind Maven they are the guys behind Maven Central, and they are very, very Maven-centric. So if you use Maven maybe Nexus is a natural and a good place to go, but we think that the Binary Repository shouldn’t dictate the stack of your production and release life cycle. So if you want to use other build tools that Maven, if you want to use other build servers than Hudson, then you probably should pick Artifactory because we are just more open. We believe that your process, your company, your stack is the right thing and the Binary Repository should work with that and not vice-versa.
Baruch: We started by using Java Content Repository, and Java Content Repository is actually a NoSQL of the days where there was no notion of NoSQL; there was no such term. So the Java Content Repository is a JSR - is the Java Standard - which is not very popular. It actually, if I'm not in error, has only one implementation which is Jackrabbit. It’s a very interesting idea of Checksum Storage; it was there way before Git used Checksum Storage to store their files, and it’s served us very well for a very long time, until recently. At the end of this month, in the end of first quarter 2013 we are going to release our new major version, Artifactory 3.0, that is based on the same concepts of Checksum Storage and database metadata, but without the Jackrabbit, without the Java Content Repository code in it.
Baruch: It has a lot of stuff that we actually don’t need in Artifactory. So it has served us very well - it helps us getting started and served the right direction in terms of checksum-based implementation. But now we felt that it’s time for it to go; and we can actually do a better implementation for ourselves and we see the improvement of performance between Artifactory 2.66, which is very performant by itself, and Artifactory 3.0, which is the new version, in the order of magnitude.
Baruch: We used Wicket as a web framework. We love Wicket for being very not demanding of any web development skills. All of us, for some strange or maybe not reason, are backend developers. We love the server side backend Java and we are not very into web development, so Wicket served us well in just writing everything in Java and get the nice UI with AJAX and all its whistles and blows that modern web development takes, without actually getting very deep into it.
Baruch: No, Artifactory is a standard Java Web Application. All you need is servlet container, it could be Tomcat, it could be Jetty, it could be any servlet container. The default installation comes with embedded servlet container in it: if you use the Zip installer it comes with Jetty; if you use the RPM installer it comes with Tomcat. So it’s a very lightweight web application.
Baruch: One of the big benefits of Artifactory is our SaaS version, which we are very proud of; it’s called Artifactory Online. Everybody can get its own instance of Artifactory in the Cloud and we are taking care of several maintenance in the upgrades. And the upgrades are... You will get even better experience with our online version, than with the downloadable version because we release more frequently to the Cloud. We start with the Cloud, we have our continuous releases, frequently releases like each a week or two, and then once in a while we get enough new changes to get a downloadable version out of it.
Baruch: It depends on what you are trying to achieve. Basically the updates of Binaries are the job of your build tool. So once you have these dependency declarations inside your build tool, being it Maven or Gradle or Ivy or NuGet, whatever the build tool that you choose, you declare your versions there. And once you update your versions inside your build tools, the build server that actually runs the build itself, will ask for a new version from Artifactory. If they are there, they will be downloaded automatically to your build server; if they are not, Artifactory will reach external Repositories and bring the artifacts from there, caching them inside Artifactory for any future use. Another scenario maybe synchronizing Artifactory with remote Artifactory servers to be always up to date, and then maybe you will get a new version automatically once that the new versions are available on a remote server.
Baruch: Artifactory comes with built in licensing management, and licensing governance. It works very well for Maven projects. We know how to analyze a pom.xml to harvest the information about licenses from there. We then attach this information to the Binaries using the metadata mechanism of Artifactory; it stays forever binded with the artifact. And then we can decide what should be the action upon discovery of this license. We can notify the administrator by mail about new licenses that have been discovered; we can notify about licenses which are considered to be banned, etc, etc. In our latest version we are working towards implementing this mechanism with other tools other than Maven and it will work for Gradle and maybe Ivy, etc.
Baruch: This a very interesting and very fun part of Artifactory. You actually can write your own plugins in Groovy. They will run inside Artifactory class paths, so everything Artifactory can do, those plugins can plug into it. It can be a reaction to an event, for example new artifact get inside Artifactory, or new artifact get downloaded from Artifactory. It could be a scheduled event like: “I want to clean up some artifacts based on my very custom logic, once in a while”; or it could be even a triggered execution - I can reach my plugin and start it by a very simple REST API. And here actually the sky is the limit. We see so many interesting implementations of plugins: it could be rewrite rules - instead of getting the version 1, give me version 2, because it’s right for my project; it could be an antivirus scan - every time a new artifact comes into Artifactory, check it and see that it’s secure; it could be very strict policies - don’t let anyone download anything unless it has some flag which means that I approve it; this kind of stuff. So actually we see very different usages and we can think about even more usages. We have some GitHub project that released some interesting examples of users plugins, and it’s fun to see how interesting Artifactory usage can be using the user plugins.
Baruch: Yes, of course. We still have our open-source version; it’s very popular and we love our users no less than our customers. Shlomi will disagree but this is my perspective of it. It serves very well the most common cases of using Binary Repository. The pro version gives more in terms of integrating release pipelines into it and integrating different tools and different technologies into it, but the basic functionality of a Binary Repository is free, open-source and everybody is welcome to use it.
Baruch: This is our new product that we are very proud that finally it’s out, because we worked very hard on it. Bintray is a distribution platform; it’s open, social and Cloud software-as-a-service platform that you can think about as a GitHub for Binaries. You can upload any type of Binaries, any type of open-source Binaries, to it and users can download it using a very fast CDN. It integrates well with all the tools. The Binaries you upload are under your name, you get the credit, they can be reviewed and they can be voted. You can include your Binaries in different popular repositories, for example JCenter. You have your own Binary and you want everybody to be able to use it, you can include it in very popular repository and everybody will be able to download it. New realtime statistics that you can decide if you want them private or public. It should be very comfortable for open-source developers to share the fruits of their labour with the world. It’s not only Java: it works for RPM, for Debian, other formats will follow; and just a distribution platform for Binaries.
Baruch: I think Shlomi will do it better.
Shlomi: We are very excited to announce the partnership with Black Duck, which is a well known vendor for licensing control and management security, management and information. They have Code Center, another product that has a huge amount of information that they got over the last ten years and a very powerful knowledge base. So, together with Artifactory Pro version that already offers the third party license control and Black Duck information, the Code Center information, we can actually provide developers with the Artifactory user experience and the Black Duck knowledge base. So developers can finally have managers off their back; they don’t have to be scared from legal department or managers scared from violation - third party violation; and they will still have the light user experience that the developer tool offer.
Charles: Thank you both very much indeed.