Fixing Corrupt Metadata in Artifactory (and my thought process behind it)

Background:
At work, I was recently introduced to the maven archetype plugin. I used it to generate a sample project containing generated client code that interacts with our framework. After working on it for a while and deploying it (successfully) to Artifactory (version 2.0.1), I was excited to show it off to my colleagues. Right around that time, we decided to upgrade the version of Artifactory to 2.2.4. The steps we followed were: Use the web console on the older version to run a Full System Export, Download the latest version to another location, Start up the new version, Run the System Import on the new version with the imported file. Everything seemed to run fine, until a guy tried my code and it failed!

Error:
My code invoked the generate goal using the maven-archetype-plugin. And this is the error that it spewed:

mvn -e archetype:generate -DgroupId=test.sonali.parikh -DartifactId=1.0 -Dversion= -DarchetypeGroupId=aero.sonail.parikh -DarchetypeArtifactId=sonali-sample-project-archetype -DarchetypeVersion=1.0
+ Error stacktraces are turned on.
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'archetype'.
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Required goal not found: archetype:generate in org.apache.maven.plugins:maven-archetype-plugin:1.0-alpha-7
[INFO] ------------------------------------------------------------------------
[INFO] Trace
org.apache.maven.BuildFailureException: Required goal not found: archetype:generate in org.apache.maven.plugins:maven-archetypeplugin:1.0-alpha-7
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.getMojoDescriptor(DefaultLifecycleExecutor.java:1558)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.segmentTaskListByAggregationNeeds(DefaultLifecycleExecutor.java:405)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:137)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)

Analysis:
Looking at the stack trace, this is valid error IF I was using version 1.0-alpha-7 and NOT 2.0-* of this maven plugin artifact. The 1.0* version does not have support for the generate goal, since it was only introduced in the 2.0 releases.

But, since I didn't specify the version of the plugin to be used, the Artifactory server should serve me the latest and greatest version. So, I should have been pulling down the latest 2.0* version from the remote artifactory server (I check, our Artifactory does serve up the 2.0-alpha-4 version). OK so, something's wrong with the process used by Artifactory to maintain its versions.

I browsed through my local m2 repository, and discovered this file maven-metadata-central.xml . This file is downloaded to the local file system as part of the maven-local-client-talking-to-the-remote-repository. It basically looks like this:
...
<?xml version="1.0" encoding="UTF-8"?>
<metadata>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-archetype-plugin</artifactId>
<version>2.0-alpha-4</version>
<versioning>
<latest>1.0-alpha-7</latest>
<release>1.0-alpha-7</release>
<versions>
<version>2.0-alpha-4</version>
<version>1.0-alpha-7</version>
<version>2.0-alpha-3</version>
</versions>
<lastUpdated>20100723072443</lastUpdated>
</versioning>
</metadata>
...

This file is not quite correct - the value of the latest tag should have read 2.0-alpha-4.

And this was indeed the bug - when I manually hacked this file in my local repo (location: C:\.m2\repository\org\apache\maven\plugins\maven-archetype-plugin\maven-metadata-central.xml) to contain the correct version, and downloaded the 2.0-alpha-4 jars and pom to my local repo, the maven command worked wonders (my code of course). So somehow the metadata was incorrect or corrupt and had to be re-generated for this artifact.

Cause:
The metadata (served up by the remote Artifactory server to a local maven client) getting corrupt/wrong might have been a by-product of the full system export, which was one the steps involved in upgrading artifactory to 2.2.4. This is sort of a known bug as of April 2010 according to this jira ticket - they say the patch fixed it, but I haven't tested the patch yet.

(My Hacky) Solution:
I didn't want to patch it just yet, so I decided to delete the 2.0-alpha-4 jar and pom from the Artifactory server repositories and re-deploy them. This workaround made the regenerate-metadata-process actually work, and the latest version was correctly downloaded on my local box!
My colleague also tested another workaround - While upgrading to 2.2.4, check the "Exclude Metadata" option while doing the full system export. That helps too!

