The nuclear option


I have been using open source software now for about 20 years. One of the things that I always saw discussed back in the day was if you don’t like the way a project is being run you can always fork it and do things differently. In all my years I have never actually felt the need to do such a thing because lets be honest running an open source project is a ton of work. As readers of my blog know I have been wanting to update to Spring 4.1. What has been holding us back was a change in aspectj 1.8.2 where it would automatically process annotations found in the code. This ends up generating the hibernate meta-model and dumping the files wherever maven was invoked. So trying to work within the project I opened up a jira for an enhancement which would allow me to pass a flag to the compiler to not process the annotations. There was a quick response at the beginning of January and I was left with the impression that this would be handled in a couple of weeks. Finally in the middle of February with the work still not done Ralph Engelmann submitted a patch which would actually implement the feature.

I thought certainly once someone had actually done the work and implemented this a new version would be forthcoming but it has gone to complete silence on that jira. Maybe this has fallen to the wayside with the news that Codehaus is shutting down. In any event my patience was up a few weeks ago so I was like let me group the source code and throw it on github and apply the patch. The first thing I found was they use Subversion instead of Git which seemed pretty suprising to me. Who would use SVN anymore, it is so terrible compared to git. Anyway I got the source code and threw it up on my github account. I applied the patch and for grins upped the version to a Java 7 minimum as I have no intention of using java 6. I changed the package name to avoid confusion. I have no desire to actually maintain this project so I haven’t done anymore to actually get it out into a maven repository. I think my plan in the short term is to just install this into our local nexus server and use it to bring us up to Spring 4.1. My hope for the medium and long term is that once they deal with the codehaus move this will get updated and I can back to the codehaus project as I don’t want to maintain this. But for now I am going nuclear and forking it and moving on…

, ,

3 responses to “The nuclear option”

  1. I guess that’s like saying who would drive a volkswagen any more when a Mercedes is so much better. Git has a much steaper learning curve, and a horrible command structure that looks like it was just slapped on without any thought (and it was). Some developers think that the most important thing for them to learn are coding techniques and not version control. There are still people that use many other version control systems. Among many other links, are lots of people that have used Git but found it to be bad – here’s one rant: http://www.worldofsuck.net/index.php/single-most-ass-revision-system?blog=2

    “But Git can do anything” you say: Just in case anyone didn’t know (but you probably already so) there are commands in Git that you can use to completely render a repo useless. You can erase all history and render it’s primary function (to consolidate code and keep it safe) null. Usually, one uses a VCS to keep their code safe and almost all will do that. But with Git, you will wonder if someone doesn’t use that one comand that can wipe it all out – not that they would – but they could.

    I’m sure everyone has seen this one by now, so I won’t argue those things, but I just want to say that Git isn’t the be-all-end-all VCS that every fan boy says it is : http://stevebennett.me/2012/02/24/10-things-i-hate-about-git/

    Ok, so now let the hate begin… 🙂

  2. While I agree what you are saying is valid. I have seen git get seriously twisted up, it is definitely a tool for someone who knows what they are doing and it does have a steep learning curve I think most Unix people are used to having tools that can completely destroy your system if misused.

    What I love about git vs svn is branching, doing a single branch in svn is painful, git branches are pretty much free, and merging branches back in are simple. I like the decentralized model of the source code. I really think it is a superior way to work (having used SVN for 4 years and now having been on git for 2.5 years). Previous to that I used CM/Synergy and prior to that Visual Source Safe. I think once you take the git pain for a month it is really a much better and faster way to work. Also github is an amazing site, and has pretty much killed the competitors like sourceforge, or codehaus back in the day. So the trend is definitely going to git.