By Allard, on January 3rd, 2009
Recently, SpringSource released the first version of their DM server. The SpringSource DM Server provides the ability to build enterprise web applications. In the basis, S2DM is a fine mixture of Equinox and Tomcat.
Building OSGi-based web applications was already possible, but it is tedious and error prone work. The typical hello-world example was easy to get going, but as soon as Hibernate or any other framework that helps in larger applications show up, so do your good old class loading problems. For classes to be visible in OSGi, a bundle must declare an Import-Package entry in the Manifest file. Chances are small that Hibernate (even if it were packaged as an OSGi bundle) has these entries for your persistent classes. This is where S2DM server comes in. It allows the more-than-hello-world web applications to be deployed in an environment where you can benefit from the best of OSGi, without the class loading misery. To do this, they have included some extra Manifest entries that are translated to OSGi-compliant directives at load time.
Comparable to the WAR, or better, EAR file, S2DM server supports the PAR file. A PAR file is much like a Jar, with some special headers in the Manifest file, containing all your bundle jars. Some of these jars may contain web bundles, while other typically contain domain classes or the service layer implementation. Contrary to EAR files, a PAR should only contain your own code. It is best practice to deploy frameworks and third party libraries separately. I’ll explain why later on.
With enterprise applications come enterprise development processes, using continuous integration, build servers and maven. In this post, I’ll lay out what you need to get maven to build S2DM server compliant bundles, and better, PAR files.
Continue reading Building Spring DM server compliant OSGi bundles with Maven
By jettro, on August 29th, 2008
This blog item gives you an inside scoop into the continuous integration environment at JTeam. You’ll learn about the why, what and how of continuous integration. The tools we use are mainly open source.
Why continuous integration?
A number of years a go not many people new the term continuous integration. That has changed a lot. All people at JTeam know what it is about and all projects use an environment that is set up to actually do continuous integration. For those that do not know what continuous integration is and those that need a short recap, we briefly explain what we think continuous integration is. Let’s start with the definition from Martin Fowler:
Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily – leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly
Key to continuous integration is delivering high quality artifacts. It is not the silver bullet, developers still need to create great code, but using a good continuous integration process helps finding bugs. Checking your quality standards a long the way increases the effect. Of course extra actions are still necessary. You can think about actions like: manual code reviews, performance tests, functional tests, etc.
JTeam has been using continuous integration from the start. Recently we implemented the second version of our continuous integration environment. We introduced new tools, the process however stayed the same.
Continue reading Continuous Integration (Again)
By jettro, on February 5th, 2008
jQuery(document).ready(function($) { window.setTimeout(‘loadFBShareMe_23()’,5000); }); function loadFBShareMe_23(){ jQuery(document).ready(function($) { $(‘.dd-fbshareme-23′).remove();$(‘.DD_FBSHAREME_AJAX_23′).attr(‘width’,’53′);$(‘.DD_FBSHAREME_AJAX_23′).attr(‘height’,’69′);$(‘.DD_FBSHAREME_AJAX_23′).attr(‘src’,'http://widgets.fbshare.me/files/fbshare.php?url=http://www.gridshore.nl/2008/02/05/jetbrains-teamcity-your-continuous-build-to-the-next-level/&size=large’); }); }
As a lot of you, I am working on larger projects with more than 10 developers, most of the time there are some offshore resources as well. Of course we are using continuous integration, we program our unit tests and run them on every [...]
Popular