-
1. Re: Deployment Best Practices
>>Can I package in a way that will update my system directory to the state >>required for a working production system?
One approach would be to use the maven-feature-plugin "add-features-to-repo" goal to populate a directory with all the bundles specified in the feature (similar in structure to system folder) . This goal is mentioned in passing on the following mail thread (http://cwiki.apache.org/SM/discussion-forums.html#nabble-td23285317 ).
You could then append this newly created folder to the "org.ops4j.pax.url.mvn.defaultRepositories" property defined in "/etc/org.ops4j.pax.url.mvn.cfg". This folder will then act as a "local" repo containing all the bundles that are specified in the feature.
Best Regards
Pat.
Edited by: patfox on Nov 13, 2009 12:21 PM
-
2. Re: Deployment Best Practices
Thanks Pat,
I'm going to give this a proper attempt. I took a quick look at it, and it seems that, in theory, both the features.xml and repository generation capabilities of the features plugin should do the job. It seems there's a serious lack of documentation on this, so if I can get it working properly, I'll report back here.
-
3. Re: Deployment Best Practices
Do you have any status updates on your situation?
I am having problems related to managing our features.xml file:
1. What is the best strategy for keeping our features file versioned with our code, preferebly through a maven project. I tryed to add a module to our existing aggregator project with packaging "xml" and maven complains "Cannot find lifecycle for packaging 'xml'". We tryed this because when we perform a "mvn deploy:deploy-file" to put the features file on our local Nexus server, it generated a pom.xml file that had packaging=xml. Any suggestions?
2. Is there any documentation/examples of the features-maven-plugin? This solution looks promising for managing features.xml files however I cannot find any good resources for explaining how to utilize it properly.
-
4. Re: Deployment Best Practices
Hi,
Getting the features plugin working was non-trivial but I eventually managed it.
I had a few bundles I wanted to package up along with the features.xml and dependencies. Within my maven project, I had submodules for my bundles and one more for the 'features' module. It has file:$/target/classes/features.xml</descriptor> </descriptors> <features> <feature>my-first-feature</feature> </features> <repository>target/my-own-repo</repository> </configuration> </execution> </executions> </plugin> This takes all the bundles in your features.xml, including third party bundles pulled from your Maven repository, and lays them out in target/my-own-repo. My final step was to use the assembly plugin to package this up in a tar.gz. I wanted to be able to install fuse, then extract this tar.gz on top of it so that the user could just start servicemix and have everything just 'work'. So, for completeness, here's the assembly plugin bit: <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-assembly-plugin</artifactId> <version>2.2-beta-4</version> <executions> <execution> <id>package</id> <phase>package</phase> <goals> <goal>single</goal> </goals> <configuration> <descriptors> <descriptor>src/assemble/package.xml</descriptor> </descriptors> <finalName>${pom.artifactId}-${pom.version}</finalName> </configuration> </execution> </executions> </plugin> ... and (some of) the assembly descriptor.... <assembly> <id></id> <!-- intentionally left blank -> http://jira.codehaus.org/browse/MASSEMBLY-301 --> <formats> <format>tar.gz</format> </formats> <includeBaseDirectory>false</includeBaseDirectory> <fileSets> <fileSet> <directory>target/my-own-repo</directory> <outputDirectory>my-own-repo</outputDirectory> <excludes> <exclude> org/apache/camel/** </exclude> <exclude> org/apache/cxf/** </exclude> <exclude>org/apache/servicemix/bundles/**</exclude> </excludes> </fileSet> <fileSet> <directory>target/my-own-repo</directory> <outputDirectory>system</outputDirectory> <includes> <include>org/apache/camel/**</include> <include>org/apache/cxf/**</include> <include>org/apache/servicemix/bundles/**</include> </includes> </fileSet> <fileSet> <directory>target/my-own-repo/</directory> <outputDirectory>system</outputDirectory> <includes> <include>org/apache/camel/**</include> <include>org/apache/cxf/**</include> </includes> </fileSet> <fileSet> <!-- Overwrite ServiceMix/Fuse-provided configuration --> <directory>target/classes/etc</directory> <outputDirectory>etc</outputDirectory> </fileSet> </fileSets> <dependencySets> <dependencySet> <outputDirectory>deploy</outputDirectory> <includes> <include>com.oracle.jdbc:ojdbc14</include> </includes> </dependencySet> </dependencySets> <files> <file> <source>$/target/classes/features.xmlmy-own-repo/org/test/me/$/$ </outputDirectory> <destName>$-$-features.xml
As you can see, I had to put some of thee bundles in the system repository. This prevented version conflicts with the versions provided by fuse. Getting the dependencies right and avoiding conflicts was a long and painful process requiring lots of trial and error. I needed a different version of camel to the default one, and it caused endless headaches. This is the biggest drawback of Fuse and since I can't see any major benefits of using Fuse over plain Felix + the bundles I require, I might just move away from this hassle.
I also had a custom org.apache.servicemix.features.cfg file in my package which overwrites the default one. It has my featuresUrl (mvn:org.test.me/features-package/${pom.version}/xml/features) at the end. I modified to featuresBoot to include my feature and remove some of the default ServiceMix ones.
So, I hope that contains all the info needed to get your feature going. If anyone comes up with any improvements, please let me know! This setup works and gives me something which is easily installed, but it's far from perfect.
-
