Twitter github

Modularity is Fun?

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.

jgit1

You know what to do with evil UI code? Time to move it into another bundle!

jgit2

Sweet! Now we have a nice separation between core and ui layers, right?

jgit3

Oh no… compile errors… what the heck?

jgit4

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.

  • Worth also noting that Jetty 7 (released on Thurdsay) also ended up taking advantage of the tighter divide between bundles when they refactored the code; previously, unintended dependencies between the client and server JARs meant that in order to run a client, you had to have the server JARs on your classpath …

  • Worth also noting that Jetty 7 (released on Thurdsay) also ended up taking advantage of the tighter divide between bundles when they refactored the code; previously, unintended dependencies between the client and server JARs meant that in order to run a client, you had to have the server JARs on your classpath …

  • Marco Lehmann

    Will there be a fetch factory for PDE/Build? I would like to provide some help. I am the build master of our Eclipse RCP based products and have some experiences with PDE/Build. Can you give some hint where to start and where you appreciate my help.

  • Marco Lehmann

    Will there be a fetch factory for PDE/Build? I would like to provide some help. I am the build master of our Eclipse RCP based products and have some experiences with PDE/Build. Can you give some hint where to start and where you appreciate my help.

  • Marco, there’s a bug open for the Git fetch factory enhancement. It has a partial patch and needs some work. If you’re interested in contributing this would be a great place to start!

  • Marco, there’s a bug open for the Git fetch factory enhancement. It has a partial patch and needs some work. If you’re interested in contributing this would be a great place to start!

  • Robert Konigsberg

    I have been considering for months blogging about some work I did separating one of our team’s critical bundles into core and ui components. It took a couple of weeks to get it right, given the large number of plug-ins that depended on it, and the surprising number of places where things required detangling: even just dealing with an IRunnableWithProgress was a real pain. Getting this right after the fact meant creating the types of structural design patterns that make Java famous for being verbose.

    Now we have a team policy of always requiring core and ui plug-ins, and new teams that want to write a plug-in are herded into that direction. Extra work, sure. But it helps greatly.

  • Robert Konigsberg

    I have been considering for months blogging about some work I did separating one of our team’s critical bundles into core and ui components. It took a couple of weeks to get it right, given the large number of plug-ins that depended on it, and the surprising number of places where things required detangling: even just dealing with an IRunnableWithProgress was a real pain. Getting this right after the fact meant creating the types of structural design patterns that make Java famous for being verbose.

    Now we have a team policy of always requiring core and ui plug-ins, and new teams that want to write a plug-in are herded into that direction. Extra work, sure. But it helps greatly.

  • Rob, that would be fascinating blog entry for me. I encourage you to write it. It’s good when people outside the traditional Eclipse world experience this and write about it. I can only write so much 🙂

    It’s natural for developers to not modularize their code from the beginning if there’s no way to enforce modularity at runtime. With OSGi being the first viable module system that enforces contracts during runtime… and Eclipse providing a good set of tooling, you see some errors immediately.

    Setting a policy of always requiring core and ui separation is a good thing. I think most experienced developers try to do this, however as you see with the JGit case, it’s easy to slip up sometimes. Sometimes it’s easy to separate out the bits, sometimes the rabbit hole is quite deep.

  • Rob, that would be fascinating blog entry for me. I encourage you to write it. It’s good when people outside the traditional Eclipse world experience this and write about it. I can only write so much 🙂

    It’s natural for developers to not modularize their code from the beginning if there’s no way to enforce modularity at runtime. With OSGi being the first viable module system that enforces contracts during runtime… and Eclipse providing a good set of tooling, you see some errors immediately.

    Setting a policy of always requiring core and ui separation is a good thing. I think most experienced developers try to do this, however as you see with the JGit case, it’s easy to slip up sometimes. Sometimes it’s easy to separate out the bits, sometimes the rabbit hole is quite deep.

  • Simon Archer

    Understanding how to manage your code’s dependencies, and sticking to the rules when under pressure are challenges that we all regularly experience.

    I see dependency problems constantly and I often feel that its a lack of understanding, as opposed to laziness or a lack of time. In my experience developers either don’t know to worry about dependencies, or don’t want to worry about dependencies. Either way, its a recipe for software disaster.

    Prior to using OSGi I’m certain that I understood that managing dependencies was important, but it was not until I used OSGi and had my dependencies “front and center” and validated at runtime, did I truly understand them and how to design and implement highly cohesive and loosely coupled components. We tried hard in our forthcoming OSGi/Equinox book (tinyurl.com/osgi-book) to get this message across.

  • Simon Archer

    Understanding how to manage your code’s dependencies, and sticking to the rules when under pressure are challenges that we all regularly experience.

    I see dependency problems constantly and I often feel that its a lack of understanding, as opposed to laziness or a lack of time. In my experience developers either don’t know to worry about dependencies, or don’t want to worry about dependencies. Either way, its a recipe for software disaster.

    Prior to using OSGi I’m certain that I understood that managing dependencies was important, but it was not until I used OSGi and had my dependencies “front and center” and validated at runtime, did I truly understand them and how to design and implement highly cohesive and loosely coupled components. We tried hard in our forthcoming OSGi/Equinox book (tinyurl.com/osgi-book) to get this message across.

  • Marco Lehmann

    Chris, please take a look at http://github.com/mlehmann/git-fetch-factory and leave a comment. Suggestions are most welcome.

  • Marco Lehmann

    Chris, please take a look at http://github.com/mlehmann/git-fetch-factory and leave a comment. Suggestions are most welcome.

  • Marco, why not contribute the fetchfactory implementation to the EGit project?

    Is there a reason you’re using the command line vs. JGit?

    This will be useful for people pulling from Git repositories and using PDE Build.

  • Marco, why not contribute the fetchfactory implementation to the EGit project?

    Is there a reason you’re using the command line vs. JGit?

    This will be useful for people pulling from Git repositories and using PDE Build.

  • Marco Lehmann

    @Chris Aniszczyk
    Thanks for the reply. The code in my repo is just a starting point. My intention is to develop the fetch factory until it is mature enough to contribute it to eclipse.org. I use the command-line version because the original code does so. I will take a look at EGit/JGit.

  • Marco Lehmann

    @Chris Aniszczyk
    Thanks for the reply. The code in my repo is just a starting point. My intention is to develop the fetch factory until it is mature enough to contribute it to eclipse.org. I use the command-line version because the original code does so. I will take a look at EGit/JGit.