A few days ago I had one of those moments that made me smile, let me describe it in pictures…
I recently was hacking on the JGit project as I’m working on getting a build ready for the project.
What did I notice? Well, there was some evil UI code in the JGit bundle.
You know what to do with evil UI code? Time to move it into another bundle!
Sweet! Now we have a nice separation between core and ui layers, right?
Oh no… compile errors… what the heck?
It looks like some of the code in the core bundle was referencing UI pieces. This is an obvious bad practice since there is the common use case that people may want to run your code in a headless fashion. However, as a developer, it’s common to start out and just group your code into one bundle. It’s sad but it’s just the reality of development. This reason should also highlight to you why modularity doesn’t come for free… you have to think about your dependencies and architecture. If you produce complex code first and try to modularize it later… you’ll end up in painful situation. Thankfully, when you have good tools that manage your classpath for you, errors like this become evident.
Ok, enough of my diatribes, back to getting a build for JGit in place at Eclipse.
On a side note, I’ll soon blog about using EGit and Gerrit to develop JGit, stay tuned.