Packaging

As described previously, the plugin supports different packaging to build JBI artifacts.
This section details and illustrates them. As a general matter, defining specific packaging allows to use JBI archives as dependencies in other projects.
It also allows to define the build life cycle to apply on such a project.

When installing such artifacts in a repository, only the JBI archive is installed.

jbi-component

This packaging identifies a Maven2 project as being the development of a JBI component (either a binding component, or a service engine).
The associated language is Java, which allows to use maven-eclipse-plugin to make this project an Eclipse project.

The build life cycle of a JBI component is:

jbi-service-unit

This packaging identifies a Maven2 project as being the development of a service-unit.
The associated language is Java, which allows to use maven-eclipse-plugin to make this project an Eclipse project.

The build life cycle of a service-unit is:

jbi-service-assembly

This packaging identifies a Maven2 project as being the development of a service assembly.
The associated language is Maven2's default language.

The build life cycle of a service assembly is:

jbi-shared-library

This packaging identifies a Maven2 project as being the development of a shared-library.
The associated language is Java, which allows to use maven-eclipse-plugin to make this project an Eclipse project.

The build life cycle of a shared-library is:

Additional jbi resources packaging

For service unit, component, shared library ... you can provided a directory thank to following xml element additionalJBIResourceDirectory,

which allows to specify a directory where all contained files will be added to zip archive of the su, sl, component ...

