BlackBox

The other big change I’m considering is actually moving away from Subversion. I’ve really enjoyed using it, but a recent discussion on the Groovy Dev list about Distributed Version Control Systems (DVCS) has got me looking at alternatives and why it would be good. I asked my friend Kate if she had any blog posts on why switching to a dvcs is a good idea and she whipped one up for me.

After reading through it I think I’m sold, but now I’m trying to figure out which one to try out first. Git honestly looks like the clear winner here in a number of respects:

• Serious mindshare amongst the OSS projects
• Has a great community committed to pushing the project forward (as Kate suggests )
• Has some really good functionality (even if it is a bit obtuse to get to understand)
• Looks like the beginnings of some plugins
  • Eclipse

But it also has some (current) drawbacks:

• Tools are really only available on Linux - Mac looks like its coming but could be a pain in the ass to build, forget Windows right now
  • No IDEA plugin yet (bummer) - but it does look like IDEA 8 will support it
  • No NetBeans plugin
• It’s a bit obtuse to learn - the commands are not necessarily the easiest to understand but they do have a Subversion -> Git guide online

So, I think I will try Git first, maybe. What about the other two - Bazaar and Mercurial? Bazaar honestly looks like 3rd place contender right now, but it does have some interesting tools available to it. Let’s look at Mercurial next.

• There are some pre-built packages for OS X and Windows - nice
• Again, looks like the beginnings of some plugins
  • Eclipse
  • IDEA
  • NetBeans

Some current drawbacks

• Doesn’t seem to have the same mindshare as Git does (this is my perception not necessarily true)

Now onto Bazaar.

• Binaries available for multiple platforms - OS X, Windows, and Linux
• Patch Queue Manager - very interesting tool
• Bundle Buggy - another interesting tool
• There are again plugins available
  • Eclipse
  • IDEA

Of course after I started this I found this much more in-depth review of the different systems over at InfoQ.

I think after reading a ton more on this (and the InfoQ article) that I’m going to give Mercurial a short first and see how it goes. Kate makes two more points at the end of this blog post on Mercurial vs. Git (which itself was a response to another blog post) - If you need Windows support or documentation are important items then Mercurial may be a better choice. For me, while I don’t need Windows support, it will be nice to understand what I’m trying to do first.

First, let me say, I like Maven - a lot. I’ve liked the idea, if not the execution, since 1.0 (yes, I know there is some serious bad blood for the implementation of 1.0, and yes I still liked it). But I’ve recently run into some irritating problems with Maven that would again, I think, require a major reworking of what it does.

Here is the main issue Maven is designed to handle one language only for its compilation - primarily Java. This is rapidly starting to fall apart now that the JVM has some serious contenders besides Java, namely Groovy, JRuby, Jython, and Scala. There are some hackish things for getting Maven to deal with these, however it still only has one “true” source directory for compilation. A case in point is a mixed Java/Groovy project - trying to get IntelliJ to respect the fact that I want not one, but two main source directories is a pain in the ass as I have to either tell it not to sync everytime I launch or I have to refix the source directories each time I update the project.

This is what triggered this post - what happens when I want to do some Flex programming with some Java, ActionScript and MXML, all of these are true source files (and in Maven specfic directories). I’m sure some Mavenite is going to say that these should be separate projects, but in alot of cases they aren’t and it doesn’t make sense to actually separate them into sub-projects. And I’m equally as sure that some Ant-ite is going to come along and tell me to use Ant - I won’t. Ant is stuck in the past and I won’t use it unless I absolutely have to. I like the “imposed” structure that Maven offers. I can walk up to any project and know where to find stuff instead of blindly hunting around for hours trying to piece it together like some giant source-code jigsaw puzzle, blech.

So, I’m at cross-roads, what should I do? There is Ivy (for dependency management -which they got from Maven natch), but that requires Ant, blech. There’s also Gant, ok, this is better, but still Ant. GMaven, but I’m right back where I started.

Enter, Gradle, a new Groovy-based build system that offers alot of the benefits of Maven without locking you in and the flexibility of Ant. I’m not 100% sold on it yet, but I’m going to give it a shot for a relatively complex project that will have a fair amount of Java, Groovy and other fun resource files. It looks interesting in that all the build files are actually Groovy scripts that are a DSL (like Gant files). Here’s a short example with some dependencies (taken directly from their examples in the download).

import org.gradle.api.tasks.util.FileSet

usePlugin('groovy')

group = 'org.gradle'
version = '1.0'

sourceCompatibility = 1.5
targetCompatibility = 1.5

dependencies {
   clientModule(['groovy'], ":groovy-all:1.6-beta-1") {
       dependency(":commons-cli:1.0")
   }
   compile project(':groovycDetector')
   testCompile ":junit:4.4"
}

compile {
   exclude('**/Exclude.java')
   groovyExclude('**/ExcludeGroovy.groovy')
   groovyJavaExclude('**/ExcludeGroovyJava.java')
}

manifest.mainAttributes(myprop: 'myvalue')
metaInf << new FileSet(new File(srcRoot, 'metaInfFiles'))

test.options.systemProperties['org.gradle.integtest.buildDir'] = buildDir.absolutePath

I will try and keep everyone up to date as I continue to investigate this new build system. They also state that they are going to be supporting polyglot programming in the near future which I’m looking forward to.