Trying not to reinvent the wheel over and over again in software development, reusability has quickly become a strongly desired virtue. Object-orientation was once meant to deal with this, but it soon became obvious that objects are a much too small unit to be really reusable across projects or companies. So in today's world we ended up with modules all over the place - some call them libraries, plugins or bundles, but most often these are simple jar files; in general a module is just a bunch of classes and resources, sometimes enriched with some meta-data.
As it is with objects, modules make only sense if there are dependencies between them. For objects, these dependencies were often hard-coded, but in the age of dependency injection they form rather meta-data that comes aside the classes (e.g. in a Spring application context xml).
For modules, two main solutions have evolved over the past years to describe dependencies: Maven pom-files and OSGi manifest-files. Both have quite a lot things in common: They specify names and versions of modules and list their mandatory or optional dependencies. Of course there are many details where the one offers more and other things than the other, but in general, it is a very similar concept.
The difference between Maven and OSGi is their use case: Maven targets the provisioning, build and distribution of modules, while OSGi is targeted at the development and - more importantly -
the (dynamic) runtime of applications. Both are well established in their domain and have a big community of users - but slowly people realize that they actually want to have them both at the same time. On the one hand, OSGi is introduced into "classical" applications by Spring Dynamic Modules where the build process is best left to Maven. The OSGi crowd on the other hand has noticed that it is a pain to collect all required dependencies and that there actually should be something like a repository infrastructure to easily retrieve and distribute modules.
The OSGi Alliance has therefore set up the OSGi Bundle Repository (OBR) - which looks very similar to Maven repositories, I just doubt that it will be equally successful. The Eclipse Foundation, one of the foremost adopters of OSGi, went one step further and introduced p2, the new provisioning system that will come with Eclipse 3.4 aka Ganymede. p2 replaces the Eclipse Update Manager, brings a new infrastructure for bundle repositories and supports to dynamically install and manage bundles in a running application. In the next phase (after the release of Ganymede), it is planned to extend p2 towards the build process as well.
Although competition is usually very welcome, it means some dilemma for the average configuration manager: Building dynamic applications does not mean that one can decide for the one option or another, but both approaches (Maven and OSGi) need to be combined. There are multiple tools and plugins available, which help converting Maven pom-files into OSGi manifests or vice versa or which allow calling the plugin build from Maven or to call Maven out of Eclipse.
The problem is that with generation one descriptor file out of the other, some information is usually lost or at least the comfortable tools cannot be used that exist to maintain the files. So the right decision very much depends on your application: If you already use Maven for continuous integration, the pom-files will be the source of everything for you and you can introduce OSGi by generating manifest files from these. If you instead work on an Eclipse RCP application and are used to all the comfort that Eclipse offers you for editing the manifest or the plugin.xml, nobody will be able to convince you that you should instead manually put your changes in a pom-file and generate the rest again.
Although p2 is a cool feature, it might make things worse, at least in the beginning: For OSGi-centric applications, its use will be very desirable, while not offering all flexibility of Maven. So if Maven is already in place, it is unlikely that it gets replaced by p2 soon. Instead there will be adapters, mapping Maven repositories or OBRs to p2 and having Maven builds pushing build artifacts back to them.
I would not object to using different tools, if the integration would be smooth - but experience shows that both worlds do not really pay much attention to each other and leave the integration part out of their scope - so usually the integration is done by some annoyed people who actually want to use things productively and have to help themselves to sort out things. Unfortunately these kind of integrations are often only pursued until there is a version that is doing somewhat the expected thing - and then it is left to the depths of Sourceforge. Maybe I am too pessimistic, but the Equinox team already stated that they are not interested in any direct support of Maven, so the way ahead might be bumpy...
Still, at some point in the far future when Spring Dynamic Modules have become a de-facto standard and p2 is stable and fully supports the build process, I am confident that building, integrating and deploying applications can be real fun :-)
As it is with objects, modules make only sense if there are dependencies between them. For objects, these dependencies were often hard-coded, but in the age of dependency injection they form rather meta-data that comes aside the classes (e.g. in a Spring application context xml).
For modules, two main solutions have evolved over the past years to describe dependencies: Maven pom-files and OSGi manifest-files. Both have quite a lot things in common: They specify names and versions of modules and list their mandatory or optional dependencies. Of course there are many details where the one offers more and other things than the other, but in general, it is a very similar concept.
The difference between Maven and OSGi is their use case: Maven targets the provisioning, build and distribution of modules, while OSGi is targeted at the development and - more importantly -
the (dynamic) runtime of applications. Both are well established in their domain and have a big community of users - but slowly people realize that they actually want to have them both at the same time. On the one hand, OSGi is introduced into "classical" applications by Spring Dynamic Modules where the build process is best left to Maven. The OSGi crowd on the other hand has noticed that it is a pain to collect all required dependencies and that there actually should be something like a repository infrastructure to easily retrieve and distribute modules.
The OSGi Alliance has therefore set up the OSGi Bundle Repository (OBR) - which looks very similar to Maven repositories, I just doubt that it will be equally successful. The Eclipse Foundation, one of the foremost adopters of OSGi, went one step further and introduced p2, the new provisioning system that will come with Eclipse 3.4 aka Ganymede. p2 replaces the Eclipse Update Manager, brings a new infrastructure for bundle repositories and supports to dynamically install and manage bundles in a running application. In the next phase (after the release of Ganymede), it is planned to extend p2 towards the build process as well.
Although competition is usually very welcome, it means some dilemma for the average configuration manager: Building dynamic applications does not mean that one can decide for the one option or another, but both approaches (Maven and OSGi) need to be combined. There are multiple tools and plugins available, which help converting Maven pom-files into OSGi manifests or vice versa or which allow calling the plugin build from Maven or to call Maven out of Eclipse.
The problem is that with generation one descriptor file out of the other, some information is usually lost or at least the comfortable tools cannot be used that exist to maintain the files. So the right decision very much depends on your application: If you already use Maven for continuous integration, the pom-files will be the source of everything for you and you can introduce OSGi by generating manifest files from these. If you instead work on an Eclipse RCP application and are used to all the comfort that Eclipse offers you for editing the manifest or the plugin.xml, nobody will be able to convince you that you should instead manually put your changes in a pom-file and generate the rest again.
Although p2 is a cool feature, it might make things worse, at least in the beginning: For OSGi-centric applications, its use will be very desirable, while not offering all flexibility of Maven. So if Maven is already in place, it is unlikely that it gets replaced by p2 soon. Instead there will be adapters, mapping Maven repositories or OBRs to p2 and having Maven builds pushing build artifacts back to them.
I would not object to using different tools, if the integration would be smooth - but experience shows that both worlds do not really pay much attention to each other and leave the integration part out of their scope - so usually the integration is done by some annoyed people who actually want to use things productively and have to help themselves to sort out things. Unfortunately these kind of integrations are often only pursued until there is a version that is doing somewhat the expected thing - and then it is left to the depths of Sourceforge. Maybe I am too pessimistic, but the Equinox team already stated that they are not interested in any direct support of Maven, so the way ahead might be bumpy...
Still, at some point in the far future when Spring Dynamic Modules have become a de-facto standard and p2 is stable and fully supports the build process, I am confident that building, integrating and deploying applications can be real fun :-)