THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
As shown in the project types, each different project type can be deployed to a server using the JBI plugin (through the ANT tasks defined in the JBI specification). The only issue here can be working out dependencies and trying to make sure that you deploy the dependencies. This means if you have a Service Assembly you wish to deploy you need to first get the dependent components (and maybe even the dependent shared libraries) to deploy. The Maven2 JBI plugin provides a couple of goals that can help you work through this.
mvn jbi:projectDeploy projectDeploy
If you have created you assemblies, service units, components and shared libraries as Maven projects (which all ServiceMix components are) you can use this goal. In essence the plugin will walk the dependencies starting in the current project then deploy each of the dependencies in reverse order. This can be very useful if you want to quickly get up and running with a new Service Assembly against an installed instance of Apache ServiceMix.
| Info | ||
|---|---|---|
| ||
If you are working with the jbi:projectDeploy you should not that you may want to disable dependency deployment, if you are deploying to a server which has other components sharing these dependencies they you can get problems while trying to undeploy and redeploy them. If this is the case you can add the parameter deployDependencies at set it to false in either you service assembly or component pom.xml. |
mvn jbi:servicemix servicemix
If you quickly want to get up and running with Apache ServiceMix the best way is to use this goal. As an extension of the deployProject goal is works in much the same way, the difference is that this goal downloads and starts a copy of Apache ServiceMix within Maven so you don't need to have a version installed, this can be very useful if you are working on trying out functionality and want to simply test your projects.
...
If you are only using dependencies for your Component (or any project type) from remote repositories then you can ignore this section. However, if you have jars or zip files that which are perhaps internal to your company or a 3rd party jar which you just want to put in your local repository and use as a dependency then you need to be sure to generate a POM for these files. If you do not then these dependencies won't be included in the installer zip file for your jbi Component (or other project type) no matter what scope you specify. Here's how to tell maven 2 to install the jar and generate a pom for it:
| Code Block |
|---|
 mvnmvn install:install-file -Dfile=abc.jar -DgroupId=com.mycompany.myproduct -DartifactId=abc -Dversion=1.0 -Dpackaging=jar -DgeneratePom=true |
If you leave off the generatePom parameter, then in your local repository you'll just see the jar file with version attached, e.g. "abc-1.0.jar". But if you include the generatePom, then you'll also see "abc-1.0.pom". You add the dependency to your JBI project like this:
| Code Block |
|---|
<dependency> Â <groupId>com.mycompany.myproduct</groupId> Â <artifactId>abc</artifactId> Â <version>1.0</version> Â <scope>compile</scope> </dependency> |
...