I just got back from a very successful JAX London, these are always very well organized conferences and this conference was no exception. Yesterday we had an OSGi day during which Neil Bartlett succeeded in writing a Vaadin Web application without having to restart the application OSGi framework. OSGi is well on its way to provide a development process with much shorter turn around time than any other environment I know. All because of its dynamic model, there is just no need to restart the framework even if you make very big changes in your code, even your bundle layout can change or the run environment.
During this presentation someone in the audience asked why bndtools supported multiple bundles per project because all other environments (like Maven, PDE, etc) limit a project to a single artifact. So why does bndtools have multiple bundles per project? There are several reasons and I think it is interesting to highlight them.
The first reason is practical. In the OSGi build for the Reference Implementation and Compliance Tests has over 1300 bundles, mostly test bundles. Having to maintain that many projects would be very painful. In reality we now have only around 130 projects. I shudder what it would mean to have 1300 projects in your Package Explorer ...
The second reason is cohesion. Sometimes your deliverable consists of multiple bundles that are actually quite cohesive. For example, assume there is a bundle that is useful on its own but someone wants to use it in conjunction with Spring. To support that use case, your bundle then requires an import of a Spring package, which would transitively drag in many other packages. You could make this import optional but that is awkward. The best solution would be to create two bundles, one with, and one without Spring. You could even make them a main bundle and a fragment for the Spring dependency. Being forced to put these two bundles in different projects creates an artificial separation that unnecessarily complicates development.
Last but not least, when we begin, we rarely know where the module boundaries are optimal. In bndtools an extra bundle has no overhead. It is easy to move packages between bundles or even allow them to live in multiple bundles. Experimenting with splitting a bundle or combining, or even just creating a test bundle, has no associated costs. In my experience, this changes the way you think about bundles, the process of developing them becomes more fluid. I rarely have projects that produces a single bundle nowadays. However, if you prefer a single bundle per project then that is your choice, 1:1 is the easy case.
That said, I actually never understood why popular build tools are constrained to a single output per project. Isn't that a little bit too much convention over configuration?
P.S. Ok, ok, Neil's Eclipse instance crashed because it ran out of heap space killing the application framework as well. So he almost reached perfection. :-)