This previous mechanism provide a way to package additional jbi resources into your su, sl, component as in the following example:

 <build>
    <plugins>
      <plugin>
	<groupId>org.ow2.petals</groupId>
	<artifactId>maven-petals-plugin</artifactId>
	<extensions>true</extensions>
	<configuration>
		<additionalJBIResourceDirectory>${project.build.directory}/additionals/</additionalJBIResourceDirectory>
	</configuration>
      </plugin>
	<plugin>
         <groupId>org.apache.maven.plugins</groupId>
         <artifactId>maven-dependency-plugin</artifactId>
         <version>2.3</version>
         <executions>
           <execution>
                        <id>unpackaging</id>
                        <phase>process-resources</phase>
                        <goals>
                            <goal>unpack</goal>
                        </goals>
                        <configuration>
                            <artifactItems>
                                <artifactItem>
			      	  <groupId>com.ebmwebsourcing.petals-esb-enterprise.usecase1.node2</groupId>
				  <artifactId>su-filetransfer-P6-provide</artifactId>
				  <version>0-SNAPSHOT</version>
				  <type>jbi-service-unit</type>
                                    <overWrite>false</overWrite>
                                    <outputDirectory>${project.build.directory}/additionals/</outputDirectory>
			      <includes>**/*.wsdl</includes>
			      <excludes>**/*.class,**/*.jar</excludes>
                                </artifactItem>
                            </artifactItems>
                        </configuration>
                    </execution>
         </executions>
       </plugin>
    </plugins>
  </build>

In the previous example, during the mvn clean install of the su-bpel-S9-provide, maven just unpackage the P6.wsdl located in su-filetransfer-P6-provide dependency and copy the wsdl into 

${project.build.directory}/additionals/ --> corresponding to target/additionals/

After that the maven-petals-plugin take the P6.wsdl file located into target/additionals precised by the following line:

<additionalJBIResourceDirectory>${project.build.directory}/additionals</additionalJBIResourceDirectory>

and copy this wsdl file into your su-bpel-S9-provided.zip (it will be copy directly at the root path into zip file)

Goals

As explained in introduction, the Petals plugin for Maven2 supports several goals.
This section details and illustrates them.

The available goals are:

• jbi-package: used to package a JBI archive.
• jbi-configure: used to configure a deliverable JBI archive.
• jbi-install: used to install a JBI archive.
• jbi-start: used to start a composant or a service assembly.
• jbi-stop: used to stop a composant or a service assembly.
• jbi-uninstall: used to uninstall a JBI archive.

jbi-package

This goal allows the creation of a JBI archive.
Depending on the project nature (which is defined by its packaging attribute in the pom.xml), the right archive will be created.

For a service assembly project, the service-units that are contained in this assembly must be declared as dependencies in the POM.

How is updated the JBI descriptor ?

As explain below, the parameter petalsesbsnapshot:updateJBIXml\ is used to generated the JBI descriptor from the Maven POM file. Updates are done according to the nature of the JBI archive and following rules.

JBI descriptor updates of a component archive

JBI descriptor updates of a service unit

JBI descriptor updates of a service assembly

JBI descriptor updates of a shared library

jbi-configure

This goal allows the configuration of a JBI archive. Depending on the JBI archive nature (which is defined by its packaging attribute), the right configuration archive will be applied. Only deliverable JBI archives (component, service assembly and shared library) can be configured by this goal, ie. service unit archive is excluded. The main use-case is the configuration of a JBI archive delivered by a provider.

Configuration of a service assembly, ans its service units, is not implemented yet.

Use-case example

To run following usecases fully on command line, it is needed to have the following dummy POM file: <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> <modelVersion>4.0.0</modelVersion> <name>Dummy POM</name> <artifactId>foo-bar</artifactId> <groupId>com.foo.bar</groupId> <version>SNAPSHOT</version> <packaging>pom</packaging> </project> To run following usecases using a configuration packaged as Maven artifact (org.foo.bar:configuration:1.0.0), it is needed to have the following dummy POM file: <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> <modelVersion>4.0.0</modelVersion> <name>Dummy POM</name> <artifactId>foo-bar</artifactId> <groupId>com.foo.bar</groupId> <version>0-SNAPSHOT</version> <packaging>pom</packaging> <build> <plugins> <plugin> <groupId>org.ow2.petals</groupId> <artifactId>maven-petals-plugin</artifactId> <version>2.1.4</version>  <extensions>true</extensions> <dependencies> <dependency> <groupId>org.foo.bar</groupId> <artifactId>configuration</artifactId> <version>1.0.0</version> </dependency> </dependencies> </plugin> </plugins> </build> </project>

Use-case 1 : How to set a JMS driver into a component

For example, we wish, on the same JBI container:

• to use the ActiveMQ v4.1.1 as JMS server and the BC JMS to interact with Petals ESB through JMS messages. So the BC JMS needs the shared library associated  to its ActiveMQ server version.
• to use the ActiveMQ v5.2.0 as JMS server and the BC Soap to interact with Petals ESB through SOAP over JMS. So the BC Soap needs the shared library associated  to its ActiveMQ server version.

In one hand, we need to deploy these shared libraries on the JBI container. So, each shared library MUST have a different JBI identifier name, for example petals-sl-jms-activemq-4 et petals-sl-jms-activemq-5.

In other hand, we don't want to change the content of the component JBI descriptor when upgrading a shared library because of bug fixes. So, we can you use the major digit of the version as version attribute for shared library identifier.

So, we need to inject this JBI identifier name and version attribute of the shared libraries in the JBI components:

• First, we configure the shared libraries using the goal 'jbi-configure':

mvn org.ow2.petals:maven-petals-plugin:2.1.4:jbi-configure -DgroupId=org.ow2.petals -DartifactId=petals-sl-jms-activemq -Dversion=4.1.1 -DjbiIdentifiersMappingFileURL=http://myhost:myport/myPath/jbi-identifiers-mapping-file.properties

mvn org.ow2.petals:maven-petals-plugin:2.1.4:jbi-configure -DgroupId=org.ow2.petals -DartifactId=petals-sl-jms-activemq -Dversion=5.2.0 -DjbiIdentifiersMappingFileURL=http://myhost:myport/myPath/jbi-identifiers-mapping-file.properties

• Next, we configure the components:

mvn org.ow2.petals:maven-petals-plugin:2.1.4:jbi-configure -DgroupId=org.ow2.petals -DartifactId=petals-bc-jms -Dversion=3.1.1 -DjbiIdentifiersMappingFileURL=http://myhost:myport/myPath/jbi-identifiers-mapping-file.properties -DjbiSharedLibrariesMappingFileURL=http://myhost:myport/myPath/jbi-shared-libraries-list-mapping-file.properties -DjbiVersionsMappingFileURL=http://myhost:myport/myPath/jbi-versions-mapping-file.properties

mvn org.ow2.petals:maven-petals-plugin:2.1.4:jbi-configure -DgroupId=org.ow2.petals -DartifactId=petals-bc-soap -Dversion=4.0.2 -DjbiIdentifiersMappingFileURL=http://myhost:myport/myPath/jbi-identifiers-mapping-file.properties -DjbiSharedLibrariesMappingFileURL=http://myhost:myport/myPath/jbi-shared-libraries-list-mapping-file.properties -DjbiVersionsMappingFileURL=http://myhost:myport/myPath/jbi-versions-mapping-file.properties

• using the following content of the file 'jbi-identifiers-mapping-file.properties':

*\:*\:*\:jbi-component = ${artifactId}-${version.major}
*\:*\:*\:jbi-shared-library = ${artifactId}-${version.major}
*\:*\:*\:jbi-service-unit = ${artifactId}-${version}
*\:*\:*\:jbi-service-assembly = ${artifactId}-${version}

• using the following content of the file 'jbi-shared-libraries-list-mapping-file.properties':

org.ow2.petals\:petals-bc-jms\:*\:1 = org.ow2.petals:petals-sl-jms-activemq:4.1.1
org.ow2.petals\:petals-bc-soap\:*\:1 = org.ow2.petals:petals-sl-jms-activemq:5.2.0

• using the following content of the file 'jbi-versions-mapping-file.properties':

*\:*\:*\:jbi-shared-library = ${version.major}

Use-case 2 : How to package an interceptor

The Petals CDK proposes some extension points to add specific processing. These points are named 'interceptors'. An interceptor must be packaged into the JBI component archive. This packaging can be done by the goal 'jbi-configure'.

For example, we wish to package our interceptor, available as a Maven artifact: org.ow2.petals.samples:my-interceptor:1.0.0:jar, into the BC Soap. So we will configure the BC Soap with an extra class-path element (our interceptor). And, as our interceptor is only needed to the component runtime, not to the component bootstrap, we will use the following command line:

mvn org.ow2.petals:maven-petals-plugin:2.1.4:jbi-configure -DgroupId=org.ow2.petals -DartifactId=petals-bc-soap -Dversion=4.0.2 -DjbiExtraComponentClasspathMappingURL=file:///home/myuser/my-extra-component-classpath-mapping.properties

where the file /home/myuser/my-extra-component-classpath-mapping.properties contains:

org.ow2.petals\:petals-bc-soap\:*\:1=org.ow2.petals.samples\:my-interceptor\:1.0.0

Use-case 3 : How to install the same component in two different versions on the same container

For example, we wish, on the same JBI container:

• to use the BC Soap version 3.1.4 to connect old service assemblies,
• to use the BC Soap version 4.0.5 to use the last functions provided by the BC Soap.

This needs different JBI identifier in each component. So we can suffix the JBI identifier with the major digit of the version two create different identifiers for each component:

mvn org.ow2.petals:maven-petals-plugin:2.1.4:jbi-configure -DgroupId=org.ow2.petals -DartifactId=petals-bc-soap -Dversion=3.1.4 -DjbiIdentifiersMappingFileURL=http://myhost:myport/myPath/jbi-identifiers-mapping-file.properties

mvn org.ow2.petals:maven-petals-plugin:2.1.4:jbi-configure -DgroupId=org.ow2.petals -DartifactId=petals-bc-soap -Dversion=4.0.5 -DjbiIdentifiersMappingFileURL=http://myhost:myport/myPath/jbi-identifiers-mapping-file.properties

using the following content of the file 'jbi-identifiers-mapping-file.properties':

*\:*\:*\:jbi-component = ${artifactId}-${version.major}
*\:*\:*\:jbi-shared-library = ${artifactId}-${version.major}
*\:*\:*\:jbi-service-unit = ${artifactId}-${version}
*\:*\:*\:jbi-service-assembly = ${artifactId}-${version}

To use a configuration available as Maven artifact, use the following command line: mvn org.ow2.petals:maven-petals-plugin:2.1.4:jbi-configure -DgroupId=org.ow2.petals -DartifactId=petals-bc-soap -Dversion=3.1.4 -DjbiIdentifiersMappingFile=jbi-identifiers-mapping-file.properties where jbi-identifiers-mapping-file.properties is available as resource into the configuration Maven artifact.

Don't forget to configure your service assemblies to be able to deploy them on the right component identified by the right JBI identifier.

Parameters

jbi-install

This goal allows the installation or the deployment of a JBI archive. According to the JBI archive nature, defined in the associated Maven POM file, the right JMX API will be used.

For remote installation, the JBI archive will be uploaded on the remote platform. Apache Wagon is in charge of uploading the JBI archive, using the parameters: protocol, serverId, remoteDirectory.

When installing a JBI component that needs one or more uninstalled previously shared libraries, they will be installed automatically if:

• the parameter installMissingSharedLibraries is enabled,
• the shared libraries are declared as dependencies in the component project POM file.

You can't use this feature if shared libraries of the component have been set using the goal jbi-configure.

When installaing a JBI service assembly that needs one or more uninstalled previously components, they will be installed automatically if:

• the parameter startMissingComponents is enabled,
• the components are declared as dependencies in the service units project POM files. Note, as components have not to be packaged into service-unit archive, their dependency scopes MUST be set to 'provided'.
• if one component needs a shared library installation, it will be driven by the parameter installMissingSharedLibraries.

This goal has no sens for a service-unit archive. If you invoke jbi-install on a service-unit project, it will be ignored.

Parameters

Parameter	Type	Default Value	Description
jbiName	String	${project.artifactId}-${project.version}	Name of the JBI archive without path and extension
verbose	Boolean	false	Verbose mode. When activated, information logged at the INFO level are displayed. Information from other levels are always displayed, independently of this mode activation.
jbiDirectory	String	${basedir}/src/main/jbi	Path to JBI sources. This path contains the JBI descriptor (jbi.xml). Every file being in this directory will be packaged in the JBI archive under the META-INF folder.
host	String	localhost	Host-name or IP address of the Petals container in which the archive will be installed
port	String	7700	JMX port number of Petals container
username	String	-	JMX username
password	String	-	JMX user password
force	Boolean	false	If enabled and needed, according to the JBI archive: jbi-component if the component is already installed, it will be uninstalled before to be installed. Otherwise an error is raised. if a service assembly is deployed on the component, it will be undeployed before to uninstall the component, if a shared library is needed and not installed, it will be installed from Maven repositories jbi-service-assembly if the service assembly is already deployed, it will be undeployed before to be deployed. Otherwise an error is raised. missing components are installed from Maven repositories jbi-shared-library shutdown installed components using the shared library if the shared library is already installed, it will be uninstalled before to be installed. Otherwise an error is raised.
startMissingComponents	Boolean	true	This parameter makes sense only to deploy a service assembly. If enabled, the components needed by the service assembly will be installed and started automatically. If shared libraries are needed by a component, their automatic installation is driven by the parameter 'installMissingSharedLibraries'. Components MUST be declared as dependency in service unit projects.
installMissingSharedLibraries	Boolean	true	This parameter makes sense only to deploy a component or a service assembly. If enabled, shared libraries needed by the component will be automatically installed,
serverId	String	-	This parameter makes sense only to install or deploy on a remote container. It's a reference to retrieve credential to upload archive on the remote container. This identifier MUST be defined in the Maven file: settings.xml in the server section.
protocol	String	scp	This parameter makes sense only to install or deploy on a remote container. Defines the protocol to use to upload the JBI archive on the remote container. The protocol MUST be supported by Apache Wagon.
remoteDirectory	String	/tmp	This parameter makes sense only to install or deploy on a remote container. Defines the directory on the remote container that will receive uploaded JBI archive.

jbi-start

This goal allows the start of a JBI archive. According to the JBI archive nature, defined in the associated Maven POM file, the right JMX API will be used. This goal makes no sens for shared library and service unit. If you invoke jbi-start on such a project, it will be ignored.

jbi-stop

This goal allows the stop of a JBI archive. According to the JBI archive nature, defined in the associated Maven POM file, the right JMX API will be used. This goal makes no sens for shared library and service unit. If you invoke jbi-stop on such a project, it will be ignored.

jbi-uninstall (not implemented yet)

This goal allows the uninstall a JBI archive. According to the JBI archive nature, defined in the associated Maven POM file, the right JMX API will be used. This goal makes no sens for service unit. If you invoke jbi-uninstall on such a project, it will be ignored.