SpacerKriggs logoKriggs

How Many Plug-ins

May 15th, 2012 · 7 Comments

Few Large vs. Many SmallTension in the workplace.

In one corner, a developer that believes Separation of Concerns ends with packages. He does believe in having more than one project, but only because we have two products with code in common. So he’d have one project for product 1, another for product 2, and another for the code they have in common. (OK, he’s not that draconian, but I’m stating this stylistically).

In the other corner, me. I take it to the other extreme. I see every service (of which we supply a couple dozen) being in its own project.

His argument is that he doesn’t want an explosion of projects from what we currently have. He wants every extracted project to be well justified.

My argument is that an increase in modularity in bundles brings design to a higher level of abstraction and has a number of benefits, including slower degradation of quality and improved software comprehension.

The question is this: what is the best philosophy to have? Few large projects? Many small projects? Or is there always a balancing act that makes this inseparable from art? I am dying for your opinions! (And relevant reading (such as articles) if you know any.)

Tags: eclipse

7 responses so far ↓

  • 1 John Arthorne // May 15, 2012 at 5:28 pm

    Sorry, it’s an art :)

    Some things to consider:

    OSGi purists would argue you should specify all your imports and exports at the package granularity. If you do this, then your bundle granularity is not important because you can refactor packages across bundles at any time without impacting anything. But then, your next question will probably be, “should I have one big package or many small packages??”

    In my experience the appropriate granularity often depends on the code. Very general, highly reusable code and services should be split into small bundles to allow clients to pick it up without pulling in too much unwanted code. More specialized code that isn’t designed for reuse can be packaged into larger bundles. Often UI code for example, can live in a larger bundle.

  • 2 Kriggs // May 15, 2012 at 5:59 pm

    John: Thanks for your comment.

    Overall, I think you make valid points, but I would disagree with your statement “bundle granularity is not important”. If you merge two projects, their dependencies between one another vanish from their combined manifest. Once you do that, any code from one half can use code from the other. If a dependency is created in the wrong direction, the integrity of your design is likely to suffer from it.

    Also, UI should probably be in the smallest (simplest) bundle possible (but no simpler, as Einstein would say). That way, a UI can be focused entirely on the concern of its appearance and be implemented really fast. One benefit of this could be to rapidly come out with an desktop application, a web application, a mobile app, where only one small project (not even necessarily in the same target language) is changed.

  • 3 soru // May 16, 2012 at 6:44 am

    A plugin is a run-time concept, visible to end users. Using them to manage design time concepts like dependencies is a _horrible hack_ that should be discouraged. It’s practically like requiring users to sign into, configure, back up, etc. multiple databases because you wanted to keep the logical model clean.

    Apart from the overhead paid by the end user, abusing a platform-level trick in that way is never going to be good enough to actually do the job satisfactorily.

    You need to be able to say that both ‘ui depends on server, not vice versa’ and ‘ depends on, not vv’. As you’ve realized, using OSGi hacks to do this forces you to pick one level to do the bundling at, so the other check is either lost or duplicated.

    To maintain, check and document a design, use an appropriate design tool like That way you can check and specify things at any level, rather than having to pick one and only one level of granularity.

  • 4 Mike Rumpf // May 16, 2012 at 6:54 am

    In my current project team this discussion is also quite active. There are some guys feeling not comfortable with hundreds of bundles (or OSGi services) because they believe (as they say it) that the management of dependencies adds a complexity to the software that is hard to handle if not completely confusing.

    After 2 years of OSGi I understand these concerns much better than in the beginning. If you increase the number of bundles (which is strongly recommeded) than I would advise the following.

    – It is essential to follow a strict naming convention for the bundles (if you are looking for a class you should be able to find it easily)
    Of course this is also true for packages but it is essential for bundles as well.

    – You need to have a clear vision of the software architecture. (layering, interfaces etc.) If a new class is created it should be obvious for all team members where (meaning which bundle) this class has to go.

    – Someone needs to be responsible for checking that no violations of the architecture happen (this may seem obvious but in our team this role is vacant because of time/budget concerns – IMHO a big mistake)

    Besides having lots of bundles means a greet deal of flexibility. If if your system is not dynamic it is really nice to be able to install a patch by just copying a small bundle in the plugins folder. If some functionality is causing trouble you may just stop/remove the respective bundle. Having every UI in its own bundle gives us the possibility to configure a set of UIs for customer A and a different set for customer B just by configuration. If you set up your workspace you may not need to import all bundles just the ones that you want. These are all practical arguments in favor of lots of bundles besides the ones you already mentioned.

    Best regards,

  • 5 Laurent Asfaux // May 16, 2012 at 11:11 am

    In our team we use the eclipse “target platform” concept to provides all dependencies of our RCP application, even those we are working on.

    To work on a specific bundle, the developer need to import it in his/her workspace as a project from the source repository (here a Subversion repository).

    Because bundles in the workspace automatically replace any target platform plug-in, we can work with a few opened projects, which speed up builds and overall Eclipse reactivity.

    Eclipse also provides in the “File” menu the ability to import a plug-in as a workspace project in binary form, linked sources, or full.

    Thanks to, I also heard about an Eclipse plug-in providing a transparent switch to edit sources of a JAR file by extracting linked sources into a project when needed, but I can’t remember its name.

  • 6 Kriggs // May 16, 2012 at 12:32 pm

    soru: If I understand properly, you believe OSGi is more of a nuisance than a benefit?
    Mike: Thank you for your input, you are right in line with my line of thinking.
    Laurent: I do plan to use a target platform. Glad to hear there is evidence of that working.

    I also plan on having a number of projects, which are just structural, be automatically generated from a model, rather than maintaining the dozen or so files that your average small project will end up having. For me, the better you design something, the easier it is to reason about it at a higher level of abstraction. The only part I wouldn’t abstract is the algorithmic logic, but every algorithm would exist in just one place, and in those cases where that is impossible (something architectural), then it would necessarily need to be generated.

  • 7 soru // May 16, 2012 at 1:13 pm

    OSGi is certainly an appropriate tool for doing various things in particular contexts. How wide that applicable niche is a question I’m not in a position to answer – ask an industry analyst.

    What it clearly isn’t is an appropriate tool for specifying, checking or documenting system designs. It was never intended to be such a thing, and using it in that way has an unfortunate habit of turning statically-detectable design-time mistakes into mysterious unrecoverable JVM-level errors, and trivial repackaging/marketing decisions into rearchitecturings.