So Why Am I Blogging About This:
Well, I spent quite some time wondering my code didn't work and why the generate goal was suddenly not a valid goal! So if anyone spends more than an hour, trying to figure out weird latest-versions of artifacts, just try and regenerate the metadata.

scmple

Tagline - This should be easy. We think it should be simple.

Scmple is my (oops our) new pet-project. What I am referring to as this and it are common problems we all face working as part of a small team on a small project. We, as part of the scmple team, want to help you to iron out these problems. We hope to make it easier for the developers to spend more of their time and effort on developing software and less on (painfully time-consuming but much-needed) administration.

Here is a typical scenario that inspired us to come up with this idea - Person A has an awesome idea, it's going to be The-Next-Big-Thing! Person A codes away at night for a few days and brags about it to Friend B. B is now all fired up and volunteers his supreme comp sci development skills. So A and B work on this new side project (lets call it TNBT). Being developers, they know they have to use a versioning system and pick SVN or CVS or Git and they start coding away. They face a few hassles along the way - who works on what feature, who fixes which bug, is there a trail of all the bug fixes (aside from versioning history), who is tracking the project milestones, what is the future feature set..but they ignore them for the time being since having functional and working code is more important. Friend C also wants to join them. So as a small team, A, B, C have to collaborate on working on TNBT and to make progress, some of the hassles need to be addressed. Keep in mind that the only time they get to work on their dream project is after-work hours and on weekends. Hence the time that they actually spend on working together is very precious. They need to be able to use this time wisely and not in integrating and organizing three to-do lists with 100 bullet points and spreadsheets containing a complex matrix of which person is assigned to which task. What this team needs is a simple, straight-forward solution that offers them project management, task management, work assignments, issue tracking, discussion forums.

Scmple to the rescue. What we hope to achieve here is to simplify the process of product and project management. I know that developers dislike the word management, but to make your product even a tiny bit successful, you need to be able to manage it efficiently. Scmple will provide a hosted platform for versioning, with a built-in feature set like issue tracking, task management, project milestones, discussion and support forum. It's designed to integrate effortlessly with your development enviroment so that writing code and managing a project go hand-in-hand.

Technology - Open Source is the way to go. We decided to use Git as the version control system (read my blog post), Ruby on Rails and PostgreSQL, with a lot of AJAX goodies thrown in. We are looking at a variety of solutions and mayyyyyybe mootools is winning.

We are working on getting a beta version out soon. Will keep you guys updated!

Moving on to another job

This post comes a little late, but better late than never! After having spent a little more than a year at SITA, I decided to leave. Just yesterday, I finished my first 2 weeks at Premiere Global.

There were a number of reasons for this transition. I have had a good time at SITA, I like the people I worked with and I learnt a lot from them. The main reason for this move was that I felt like I wasn't challenged enough. I wanted to learn something new, work on something exciting. The projects that I had been working on for about a year were sort of coming to an end, and I guess I wanted a change. It was a little hard to leave since I am emotional and very loyal to the company but everybody understood my reasons to leave. So after a farewell lunch at a hibachi grill and a going away gift (a cute pineapple plant), my last day at SITA was over.

A couple of friends recommended Premiere Global Services (or PGI as we lovingly refer to it) to me. And hopefully vice-versa! I have been wanting to get into working in a web services environment and it sounded like PGI was working on re-designing their eMarketing to use a web-services-based framework. I interviewed with the team a few weeks ago and it seemed to be a good fit.

So here I am - 2 weeks into PGI and loving it! The guys in my team are real smart, I get to learn something new every single day and I have already written code and checked it in! Awesome!

Ubuntu vs Mac OS

