Home > Artifactory, Java, Maven > Artifactory Online – the case of distributing Groovy++

Artifactory Online – the case of distributing Groovy++

After working with open source Artifactory version and thoroughly exploring it’s add-ons I knew it would come a moment to put my hands on its cloud solution – Artifactory Online. It just made sense to “close the loop” this way .. Тhe moment I’ve heard about online instance, running 24×7 without having to take care of anything – it sounded really, really nice.

I can’t say we spend a lot of time administering our open source version in Thomson Reuters. Quite the opposite – I only need to take it down for upgrades from time to time. But it still takes us a machine. A virtual one, of course but still – that’s CPU and memory that could be well spent somewhere else. So having online instance not only gives a peace of mind freeing everybody from taking care of one more server and one more database – it frees some hardware resources as well.

Well, a beauty of cloud computing, when it works. And Artifactory certainly does!

But my first use of Artifactory Online was for slightly different purpose – Maven support for the Groovy++ project. There was a clear need to host Groovy++ binaries in a public Maven repo.

What options are available today?

  • OSS repository hosting from Sonatype.
    It’s a good free solution but like any other free solution it only provides you so much: if you don’t mind being at mercy of other people with certain demands about how your POMs should look like – then it’s a good way to go. But I’d prefer my personal repository, where I can configure it the way I want without sharing it with other projects and asking favors. Also, bear in mind you get no security whatsoever – all your binaries would be open to everybody, anytime. And it only works for open-source projects which can be another showstopper.

  • Another option is to host a public Apache or nginx server and just make the files available following Maven’s naming conventions, like it’s done on "repo1". Not to mention the lack of security (again) – this kind of storage can be fragile to files corruptions: after all it’s just a dumb files storage, not an intelligent repo manager. You can’t use Maven to deploy artifacts and it provides no additional services, like virtual repos, artifacts searching or usage statistics.

  • Public hosting of open-source Nexus or Artifactory – it’s much better and we can finally protect it the way we want. But we still need to pay for hosting, memory usage, bandwidth usage and we now need to install and administer it on top of everything else. And put some extra protection, may be.

  • Artifactory Online. The best way to go, if you ask me. Not only it provides a cloud-based 24×7 running Artifactory instance, but it does so with all add-ons installed, so you really get it the ‘Full Monty’! It solves our original problem, to host binaries in a public Maven repo, but it doesn’t stop there, as I’ll show shortly – running a private Artifactory instance brings other advantages to your projects.

We’ve settled with last option, meet http://groovypp.artifactoryonline.com/!
The initial setup went very fast as there were very few things to take care of, actually:

  1. Registration

  3. Creating deployment user and "settings.xml". The fact that Artifactory provides a way to generate new “settings.xml” (skip to 00:10:40) and store an encrypted passwords (00:11:55) comes in very handy:

            <password>\{ABAeqq\}pIcMooZ8G/2Y2drgC99SDw==</password> <!-- Sample -->
  4. Instructing Maven about new repositories:


As you see, we’re using new repo not only for <distributionManagement> but as our only Maven repository.
From now on we only talk to groovypp.artifactoryonline.com/groovypp/libs-releases.
This is “virtual repository”, a “gateway” Maven will connect to for retrieving any 3-rd party library. I can now add additional Maven repositories by editing it in Artifactory, there’s no need to update the POM any more when new external repos are added to the project.

After this quick setup I ran it for the first time. I was expecting somewhat slower performance than the one we have in the office where Artifactory is running on the same network. After all, we’re talking here about remote repository running somewhere across the ocean:

But the download was pretty fast. It depends on the bandwidth, of course but I can’t say that significantly more distant repository has slowed me down. UI was very response and Maven’s filling of empty local repo was fast enough as not to notice any significant difference. Good!

Groovy++ project is now happily using Artifactory Online for several months and releases, you’re always welcome to download the latest version manually or give it a try with Maven.

What else can I say about running a private repo like that?

I think the main beauty of it is being able to “go public” in matter of minutes. No setups, no worries – you have your very own binaries storage, intelligent and secured that can be used for any purpose. That’s right, Artifactory can serve any binaries, not necessarily Maven’s artifacts. So one can store there practically anything and then secure or backup it safely.

Makes me think of various App Store services where people publish their Android / iPhone applications and enjoy the ride. That’s good, I believe “going public” should be easy for anyone today – this way creativity meets no entry barriers!

I only have a single request to Artifactory developers – an option to create aliases to existing repo. This would allow to reuse the same repository for different projects or purposes: http://projectA.artifactoryonline.com/ and http://projectB.artifactoryonline.com/ will point to the same Artifactory instance but will be used by different people.

Overall, a very pleasant experience!
Exactly what I was expecting – can’t help it but these guys never disappoint 🙂

  1. May 5, 2010 at 20:15

    In my opinion, the most important requirement for an open-source project’s Maven repository is the ability to sync with Maven Central. Is this possible with Artifactory Online?

  2. May 5, 2010 at 22:30

    From what I know Artifactory Online doesn’t provide a way to sync it’s uploaded Artifacts with “repo1”. It’s owned and controlled by Sonatype and anyone wishing to host artifacts there needs to talk to them. Right now I’m not aware of any other way to get there.

    But for me “repo1” isn’t that special as it is probably for other people. I mean, yes, people know it and check it first so it’s kind of comfortable to have one. But why do you think it’s *critical* for OS-project to be available there? Comfortable – yes (people don’t need to add one more <repository> to their POMs), but critical? I doubt so.

    If each project specifies exactly it’s repository location then I don’t care much about the URL. Besides, this centralized control of all artifacts isn’t something that I like much, to tell you the truth … What happens if Sonatype decides to pull the plug tomorrow?

    I wonder how it works with Ubuntu/Linux repos – what kind of control do they have there? Who’s authorized to add packages, how easy it can be done and how critical it is for the package to appear in master repo ( like http://packages.ubuntu.com/ )?

  3. May 16, 2010 at 16:34

    From my experience, not deploying to one of the big public Maven repositories is a significant barrier for adoption, especially for Enterprise use.
    If Sonatype pulled the plug, people would have to get the artifacts from the project’s own Maven repository, which has to exist anyway in order to be able to automatically sync with Maven Central.
    We use Artifactory at work, and I love it. But for my OSS project I don’t see much use for a repository manager. The project consists of just a few artifacts, and all dependencies are available from public Maven repositories.

  4. May 21, 2010 at 22:34

    I see your point. May be our experience is just different. We’re using lot’s of third party libraries and don’t really care whether their artifacts are coming from repo1 or some other place. If it’s some other repo, it’s just a matter of adding one more remote repo to our corporate Artifactory. May be syncing with repo1 is easy and lot’s of OS projects can do so. It’s just me who prefers having his own toys to play with 🙂

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: