Apache and OSGi
2005-12-16
This week I was on Apache Con 2005, the yearly conference of open source developers under the Apache flag. Together with Richard S. Hall, Enrique Rodriguez, Jeff McAffer, BJ Hargrave, Jason van Zijl , I was invited to participate in a panel about OSGi technology. Several Apache projects are already using OSGi (like the Apache Directory project) and others are eying it, like the Harmony VM project and Cocoon. This week I was there to spread the OSGi gospel as well as learn how these hard-core developers see OSGi.
I learned several things. First that there are only three things important about software: licenses, licenses, licenses. It is amazing how almost any technical discussion today ends up debating the merits of the Apache Software License 2.0 over the viral GPL, or how BSD lacks the patent clause. Where are the good old days we could discuss garbage collection without sweeping over copyrights, patents, and disclaimers?
The next hot thing seems to be the build. Building software is an art that many people try to master. Apache projects try to be self supporting so after the horror of ant they now consider maven the next best thing, well, maven-2, because maven one seem to have had some shortcomings. Despite the use of XML (which seems a mandatory requirement for an Apache project), maven is a significant improvement over ant for builds.
The problem with ant is that it basically a (terribly bad) script language, causing incredible redundancy and very hard to manage projects. Maven is different, it centralizes the rules of project building. The only thing the project provides is the Project Object Model (POM file, and yes, it is defined in XML), which provides a description of the project. This decouples the project from the build features. New features can be added that do not require changes in every POM file. Maven provides an impressive number of plugins, which provide the features. One such plugin is the OSGi plugin, which is being developed to create the OSGi bundles and its artifacts. Maven is definitely in the right direction except that the POM file should have been designed for human consumption instead of plugin consumption.
I also learned why many people in the Apache Foundation are eyeing OSGi: containerism. It is hard to get any details but Apache seems have sent the Avalon project to the wholly hunting grounds. Avalon was a project that should have made an OSGi like system available to all the other Apache projects. After a number of years the project was shut down because the group could not unify on a single design (I think this is an euphemism). I recall that a couple of years ago I tried to convince the Avalon project to take a look at OSGi, but I failed miserably to attract their attention.
On this conference, several people told me that the greatest strength of the OSGi is that Apache can not change it. Or as someone said, Apache is great at implementing a specification, but has serious problems with designing from scratch. This makes sense to me, when you have a diverse group of developers, spread around the world, with diverse backgrounds, and when they are all peers, then it is impossible to make complex designs. I am already terribly impressed with the breadth and the quality of the implementations they produce.
After this week, I am convinced that you will see a lot of OSGi at Apache. It seems to be the right moment for the organization to standardize on a single container model, and the OSGi is the best in the market. The Felix incubator project makes it very easy to use an OSGi Framework in an Apache project. The OSGi plugin for maven will make it easy to created the bundles. However, OSGi technology is not a run race for all projects. Some of the code bases are humongous and converting them into components will require effort. The key missing part is good tooling because providing the import export clauses by hand is too much work. This is a common problem and I am currently seeking approval to make the OSGi tools available to the community.
It will be interesting to see how much of the Apache code base will be converted over the coming year. I think many projects will convert. I bet next year I can directly download bundles from Apache.
I learned several things. First that there are only three things important about software: licenses, licenses, licenses. It is amazing how almost any technical discussion today ends up debating the merits of the Apache Software License 2.0 over the viral GPL, or how BSD lacks the patent clause. Where are the good old days we could discuss garbage collection without sweeping over copyrights, patents, and disclaimers?
The next hot thing seems to be the build. Building software is an art that many people try to master. Apache projects try to be self supporting so after the horror of ant they now consider maven the next best thing, well, maven-2, because maven one seem to have had some shortcomings. Despite the use of XML (which seems a mandatory requirement for an Apache project), maven is a significant improvement over ant for builds.
The problem with ant is that it basically a (terribly bad) script language, causing incredible redundancy and very hard to manage projects. Maven is different, it centralizes the rules of project building. The only thing the project provides is the Project Object Model (POM file, and yes, it is defined in XML), which provides a description of the project. This decouples the project from the build features. New features can be added that do not require changes in every POM file. Maven provides an impressive number of plugins, which provide the features. One such plugin is the OSGi plugin, which is being developed to create the OSGi bundles and its artifacts. Maven is definitely in the right direction except that the POM file should have been designed for human consumption instead of plugin consumption.
I also learned why many people in the Apache Foundation are eyeing OSGi: containerism. It is hard to get any details but Apache seems have sent the Avalon project to the wholly hunting grounds. Avalon was a project that should have made an OSGi like system available to all the other Apache projects. After a number of years the project was shut down because the group could not unify on a single design (I think this is an euphemism). I recall that a couple of years ago I tried to convince the Avalon project to take a look at OSGi, but I failed miserably to attract their attention.
On this conference, several people told me that the greatest strength of the OSGi is that Apache can not change it. Or as someone said, Apache is great at implementing a specification, but has serious problems with designing from scratch. This makes sense to me, when you have a diverse group of developers, spread around the world, with diverse backgrounds, and when they are all peers, then it is impossible to make complex designs. I am already terribly impressed with the breadth and the quality of the implementations they produce.
After this week, I am convinced that you will see a lot of OSGi at Apache. It seems to be the right moment for the organization to standardize on a single container model, and the OSGi is the best in the market. The Felix incubator project makes it very easy to use an OSGi Framework in an Apache project. The OSGi plugin for maven will make it easy to created the bundles. However, OSGi technology is not a run race for all projects. Some of the code bases are humongous and converting them into components will require effort. The key missing part is good tooling because providing the import export clauses by hand is too much work. This is a common problem and I am currently seeking approval to make the OSGi tools available to the community.
It will be interesting to see how much of the Apache code base will be converted over the coming year. I think many projects will convert. I bet next year I can directly download bundles from Apache.
Add a comment