According to a recent OSGi survey done by the Burton Group, 4/5 of the respondents are planning on developing OSGi-based systems in the next 6-12 months, with 1/2 of them currently developing such solutions. Interestingly, the biggest issue does not appear to be finding OSGi-ised bundles of open-source projects (perhaps that's due to more open-source projects being shipped as OSGi bundles already, or perhaps via the SpringSource Bundle Repository); but rather access to information about how to develop OSGi-based solutions effectively. Seems like a good time for an OSGi book ...
The results conclude that if the application server supported OSGi bundles directly, then almost 9/10 of respondents would consider developing bundles directly to run in such a server, and tools such as Infiniflow and SpringSource Application Platform are well set for the future.
The question is, where does this leave JSR277? Is it already too late for this me-too implementation?
5 comments:
I don't think the survey is representative of all Java use. That they found a lot of OSGI amongst the chosen subset is hardly a great surprise.
Try doing a survey of OSGI use in desktop apps. You will find Eclipse and ...
I think there is plenty of room left for 277, just perhaps not in the pool you swim in.
Mark,
Even if the survey is biased, why does JSR 277 want to invent something that already exists today in EE, SE, and ME and is broadly seen as solid?
I know most people do not cross the EE,ME,and SE boundaries but isn't their a lot of value to have a common module system across the board? Many enterprise applications will have to interoperate with mobile devices and desktops in the future. A good module system can make these artificial Ex boundaries go away, shouldn't the goal be convergence instead of disruption?
Kind regards,
Peter Kriens
My interest is probably in the bit of JSR-277 which isn't found in OSGI, namely a repository.
I also already use WebStart style version IDs so OSGI doesn't appeal there either.
While I am in favour of convergence in principal, your idea of convergence appears to be meeting at your place.
Mark,
There are many repositories for OSGi bundles. OBR, SSAP, Equinox's update sites (including those which are put into Maven's repository).
However, I'm not against the idea of a standardised format; in fact, I don't think many people are. After all, working together is what's important for most people. The problem is that even the expert group aren't convinced about compatibility, so when that happens questions do have to be asked.
As for webstart -- well, that's not really a component system, is it? That's a runtime environment. Even OSGi has 'execution environments' which correspond to major releases of Java (J2SE-1.4 etc). The big problem isn't the syntax involved in expressing a range, but rather the number of digits. It's hard to map 3 digits into 4 or vice versa, and has already been noted there's no-one who needs 4 digits (especially since the 4 digits that Sun use translate trivially into strings at the lower layer). So it's about compromise, not about everything being the OSGi way - have a bizarre syntax, but use 3 digits and one string; that would solve everyone's problems. (But I think you commented on the wrong post about version numbers ...)
Have a look at JNLP component descriptors. The JNLP download protocol is half a repository.
WebStart is a runtime environment where JNLP files serve as the application/component descriptors. Components are versioned either by modification date or explicit version numbers.
Post a Comment