Since the last Bundle.update, a new milestone of NetBeans adds support for embedding OSGi bundles, and this week's London OSGi DevCon promises to be of interest. ECF 3.2 has been released, and EGit/JGit is making strong headway in the world of DVCS.
NetBeans 6.9 M1 with OSGi
Milestone 1 of NetBeans 6.9 was released, with the new and noteworthy announcing that the previously experimental Netigso being bundled in as part of the core platform.
This embeds a runtime of Apache Felix, which allows OSGi bundles to run in-process with the IDE. This will allow (for example) GlassFish, which is already an OSGi application, to run in the NetBeans process itself.
Netisgo also provides a shim which allows NetBeans modules to wrap and call OSGi components, and vice versa. However, it does not replace the NetBeans module system; rather, there are two module systems running next to each other.
There is also an experimental NetBeansInOSGi which aims to use OSGi as the underlying runtime for the NetBeans module system. Code will not need recompilation, as the NetBeans modules will still be present, but instead of a proprietary runtime, each NetBeans module will be an OSGi runtime.
Combined with IntelliJ's Osmorc plugin, which provides OSGi development for InteltiJ's users, all major Java IDEs now support OSGi development out of the box. Eclipse 3.6M5 was also recently released.
OSGi DevCon
This week sees OGSi DevCon London, in conjunction with JAX London. The programme is available, and Tuesday hosts a free JAX Community Night between 20:00 and 22:15; however, registration is mandatory for those wishing to attend who won't be attending JAX itself.
Kirk Knoernschild will open the conference with the “OSGi in the Enterprise” keynote; a preview of the presentation notes that the number of lines of code doubles every seven years, which Kirk highlights:
But let’s put this in perspective for what it means over the course of the next seven years, as well. It means that between 2010 and 2017, we’ll produce more code than the total amount of code ever written combined!
- Since the Spring framework was released in 2002, the number of lines of code has grown more than 500% through the release of Spring framework 2.5 in 2008.
- FreeBSD contained roughly 8 million lines of code in 2002. In 2009, it was close to 16 million.
- In 2004, the Linux Kernel contained approximately 6 million lines of code. In 2009, it was around 12 million.
The takeaway is that the code growth will happen, and unless the complexity is managed, it will become an increasing problem; modularity is the answer.
There are also tutorials available at OSGi DevCon for those who don't know why OSGi is important, as well as updates on the Java Persistence API and dm Server.
ECF releases 3.2 with remote services
As Scott Lewis announced last week, ECF 3.2 has been released and is now available from the Eclipse download page. The Eclipse Communication Framework provides the underpinnings for Eclipse's communication with the outside world, including the HTTP downloads for the P2 update manager.
The big news for the release is support for the OGSi 4.2 remote services API, which allows OSGi services to communicate between VMs. This communication needs no additional code, other than the configuration properties service.remote.interfaces and service.exported.configs. An upcoming episode in the Modular Java series will focus on using remote services in OSGi.
ECF also provides other communication services, including asynchronous access of REST-based APIs, load-balancing client-side requests and an early-access for Google's Wave protocol.
EGit/JGit early access
With the rise of DVCS, Eclipse is gaining momentum for both Git and Hg. Whilst both are responsive to requests and have frequent updates, EGit is hosted at Eclipse and has an Eclipse update site. (HgEclipse has an update site as well, but at JavaForge instead of Eclipse.org)
Whilst EGit is the Eclipse UI provider, the heavy lifting is done under the covers with JGit. This is an OSGi bundle, which can be embedded in other OSGi runtimes, to provide Git support. (This could be used to plug into NetBeans' new OSGi system, for example.) If you have an OSGi runtime which needs to acquire/share distributed configuration information, then using Git as a distribution and update mechanism may be applicable.
If you are not yet using a DVCS but want to learn more, I previously blogged about Git for Eclipse Users, which provides a soft introduction into the world of DVCS and Git in particular, as well as explaining some of the differences between that and traditional CVCS like SVN and CVS. Ekke has published a Git and Mercurial tutorial series and Lars Vogel has published a Version control with Git tutorial, both of which look at Eclipse's use of Git.