Lóránd Somogyi

As you might know we use Maven extensively. We have a corporate Maven Repository served by JFrog’s Artifactory. We have more than 30000 artifacts in our repository, – about 35GB of backup.

We try to keep up-to-date with new Artifactory releases. Unfortunately some times upgrade is not that smooth, so we need a backup and a drop-in service in case of failure.

As most of our artifacts are just old releases, we decided to create a secondary service, which acts as a drop-in service in case Artifactory is down. The idea is simple, just create a repo1.maven.org like service, with simple HTTP. Each time upgrade is to take place, copy all the new data to that repository and switch the service to point to it. – This works in case of failure too, just copy the backup to a simple “repository”.

To create the simple repository we took our Artifactory backup, removed the Artifactory specific meta-data and copied to a directory and configured an Apache HTTPD to serve it. Unfortunately the Artifactory backup contains no maven-metadat.xml, which plays key role in resolving versions. I was sure there is a maven-metadata.xml generator somewhere on the Net. But there were none! We needed it badly, so I created one. It is a simple Perl script that runs under Linux (uses shell commands extensively). It takes care of releases, but ignores SNAPSHOTs. Afterwards I realized that we need to produce md5 and sha1 checksums to, so I’ve created another script.

I thought it would be nice to share the scripts, so I’ve created a project on Google Code under maven-scripts name.

To create maven-metadata.xml:

• cd to root of the Maven Repository folder, in my case: cd /data/mvnrepo/releases-backup
• execute the script: /path/to/script/mvn-metadata-gen.pl

You will see 2 lines for each maven-metadata.xml generated: one for the metadata, the other for sha1.

If you need md5 and sha1 sums for POMs and JARs:

• cd to root of the Maven Repository folder, in my case: cd /data/mvnrepo/releases-backup
• execute the script: /path/to/script/mvn-sha1md5.pl

(Well, this could be Bash script too…)

Script could be downloaded at download page.

Please report any problem, bug, issue at projects issues page.

Lift the weight

If you have a lots of artifacts as we have, you could lift the weight a bit from your Maven Repository creating a repository as described above and setting it as a mirrored repository.

We do that, and now:

• Artifactory eats up less Memory, CPU and disk space
• Backup is much smaller
• Maintenance is easier
• Upgrades are less painful

We have a strange animal: A web application with really lots of jars. (Today total of 273 JARs.)

We use Maven 2, Eclipse with WTP, Tomcat, Q4E, etc.., but from these technologies only Eclipse, WTP and Tomcat are relevant for the problem I’d like to describe. Most of developer machines runs Windows XP, and some Windows 2000, and just few Linux.

As we use Maven 2, the jars came form ${user.home}/.m2/repository/ folder. We just let Q4E set up the path for our projects inside Eclipse. For some reason we stack with Q4E 0.3.0, and we tweaked the WTP Server (Tomcat) launch settings, to have all JARs included. We did not used “served modules without publishing”, nor “J2EE Module Dependencies” for few (here) non-relevant reasons.

After adding few new modules (JARs) to the webapp, for few developers the Tomcat Server just failed to start. No log, and nothing in the debug view, nor in the error view. Eclipse WTP were just waiting for Tomcat to start… forever… We were bitterly searching for solution/bug. With no luck. After adding even more JARs, even more developers were complaining: the same problem.

Read more…

We use Maven2 for developing our huge application, (and few smaller). We have almost 200 projects which depends on each other somehow. That’s why I really like Maven2. It was a nightmare to handle all those dependencies by hand, – as we did it before moving to Maven. Of course there are other great things about Maven, like reports, site and of course the release management. – OK, there is still an annoying bug with release plugin, ranges and snapshots, but we can live with it.

With the release of 2.0.9, we got a new powerful feature for handling dependency versions. The so called “Importing Dependencies” noted in release notes and described in the documentation and in wiki.

Read more…

I was playing a bit with Hibernate and Groovy. I was about to examine the possibility of using Groovy producing JPA Entities.

As I use Maven 2, the natural way is to create a project and define dependencies. As a good Maven user I was looking for the best artifact in the maven repository. I found Hibernate, and Groovy too. I took the latest from both. For groovy there was a choice between groovy-all and groovy. The groovy POM file was more descriptive, so I took that one.

Now that was a bad idea.

The problem is: Hibernate depends on ASM 1.5.3 while Groovy depends on ASM 2.2. ASM is not backward compatible, so ASM 2.2 won’t work for Hibernate. It will fail with class not found exception, (and vice versa for Groovy). After a day of hacking Maven POM file, and looking for some solution, I found this. Just look at the last paragraph, there is the solution. Just pick groovy-all. So I did that, and everything is fine again. Or at least to thought so…
I work on a framework, so I need to use ASM to enhance or to create some code at runtime. I usually do that by using ASM Eclipse plugin, because that is the fastest and easiest path. But that plugin relies on ASM 2.2, and now I’m back where I was…

Ok, I could use a class loader hierarchy, but that would mean special configuration for Maven, or even worst, special configuration at deployment.

I think the Hibernate team should consider the solution Groovy team made.

Or I’m going to do that.

Nice and easy.