Maven and OSGi do not contradict each other. In fact I build OSGi bundles primarily with Maven. I agree Import-Package is too low level for humans to cope. This is why I work at the coarser grained maven level and use a maven plugin to automatically build the low-level OSGi metadata for me.
Also OSGi supports maven-style dependencies at runtime with Require-Bundle. This includes the possibility to have composite facade bundles like say “org.apache.wicket-1.4.0.jar”. At *runtime* both Import-Package and Require-Bundle have their valid use cases. At *buildtime* however we should always use Maven/Require-Bundle level of granularity and tools to get the flexible low-level OSGi metadata.

Here is a blog explaining why this high-low separation is a good idea:

http://www.osgi.org/blog/2008/06/jsr-277-and-import-package.html

As for the service model: I agree it is not for every usecase. Real application are a mix between the service model and the extender model. I think extender is at least as important as the service model and more generic. Here again we are just starting to explore the full potential and to develop clear best practices and standards like OSGi RFC-66.

Anyway my point is that OSGi and the enterprise do not have fundamental contradictions. It is mostly that the raw OSGi is a thin modular layer on top of the JVM. Having runtime modularity is very compelling - but it must also be easy/cheap to use. That’s why rather than reject the best current modularity runtime for Java we should push forward and built it up to a convenient general purpose programming environment. It is also tremendous fun trying to do so

With Maven-style dependency, wicket is easily imported because “wicket” is a conceptual name encompassing the entire wicket library, not just the name of a package. And it’s trivial:

<dependency>
<groupId>org.apache.wicket</groupId>
<artifactId>wicket</artifactId>
<version>1.4.0</version>
</dependency>

To convince anyone to switch to OSGi, you’d need to explain why redesigning Wicket in an OSGi style was better. If OSGi had real value for the enterprise, either the dependency management would be easier than the Maven example above, or an OSGi-style reorganization of Wicket would be intrinsically superior to the current Wicket architecture. Handwaving about service-oriented design isn’t enough.

Some applications which fit a strong service-oriented design may fit well with OSGi, but that does not imply that all enterprise applications should therefore be converted to use OSGi.

I am not convinced there is a “natural” way enterprise applications are organized that clashes with either package level visibility or the service model. I would be grateful for any examples that both constitute a good practice and at the same time fundamentally clash with package-level visibility or services.

To me the greatest barrier to enter OSGi is the lack of support for the big infrastructural services every non-trivial application needs. With this in place the next barrier is the required switch in thinking from the usual app designs to a strong service oriented design. Many traditional isolation practices are hard to use with OSGi because they are no longer required! I think we have trouble grasping the extent to which we need to do *less* with OSGi. We almost don’t need abstract factories, we almost don’t need singletons, we almost don’t need classes in our APIs, consequently we don’t need to control access between the public and private halves of these classes with package-private members and any other tricks. Currently the main weakness of the package-level control is that I can’t expose certain service APIs to collaborating bundles in my application while hiding them from bundles within other applications. However without OSGi any such access control is down to pure convention, so certainly OSGi improves the situation although it does not completely solve the problem. This last hole will be plugged with composite bundles. I.e. a multi-bundle app will look as a single bundle to other apps. In fact Eclipse already has a reference implementation of this.

As for the service model: I think it is not meant to be used directly by developers. I look at it as an extremely simple interoperation layer. It’s job is to capture the absolute minimum of functionality required to share live objects between bundles - the simpler and more straightforward the better. Currently it does a good job at this but I think it needs to be refined and simplified a bit more. Because the service model is so simple it is quite easy to extend it to a full DI runtime. The beauty of this design is that we can have any number of ‘oppinionated’ component/DI runtimes running concurrently within the same OSGi container and interoperating with each other completely transparently. So everyone can use the runtime that suites their application best, drop down to the raw API, or even implement their own DI framework. I am almost certain it will be possible to implement JSR-299 on top of OSGi as well. Btw today there are no less than 5 component/DI runtimes for OSGi an they do interoperate transparently and are free to evolve independently.

Stephan Schmidt
Head of Development b4f
http://twitter.com/codemonkeyism

The difficulty with OSGi is really when you get to engineering implementation details. If you stick to the 10,000 foot level “modularity and services are good”, then OSGi looks fine. When you start putting it into real engineering practice for enterprise applications, the mismatch becomes apparent.

The two mismatches in OSGi are the package orientation and the entire service model.

OSGi strongly encourages a model where each module export a single package and has a collection or implementation packages. For simple applications, like embedded application, this package structure can work well, but in an enterprise environment it warps the natural enterprise organization to a foreign strict-package model. In other words, the enterprise application is no longer organized naturally to the application itself, but to the foreign OSGi model.

The service model is just a generation behind, basically a service-locator model. There’s nothing intrinsically wrong with the model, but new technologies like Java Injection (JSR-299) are more descriptive and powerful.

And it must be so many years using Resin, or it might be that I use Resin because my mind is aligned with Caucho guys, but I agree that OSGi might still need a bit of time so something simpler, easier to use, even if not feature-complete, could be useful now, to start changing things and exploring best practices etc.

The only thing I would ask is for web apps to still be compatible with other containers. So, for example, you might allow .jar files to be included in WEB-INF/lib but if you include WEB-INF/pom.xml they are moved/renamed/not taken into account automatically. That means the application as-is can work in other containers but you get all the goodies if you do it inside Resin/Pomegranate.

I’m looking forward to using this and the new GIT/.war features of Resin 4.0 in production :).
S!
Daniel Lopez

http://rinswind.blogspot.com/2009/06/current-state-of-affairs.html

In a mobile context, it may make sense to create one package of API interfaces to export, and hide the rest in other packages, but enterprise applications need more flexibility to their package design.

In other words, while the OSGi model of package-use is fine, it’s not the One True Package Architecture, and doesn’t play nicely with enterprise applications.