I currently work on a second version of JBoss Enterprise Web Server which should be released pretty soon. You can find more info about the product itself on the official site. I’ll describe here some behind the scene technical aspects about how it is build and maintained.
One of the problems with majority of Open Source projects is the lack of support for previous version. By the time you or your IT department deploys the software stack needed to run your fancy new application, it is a good chance that those components making your software stack have already released multitude of new version, patches or security updates. If the component breaks backward compatibility (deliberately or unintentionally) you are in big problems. You will either need to fix your application or stay with previous version of the component. The first one will cause you to make the quality testing all over again and if by the time you have tested again a new version emerges, you are in the endless loop.
As an example I’ll give the latest Apache Tomcat 5.5 release.
Version 5.5.32 was released on February 1st. Around that time a JDK Double.parseDouble Denial-Of-Service security issue was discovered () for which we created a workaround and on February 10th the 5.5.53 was released fixing that issue. You may think, wow! that’s cool, open source at its best since a traditional software vendor would need months for that. Not so fast!
Together with fix, a whole bunch of other code changes came along with version 5.5.33, which you can see listed in changelog. Those changes won’t probably break anything from 5.5.32 but you or your QE team will have to verify that statement for sure.
All those problems are foundations upon which companies like mine are basing their existence. We make sure that version we give you doesn’t break the compatibility and that it has all the relevant security issues fixed. We have our QE team that verifies all that before shipping the updates to our customers. At the end this makes your life and your IT department’s life a lot easier. At least you can blame someone if it’s not working.
So, how that works with JBoss Enterprise Web Server? Basically the same way as with any Red Hat Enterprise Linux component. If you are familiar with RHEL updates and .rpm files (or even Fedora for a more limited time) you know that component versions doesn’t change which is a first premise in ensuring the backward compatibility. Only security features and limited
number of enhancements (mainly performance related) are added to base code, tested and made as an update. Inside Red Hat we have a huge engineering team that implements those code updates and patches and handing over the updated code to equally huge Quality engineering team that verifies the resulting package doesn’t break anything.
However there is one small problem with all that. It’s targeted for Linux operating system. Rpm packaging system is deeply embedded inside Linux distribution so although the source package is multiplatform the end result isn’t. Since JBoss Enterprise Web Server was meant to be used on multiple platforms like Microsoft Windows and Oracle Solaris we needed something that would allow us to leverage exiting update code base while at the same time making is platform neutral. That’s how the new build system was born.
February 14, 2011
0 Comments