So I recently bought an iMac, and I love it! I still have my dell laptop which has Ubuntu on it. Funny thing is that I recently switched over from OpenSuse to Ubuntu. IMO Ubuntu was easier to install from OpenSuse. Of course taking into account that I had installed OpenSuse on a purely Windoze box, all the fun stuff involving partitioning was already done for me. Anyway I did spend a few weeks with Ubuntu installing software and configuring my desktop so I do have some sort of an experience with it.

So If I have a laptop, why do I need another personal machine??
I have always wanted a machine with Mac OS on it. I used the Apples sparingly at Emory, but never truly got the hang of it. Ever since my husband got a mini, we sort of started replacing all our machines at home to either Apple TVs or Mac minis. I never really had the need for another machine since my Dell was good enough for all my side-project development machine. Or let me rephrase - I was happy with my laptop for the last 4 years. I do have a few issues with my Dell right now - I can't test out my web apps on Safari/IE/FF, Its not very fast (tops out at 2G RAM), I don't have a fancy text editor(tried to pimp up gedit to emulate textmate), and well I really wanted a change in my OS.

This last weekend was the tax free weekend. We stood in line at the apple store and were taken care of pretty quickly. After 20 minutes, I was the proud owner of an iMac **and** a free iPod touch! The iMac, designed by Apple in California, is a simply amazing design - the monitor has the entire computer inside it and its still not that thick. The speakers are not bad and I have enough USB ports on the back of the monitor - very sleek.

Once you get the hang of using an Apple machine with the funky Mighty Mouse, and learning your way around the Expose and the million keyboard shortcuts, its a pretty straight-forward OS to interract with. The only thing I might want to complain about is the lack of focus-follows-mouse support in the windows manager. Ever since my school days of playing around with Enlightment, I have been addicted to this very customized preference.

Anyway, other than that, here is a list of differences I see between Mac and Linux -

1. Ease of installation of software - On Linux, installing a software or application is not the most complicated process, but it takes time - the basic steps are downloading the binary or the tar ball, unzip it, make it, and then copy the files over to /the/proper/location. On an Apple, all you do is download the mac-os-version and copy it to Applications. Thats it - how easy is that.
2. The Dashboard - On Linux, you would probably need to start up all these applications in a different desktop - there is no dock like functionality. On an Apple, its always there at your beck and call . I like using it without the need to crank up the date app or the calendar app or the weather app.
3. Fluid - There is no way that I can explain how convenient SSBs are!! I have facebook, hahlo, jango, zimbra mail all opened up as its own little application. There are neat scripts that make the GUI look better and I don't have to bother about whether one app might cause a crash in another. So sure, I could open up different sessions of FF but it is not the same experience. Also, fluid is based on the Safari technology, its a lot faster.
4. TextMate - Eclipse is way too bloated to code. If I am not writing java code, Eclipse is more of a hassle to use than anything. Textmate is so easy to use, so many different templates and such a simple interface.
5. iTunes - I have tried to use amarok to sync my ipods. It hasn't been a complete disaster but its not intuitive. iTunes does it the best!
6. Prettier fonts/design/layout/shadows/GUI - Need I say more - its just prettier!
   

Hopefully I can code up the next-earth-shattering application on my new beautiful desktop, and then this purchase would be justified!

Grit Documentation

Grit is a Ruby library for extracting information from a git repository in an object oriented manner.

I am trying to use grit for a simple project - basically provide a GUI for git. Eclipse does a good job for CVS and SVN and gitk doesn't do a good job with git. It sounds like a good idea, and I really am all for git. Other than a few irritating things about merge, git is a pretty kewl tool.

So for this simple project, I am using mojombo-grit (and Ruby on Rails) to look at the tree/branch structure of git commits. Its pretty straight-forward but the API documentation is not that great. Its just not laid out intuitively and IMHO not easy to understand to follow. I like their example on the home page, which starts you off easily. But then after that, if you have to get more information on (say) a branch, then the doc doesn't do much for you.

Looking around for a better take on the documentation ....