Maven + Apache Felix + CXF + DOSGi Series
This is a blog series on how to combine Maven + Apache Felix + CXF + DOSGi. The information presented may not be correct and some parts can definitely be improved. Not all posts are published immediately, so stay tuned!
Part 1 Maven + Apache Felix: Easy Development and Debugging With Eclipse
Part 2 Maven + Apache Felix: Best Practices
Part 3 Maven + Apache Felix + CXF: Creating a RESTful Webservice with CXF. A Simple String Example.
Part 4 Maven + Apache Felix + CXF: Creating a RESTful Webservice with CXF. Returning and Object.
Part 5 Maven + Apache Felix + CXF: Creating a RESTful Webservice with CXF. Consuming an Object
Part 6 CXF RESTful Webservices: Running on a Different Port
Part 7 Maven + Apache Felix + CXF: RESTful Webservice with CXF. Using POST.
Part 8 Maven + Apache Felix + CXF: Securing a Service with HTTP Basic Authentication
Part 9 Maven + Apache Felix: Strategy to Handle non-OSGi Dependencies
Part 10 Apache Felix: Running Two Instances of Felix Launcher in The Eclipse
Part 11 Maven + Apache Felix + CXF + DOSGi: An Example of DOSGi Service
IzPack: Installing Only When Version Was Changed
This post describes a concept of updating a product only when a Maven version of it was changed.
Assume you have a product A, installable by IzPack and built by Maven. When you install product A, you may use RegistryInstallerListener to add entry to the registry. In RegistrySpec.xml (where you provide target key where to store information) you use Maven ${project.version} property. Therefore, when the product A will be installed, the Maven version will be stored in the Registry. Next time you install product A you use read that entry from a registry (here I describe how to do that in IzPack 4. This is out-of-the-box in IzPack 5) and then compare the Maven versions (you may use this post information to create a Maven panel) and determine, whereas to install/update a product.
Product A may also be independent installer, launched from another installer. For instance, if product A installer requires administrative rights, and it is included from product B, which doesn' require administrative right, you would like to avoid UAC as much as possible. So from product B you can check version of product A and determine, whereas you need to launch it.
Comparing Maven String Versions
This posts describes comparint Maven String versions. It is assumed, that you have a Maven-managed project.
Add a maven-artifact dependency
<dependency> <groupId>org.apache.maven</groupId> <artifactId>maven-artifact</artifactId> <version>3.0.3</version> </dependency>
Then you could write something like this:
public int compare(String version1, String version2) {
ArtifactVersion mavenVersion1 = new DefaultArtifactVersion(version1);
ArtifactVersion mavenVersion2 = new DefaultArtifactVersion(version2);
int result = mavenVersion1.compareTo(mavenVersion2);
return result;
}
Panel for Reading Registry in IzPack 4
The panel called RegistryReaderPanel. It can be used in automated installation (silent installations). However, it can be used only once (can be easily extended). Code depends on IzPack COI tools. So COI tools classes need to be delivered together with the panel. Panel is built using Maven, so COI tools are shaded with Maven Shade Plugin. By default we are reading from HKEY_LOCAL_MACHINE registry root. You have to provide an xml file specifying what you want to read and to which variable to store the read value. Here is an example:
<registryReader>
<registry key="SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\myApp"
name="DisplayVersion" default="null" variable="myApp.version" />
</registryReader>
You may have several registry entries to read multiple keys. name specifies registry key. variable specifies to which variable to store the value. default specifies what should be a default value, when key was not found.
You will also need to provide COI dlls in install.xml:
<native type="3rdparty" name="COIOSHelper.dll" stage="both"> <os family="windows" /> </native> <native type="3rdparty" name="COIOSHelper_x64.dll" stage="both"> <os family="windows" /> </native>
You will need to separate COI package yourself and add it to your Maven repository.
And here is the panel source:izpackExtensions-registryReader
IzPack: Adding Custom Panels without Rebuilding Standalone Compiler
On FAQ page of izpack-maven-plugin there is a link on how to include own custom panels without rebuilding standalone compiler. I will describe our own approach.
We have a specific Maven project for IzPack extensions. For every custom panel we have a child module. Basically, each child module is just a plain Java project with required IzPack structure.
We have a special Maven parent project for all our installers. This parent defines 3 steps to build IzPack installer in pluginManagement section:
- Copy all dependencies to specific folder defined by child installers. Then we will pick up these dumped files in
install.xmlfile. It is used to dump our own product, third party stuff and our own custom panels, which are referenced from dependency section inpom.xml - Filtering step. We run filtering through all IzPack files to automatically replace version, name, path to files (fx dumped in previous step) in
install.xmland all other resources. Filtered files are copied to specific staging directory. We use Maven resources plugin for that purpose. - The last step defines the routine to build IzPack installation
All child projects have to do is to inherit these plugins from parent.
As I said, our custom panels are ordinary Maven projects. In each installer in dependency section in pom.xml we add a reference to custom panel project. As I described above, all jars are dumped in specific folder and we just have to pick them in our install.xml:
<panel classname="MyPanel" jar="${dependencies.dir}/izpackExtensions-myPanel-${izpackExtensions.version}.jar" />
Where dependencies.dir and izpackExtensions.version are ordinary Maven variables which are substituted during filtering step.
Axis2 + Guice + Maven + Servlets
In this post I will continue Axis2 + Maven + Servlets + Tomcat topic. I will refer to it as previous post, because some stuff will be repeated. I will show how to have Google Guice dependency injection in Axis2 webservices.
I will reuse technique from sagara's Blog. It works perfectly, but it can be improved a little.
The same Axis2 wsdl generation technique will be used, so I will not refer to it again.
Again, we start by our
JAX-WS web services + Maven + Tomcat
There is an awesome article about Deploy JAX-WS web services on Tomcat. It describes how to have a web service running without much effort.
We will follow the article and do the same, but with three differences:
- We will build it with Maven
- We will omit interface in the web service
- We will not copy jars to the Tomcat. All dependencies will be managed by Maven
Let's start by creating a fresh maven project jaxwsExample. pom.xml will contain single
Axis2 + Maven + Servlets + Tomcat
In this post I will show how to combine axis2 web services with maven and a war project and make it run under Tomcat 6.
We will try to avoid holding auto-generated sources, instead we will generate them and compile whenever they are needed. We will also try to make the whole process as automatic, as possible.
Start by
Checking out PDE as Maven Project in Eclipse
Ealier I though about bringing maven structure to mavenized PDE projects. That it instead of having
- trunk # dk.sorokin.maksim.feature # dk.sorokin.maksim.plugin # dk.sorokin.maksim.parent
where dk.sorokin.maksim.parent is a project containing parent pom.xml, have more standard maven structure:
- trunk
# dk.sorokin.maksim.parent
@ dk.sorokin.maksim.feature
@ dk.sorokin.maksim.plugin
Latter case has more benefits. One could use "Check out as Maven Project...". When a new plugin is added, changes immediately are seen on the parent. There will be no need in providing "relativePath" to the parent in the modules.
However, as far as I see, at the moment it is not possible. The problem is that together with Mavenizing the project, we still want to preserve developers to work with the project the way they worked before. We need to have ".project" and ".classpath" files commited to repository. M2Eclipse Eclipse plugin fucks up ".classpath" file and adds some new settings during "Check out as Maven Project...".
Therefore, currently we will use a plain PDE structure and will not check out projects as Maven ones.
Building RCP Deliverable with Tycho
We managed to build our Eclipse based product deliverable with Eclipse. Yes, it is possible! I suggest looking into the following resources:
- Packaging type eclipse-repository shall support publishing of categories, features and bundles
- Demo RCP Application and P2 Updateable Eclipse Product
- itp04-rcp demo application
Especially, take a look at the last demo link.