Just listened to an interesting interview with Joel Spolsky of Joel on Software fame. He hires competent developers to work on some project. As the real needs of customers emerge, the project is adjusted or new projects are spawned. So his approach is to start with technology and "lead" customers, but then listen hard for their feedback and react accordingly. Very sensible.
The Aspects Equinox incubator project just announced its first release.
Now you can write AspectJ aspects, package them as OSGi bundles, and apply them to bundles which explicitly "opt in" to these aspects. The "co-opt" model is coming soon and will enable aspects to be applied to unmodified bundles (without them having to opt in).
JSR 277 has produced an Early Draft Review specification which I hope the Java community will review carefully. As a member of the Expert Group that produced the spec., I don't think it would be appropriate to express my opinion here, much as I would like to.
The OSGi Alliance recently held a workshop on applying OSGi to the enterprise. You might find it surprising that a technology initially created for small devices is starting to be used on large enterprise systems such as application servers.
But businesses need to keep their IT costs down, especially price/performance. Salaries for application developers, operations staff, etc. can be reduced by using languages such as Java and standardised middleware. But if that impacts performance, then price/performance suffers.
OSGi provides good support for Java modularity, versioning, and lifecycle management but is also efficient because of its roots in small devices. Modularity helps keep development and maintenance costs down; versioning and lifecycle management reduce operational costs.
So, apart from the coolness of OSGi technology, I would expect its price/performance to appeal to middleware vendors and their enterprise customers. I would also expect customers to see value in using OSGi directly, e.g. in conjunction with Spring.
