[savara-commits] savara SVN: r92 - runtime/trunk/docs/samplesguide and 13 other directories.

do-not-reply at jboss.org do-not-reply at jboss.org
Wed Nov 25 17:14:32 EST 2009


Author: objectiser
Date: 2009-11-25 17:14:32 -0500 (Wed, 25 Nov 2009)
New Revision: 92

Added:
   runtime/trunk/docs/samplesguide/src/main/module/convawareesb.xml
   tools/eclipse/trunk/docs/userguide/src/main/module/bpel.xml
   tools/eclipse/trunk/docs/userguide/src/main/module/conversation-validation.xml
   validator/trunk/docs/pom.xml
   validator/trunk/docs/samplesguide/
   validator/trunk/docs/samplesguide/pom.xml
   validator/trunk/docs/samplesguide/src/
   validator/trunk/docs/samplesguide/src/main/
   validator/trunk/docs/samplesguide/src/main/images/
   validator/trunk/docs/samplesguide/src/main/images/ChoreoMonReady.jpg
   validator/trunk/docs/samplesguide/src/main/images/MonitorMenu.jpg
   validator/trunk/docs/samplesguide/src/main/images/TrailblazerWebPage.jpg
   validator/trunk/docs/samplesguide/src/main/master.xml
   validator/trunk/docs/samplesguide/src/main/module/
   validator/trunk/docs/samplesguide/src/main/module/author_group.xml
   validator/trunk/docs/samplesguide/src/main/module/cdlvalidator.xml
   validator/trunk/docs/samplesguide/src/main/module/overview.xml
   validator/trunk/docs/samplesguide/src/main/xslt/
   validator/trunk/docs/samplesguide/src/main/xslt/pdf.xsl
   validator/trunk/pom.xml
Removed:
   runtime/trunk/docs/samplesguide/src/main/module/cdlconformance.xml
   runtime/trunk/docs/samplesguide/src/main/module/cdlvalidator.xml
   tools/eclipse/trunk/docs/userguide/src/main/module/bpel-governance.xml
   tools/eclipse/trunk/docs/userguide/src/main/module/cdlconformance.xml
   tools/eclipse/trunk/docs/userguide/src/main/module/conversation-validation-with-cdl.xml
Modified:
   runtime/trunk/docs/samplesguide/pom.xml
   runtime/trunk/docs/samplesguide/src/main/master.xml
   runtime/trunk/pom.xml
   runtime/trunk/samples/jbossesb/brokerage/broker/pom.xml
   tools/eclipse/trunk/docs/userguide/src/main/master.xml
Log:
Further reorganisation of the documentation - still changes to make from overlord-cdl to savara.

Modified: runtime/trunk/docs/samplesguide/pom.xml
===================================================================
--- runtime/trunk/docs/samplesguide/pom.xml	2009-11-24 23:47:13 UTC (rev 91)
+++ runtime/trunk/docs/samplesguide/pom.xml	2009-11-25 22:14:32 UTC (rev 92)
@@ -4,10 +4,10 @@
 
     <modelVersion>4.0.0</modelVersion>
 
-    <groupId>org.jboss.savara.docs</groupId>
+    <groupId>org.jboss.savara.runtime.docs</groupId>
     <artifactId>samplesguide</artifactId>
     <packaging>jdocbook</packaging>
-    <name>Savara::Runtime::docs::samplesguide</name>
+    <name>Savara::Runtime::Docs::SamplesGuide</name>
 
    <parent>
     <groupId>org.jboss.savara.runtime</groupId>
@@ -59,7 +59,7 @@
 		                <format>
 		                    <formatName>pdf</formatName>
 		                    <stylesheetResource>file:///${basedir}/src/main/xslt/pdf.xsl</stylesheetResource>
-				            <finalName>SamplesGuide.pdf</finalName>
+				            <finalName>SAVARA-Runtime-SamplesGuide.pdf</finalName>
 		                </format>
 						<format>
 						    <formatName>html</formatName>

Modified: runtime/trunk/docs/samplesguide/src/main/master.xml
===================================================================
--- runtime/trunk/docs/samplesguide/src/main/master.xml	2009-11-24 23:47:13 UTC (rev 91)
+++ runtime/trunk/docs/samplesguide/src/main/master.xml	2009-11-25 22:14:32 UTC (rev 92)
@@ -12,7 +12,6 @@
   
   <toc/>
   <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="module/overview.xml"/>
-  <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="module/cdlvalidator.xml"/>
-  <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="module/cdlconformance.xml"/>
+  <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="module/convawareesb.xml"/>
 
 </book>

Deleted: runtime/trunk/docs/samplesguide/src/main/module/cdlconformance.xml
===================================================================
--- runtime/trunk/docs/samplesguide/src/main/module/cdlconformance.xml	2009-11-24 23:47:13 UTC (rev 91)
+++ runtime/trunk/docs/samplesguide/src/main/module/cdlconformance.xml	2009-11-25 22:14:32 UTC (rev 92)
@@ -1,192 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
-]>
-<chapter id="cdlconformance">
-  <title>CDL Conformance</title>
-
-  <para>
-There are two examples to demonstrate the conversation aware ESB actions(for both stateful and stateless), and the conformance checking against a choreography.
-  </para>
-  <para> 
-These are <filename>purchasing</filename>, a simple customer/supplier example with two associated Eclipse projects (<filename>purchasing-store-stateful/less</filename> and <filename>purchasing-models</filename>), and <filename>brokerage</filename> which extends the purchasing example through the introduction of a broker that mediates between potentially multiple suppliers to find the best deal, defined within three Eclipse projects (<filename>brokerage-broker-stateful/less</filename>, <filename>brokerage-supplier-stateful/less</filename> and <filename>brokerage-models</filename>).
-  </para>
-  <para>
-These examples make use of a common <emphasis>Credit Agency</emphasis> service, defined within the <filename>common-creditAgency-stateful/less</filename> Eclipse project, and are executed through the use of client applications defined in the <filename>${OverlordCDL}/samples/client</filename> folder.
-  </para>
-
-   <warning>
-	   At the moment, the conversation aware ESB runtime doesn't support the hot-deploy. That means if you update the business pojo class, such as <emphasis role="bold">$creditAgency/src/main/com/acme/services/creditAgency/CreditAgencyPurchase.java</emphasis> file,
-	   You need to re-deploy it, and then <emphasis role="bold">restart the server </emphasis> to cause it to take effect. This issue has been tracked under <ulink url="https://jira.jboss.org/jira/browse/SOAG-72">https://jira.jboss.org/jira/browse/SOAG-72</ulink>. Will be fixed in the next release.
-   </warning>	
-	
-  <section>
-	<title>Purchasing Example</title>
-    <section>
-     <title>Overview</title>
-	<para>
-The purchasing example describes the interactions between a Buyer, Store and Credit Agency. The flow for this example would be:
-	</para>
-	<itemizedlist>
-		<listitem>
-Buyer send a 'buy' request to Store
-		</listitem>
-		<listitem>
-Store send a 'credit check' request to the Credit Agency.
-		</listitem>
-		<listitem>
-If the Credit Agency returns a successful message, then the Store will send a 'BuyConfirmed' to user.
-		</listitem>
-		<listitem>
-If the Credit Agency returns a failed message, then the Store will send a 'BuyFailed' to user.
-		</listitem>
-	</itemizedlist>
-
-	<para>
-To check conformance, we need to refer to the model and service implementation projects in the Eclipse environment.
-The <filename>purchasing-models</filename> project contains the CDL used to perform conformance checking on the <filename>src/main/resources/META-INF/jboss-esb.xml</filename> files within the other projects. A full explanation of the conversation aware ESB actions can be found in the <emphasis>Conversational Aware ESB</emphasis> section of the <emphasis>User Guide</emphasis> in the <filename>docs</filename> folder.
-	</para>
-	<para>
-To provide a simple demonstration of the conformance checking:
-	</para>
-	<orderedlist>
-		<listitem>
-Double click on <filename>purchasing-store[-stateful/less]/src/main/resources/META-INF/jboss-esb.xml</filename>
-		</listitem>
-		<listitem>
-Scroll down to the second action, within the first service. This represents a <emphasis>ReceiveMessageAction</emphasis> and has a property defining the message type to be received.
-		</listitem>
-		<listitem>
-Edit the 'messageType' property value, e.g. by adding an 'X' to the end of the value.
-		</listitem>
-		<listitem>
-Then save the file. This should result in an error being generated, complaining about a type mismatch.
-		</listitem>
-	</orderedlist>
-	<para>
-The information regarding the expected message type is obtained from the choreography description in the <filename>purchasing-models</filename> project. To identify the precise interaction within the choreography that this error relates to, select the context menu associated with the error and choose the Quick Fix menu item. This will display a dialog with a list of fixes, select the <emphasis>Show referenced description</emphasis> option and press OK. This will cause the relevant interaction within the choreography description to be displayed.
-	</para>
-	<para>
-Another Quick Fix option associated with this error is <emphasis>Update from Referenced Description</emphasis>. By selecting this option, you will notice that the message type is changed back to the value without the 'X'.
-	</para>
-    </section>
-    
-	<section>
-		<title>Running the Example</title>
-		<para>
-		 This example has two versions, stateful and stateless. in the sample folder, you will find the samples were grouped in stateful and stateless folder.
-		 One is the stateful purchasing example (this is the example that we had since M1 release),the other is stateless purchasing example that is introduced in the M2 release.		 
-		</para>
-		<orderedlist>
-			<listitem>
-		First step is to install the ESB services. (Presumely the JBoss ESB server started already)
-		In a command window, Go to the the <filename>$Overlord/samples/stateful</filename> folder (or <filename>$Overlord/sample/stateless</filename> in the stateless approach), execute the <emphasis role="bold">ant deploy-purchasing</emphasis>.
-			</listitem>
-			<listitem>
-		Go to the <filename>$Overlord/samples/client</filename> folder and execute <emphasis role="bold">ant runPurchasingClient</emphasis> (or <emphasis role="bold"> ant runStatelessPurchasingClient</emphasis> in stateless approach.), which will send a 'BuyRequest' message to the Store, which will then perform the credit check before returning a response to the client.
-			</listitem>
-		</orderedlist>
-
-		<para>
-To see a different response from the client, change the <emphasis>isCreditValid</emphasis> method on the <emphasis>CreditAgencyPurchase</emphasis> class to return <emphasis>false</emphasis>, within the <filename>common/creditAgency</filename> ESB service implementation, and then re-deploy the Credit Agency service. Then when the client is re-run, a 'BuyFailed' message will be returned.
-		</para>
-		
-		<tip>
-		  <para>You can undeploy the corresponding esb artifact by through command <command>ant undeploy-purchasing</command> in the <filename>$Overlord/samples/stateful</filename> folder or <filename>$Overlord/samples/stateless</filename> folder respectively.</para>
-		</tip>
-
-	</section>
-
-  </section>
-
-  <section>
-	<title>Brokerage Example</title>
-    
-    <section>
-     <title>Overview</title>
-	
-	<para>
-The brokerage example describes the interactions between a Customer, Broker, Supplier and Credit Agency. The flow for this example would be:
-	</para>
-
-	<itemizedlist>
-		<listitem>
-Customer sends an 'enquiry' request to Broker
-		</listitem>
-		<listitem>
-Broker sends the request to one or more Suppliers concurrently
-		</listitem>
-		<listitem>
-When all of the quote responses have been received, or a timeout expires, the available information is returned to the Customer
-		</listitem>
-		<listitem>
-Customer decides whether to:
-			<itemizedlist>
-				<listitem>
-	Cancel the transaction, or
-				</listitem>
-				<listitem>
-	Send a 'buy' request to the Broker
-				</listitem>
-			</itemizedlist>
-		</listitem>
-		<listitem>
-If a 'buy' request is received by the Broker, it will send a 'credit check' request to the Credit Agency
-		</listitem>
-		<listitem>
-If the Credit Agency returns a successful message, then the Broker sends a 'buy' request to the Supplier selected by the Customer (in the 'buy' request), followed by a confirmation back to the Customer
-		</listitem>
-		<listitem>
-If the Credit Agency returns a failed message, then the Broker will inform the Customer
-		</listitem>
-	</itemizedlist>
-
-	<para>
-To check conformance, we need to refer to the model and service implementation projects in the Eclipse environment.
-The <filename>brokerage-models</filename> project contains the CDL used to perform conformance checking on the <filename>src/main/resources/META-INF/jboss-esb.xml</filename> files within the other brokerage projects. A full explanation of the conversation aware ESB actions can be found in the <emphasis>Conversational Aware ESB</emphasis> section of the <emphasis>User Guide</emphasis> in the <filename>docs</filename> folder.
-	</para>
-	<para>
-To provide a simple demonstration of the conformance checking:
-	</para>
-	<orderedlist>
-		<listitem>
-Double click on <filename>brokerage-broker[-stateful/less]/src/main/resources/META-INF/jboss-esb.xml</filename>
-		</listitem>
-		<listitem>
-Scroll down to the second action, within the first service. This represents a <emphasis>ReceiveMessageAction</emphasis> and has a property defining the message type to be received.
-		</listitem>
-		<listitem>
-Edit the 'messageType' property value, e.g. by adding an 'X' to the end of the value.
-		</listitem>
-		<listitem>
-Then save the file. This should result in an error being generated, complaining about a type mismatch.
-		</listitem>
-	</orderedlist>
-	<para>
-The information regarding the expected message type is obtained from the choreography description in the <filename>brokerage-models</filename> project. To identify the precise interaction within the choreography that this error relates to, select the context menu associated with the error and choose the Quick Fix menu item. This will display a dialog with a list of fixes, select the <emphasis>Show referenced description</emphasis> option and press OK. This will cause the relevant interaction within the choreography description to be displayed.
-	</para>
-    </section>
-    
-	<section>
-		<title>Running the Example</title>
-		<para>
-		 This example has two versions, stateful and stateless. in the sample folder, you will find the samples were grouped in stateful and stateless folder.
-		 one is the sateful broker example (this is the example that we had since M1 release), the other is stateless broker example that is introduced in the M2 release.		 
-		</para>
-		<orderedlist>
-			<listitem>
-			First step is to install the ESB services (Presumely the JBoss ESB server started already) 
-			In a command window, Go to the <filename>$Overlord/samples/stateful</filename> folder (or <filename>$Overlord/samples/stateless</filename> in the stateless approach), execute <emphasis role="bold">ant deploy-broker</emphasis>
-			</listitem>
-			<listitem>
-			Go to the <filename>$Overlord/samples/client</filename> folder and execute <emphasis role="bold">ant runBrokerageClient</emphasis> (or <emphasis role="bold"> ant runStatelessBrokerageClient</emphasis> in stateless approach), which will initially send an 'enquiry' message to the Broker, which will communicate with the set of Suppliers to obtain the best quote. The client will then send a 'buy' request, which will result in the Broker performing a credit check before returning a response to the client.
-			</listitem>
-		</orderedlist>
-		
-		<tip>
-		  <para>You can undeploy the corresponding esb artifact by through command <command>ant undeploy-broker</command> in $Overlord/samples/stateful or $Overlord/samples/stateless respectively.</para>
-		</tip>
-	</section>
-
-  </section>
-
-</chapter>

Deleted: runtime/trunk/docs/samplesguide/src/main/module/cdlvalidator.xml
===================================================================
--- runtime/trunk/docs/samplesguide/src/main/module/cdlvalidator.xml	2009-11-24 23:47:13 UTC (rev 91)
+++ runtime/trunk/docs/samplesguide/src/main/module/cdlvalidator.xml	2009-11-25 22:14:32 UTC (rev 92)
@@ -1,132 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
-]>
-<chapter id="cdlvalidator">
-  <title>CDL Validator</title>
-
-  <section>
-	<title>Trailblazer Example</title>
-
-	<para>
-This example can be found in the <filename>trailblazer</filename> folder, which contains an enhanced version of the trailblazer example found in the JBossESB distribution. See the TrailBlazer Guide in the JBossESB distribution (<filename>$JBossESB/docs/samples/TBGuide.pdf</filename>) for more information about the example. The main changes are the introduction of a File Based Bank, and modifications to the message structures to enable a consistent conversation id to be carried with the messages.
-	</para>
-
-<note>
-	<para>
-The choreography description for the Trailblazer example can be found in the <emphasis>trailblazer-models</emphasis> project in the Eclipse environment. If the project has not yet been imported, then please refer to the instructions in the <emphasis>Getting Started Guide</emphasis>.
-	</para>
-	<para>
-You can open the choreography for the trailblazer (trailblazer.cdm) and also a scenario representing a valid transaction associated with the choreography (LoanRequest.scn). In the choreography description editor, view the "Choreography Flows" tab to see the structure of the process.
-	</para>
-	<para>
-To simulate the scenario against the choreography, to ensure that the choreography correctly caters for the valid business scenario, the user should press the green 'play' button in the toolbar, associated with the Scenario Editor.
-	</para>
-</note>
-
-
-  <orderedlist>
-	  <listitem>
-Update the <filename>$JBossAS/server/default/deploy/jbossesb.sar/jbossesb-properties.xml</filename> file, in the section entitled "transports" and specify all of the SMTP mail server settings for your environment.
-	</listitem>
-	<listitem>
-Update the <filename>trailblazer/trailblazer.properties</filename>
-	<para>
-Update the <property>file.bank.monitored.directory</property> and <property>file.output.directory</property> properties. These are folders used by the File Based Bank, and are set to <filename>/tmp/input</filename> and <filename>/tmp/output</filename> by default. If the selected folders do not exist, then please ensure they are created prior to running the example.
-	</para>
-	</listitem>
-	<listitem>
-Update the <filename>trailblazer/esb/conf/jboss-esb.xml</filename>
-	<para>
-There is a <emphasis>fs-provider</emphasis> block, update the <property>directory</property> attribute value to be the same as the <property>file.output.directory</property> value in <filename>trailblazer.properties</filename> file.
-	</para>
-	</listitem>
-	<listitem>
-Start the JBossAS server
-	</listitem>
-	<listitem>
-From the <filename>trailblazer</filename> folder, execute the command to start the ESB: <emphasis role="bold">ant deploy</emphasis>
-	<para>
-this should deploy the ESB and WAR files to your JBoss AS <filename>server/default</filename>.
-	</para>
-	</listitem>
-	<listitem>
-From the <filename>trailblazer/banks</filename> folder, execute the command to start the JMS Bank service: <emphasis role="bold">ant runJMSBank</emphasis>.
-	</listitem>
-	<listitem>
-From the <filename>trailblazer/banks</filename> folder, execute the command to start the JMS Bank service: <emphasis role="bold">ant runFileBank</emphasis>.
-	</listitem>
-	<listitem>
-		<para>
-In the Eclipse environment, select the popup menu associated with the <filename>trailblazer.cdm</filename> file, and choose the <emphasis>Choreography->Monitor</emphasis> menu item.
-		</para>
-
-		<imageobject>
-			<imagedata fileref="images/MonitorMenu.jpg" align="center" width="2in" />
-		</imageobject>
-
-		<para>
-Wait for the monitor window to start, and indicate that the choreography is being monitored, shown in the status line at the bottom of the window.
-		</para>
-
-		<imageobject>
-			<imagedata fileref="images/ChoreoMonReady.jpg" align="center" width="4in" />
-		</imageobject>
-
-	</listitem>
-	<listitem>
-		<para>
-Start a browser and enter the URL: <ulink url="http://localhost:8080/trailblazer">localhost:8080/trailblazer</ulink>.
-		</para>
-
-		<imageobject>
-			<imagedata fileref="images/TrailblazerWebPage.jpg" align="center" width="4in" />
-		</imageobject>
-
-	</listitem>
-	<listitem>
-Now you can submit quotes, You will see either a loan request rejected (single email) because the score is less than 4, or two emails (one from JMS bank and one from FileBased bank) with valid quotes. When entering subsequent quotes, make sure that the quote reference is updated, so that each session has a unique id.
-	</listitem>
-     </orderedlist>
-	<para>
-To demonstrate what occurs when the implementation deviates from the expected behaviour as defined in the choreography description, try the following steps:
-	</para>
-    <orderedlist>
-	<listitem>
-		Run the ant task <emphasis role="bold">ant deploy-error-client</emphasis> to redeploy the trailblaizer example.
-	</listitem>	
-	<listitem>
-		Run the commands from step 6 above.
-	</listitem>
-	</orderedlist>
-	<para>
-		The above steps show how changing the service implementation without updating a choreography can result in behavioural validation errors being detected. 	
-	</para>
-	<tip>
-	   <title>What is changed when we run ant deploy-error-client</title>
-		<para>
-			Compared to command of <emphasis role="bold">ant deploy</emphasis>, basically, we have just updated the following code in
-			<emphasis role="bold">$Overlord/samples/trailblazer/client/src/org/jboss/soa/esb/samples/trailblazer/loanbroker/LoanBroker.java</emphasis> file.
-		</para>
-		<para>
-		In the following code within the <emphasis role="bold">processLoanRequest</emphasis> method, we've changed the "4" to "7"
-		
-<programlisting>
-        //step 2 - check if score is acceptable        
-        if (score >= 4) {
-</programlisting>
-		</para>
-	</tip>  
-	
-	<para>
-	Issue further loan requests, remembering to change the quote reference each time, until a Credit Check result of between 4 and 6 inclusive occurs, which will result in an out of sequence message being reported (in red) to the Choreography Monitor
-
-	<note>
-		<para>
-		It is currently a requirement that the choreography used within the Choreography Monitor is the same as the description used to locally monitor the services (i.e. within the overlord-cdl-validator.esb/models directory).
-		</para>
-	</note>	
-	</para>
-
-  </section>
-	
-</chapter>

Copied: runtime/trunk/docs/samplesguide/src/main/module/convawareesb.xml (from rev 91, runtime/trunk/docs/samplesguide/src/main/module/cdlconformance.xml)
===================================================================
--- runtime/trunk/docs/samplesguide/src/main/module/convawareesb.xml	                        (rev 0)
+++ runtime/trunk/docs/samplesguide/src/main/module/convawareesb.xml	2009-11-25 22:14:32 UTC (rev 92)
@@ -0,0 +1,192 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
+]>
+<chapter id="convawareesb">
+  <title>"Conversation Aware" ESB Services</title>
+
+  <para>
+There are two examples to demonstrate the conversation aware ESB actions(for both stateful and stateless), and the conformance checking against a choreography.
+  </para>
+  <para> 
+These are <filename>purchasing</filename>, a simple customer/supplier example with two associated Eclipse projects (<filename>purchasing-store-stateful/less</filename> and <filename>purchasing-models</filename>), and <filename>brokerage</filename> which extends the purchasing example through the introduction of a broker that mediates between potentially multiple suppliers to find the best deal, defined within three Eclipse projects (<filename>brokerage-broker-stateful/less</filename>, <filename>brokerage-supplier-stateful/less</filename> and <filename>brokerage-models</filename>).
+  </para>
+  <para>
+These examples make use of a common <emphasis>Credit Agency</emphasis> service, defined within the <filename>common-creditAgency-stateful/less</filename> Eclipse project, and are executed through the use of client applications defined in the <filename>${OverlordCDL}/samples/client</filename> folder.
+  </para>
+
+   <warning>
+	   At the moment, the conversation aware ESB runtime doesn't support the hot-deploy. That means if you update the business pojo class, such as <emphasis role="bold">$creditAgency/src/main/com/acme/services/creditAgency/CreditAgencyPurchase.java</emphasis> file,
+	   You need to re-deploy it, and then <emphasis role="bold">restart the server </emphasis> to cause it to take effect. This issue has been tracked under <ulink url="https://jira.jboss.org/jira/browse/SOAG-72">https://jira.jboss.org/jira/browse/SOAG-72</ulink>. Will be fixed in the next release.
+   </warning>	
+	
+  <section>
+	<title>Purchasing Example</title>
+    <section>
+     <title>Overview</title>
+	<para>
+The purchasing example describes the interactions between a Buyer, Store and Credit Agency. The flow for this example would be:
+	</para>
+	<itemizedlist>
+		<listitem>
+Buyer send a 'buy' request to Store
+		</listitem>
+		<listitem>
+Store send a 'credit check' request to the Credit Agency.
+		</listitem>
+		<listitem>
+If the Credit Agency returns a successful message, then the Store will send a 'BuyConfirmed' to user.
+		</listitem>
+		<listitem>
+If the Credit Agency returns a failed message, then the Store will send a 'BuyFailed' to user.
+		</listitem>
+	</itemizedlist>
+
+	<para>
+To check conformance, we need to refer to the model and service implementation projects in the Eclipse environment.
+The <filename>purchasing-models</filename> project contains the CDL used to perform conformance checking on the <filename>src/main/resources/META-INF/jboss-esb.xml</filename> files within the other projects. A full explanation of the conversation aware ESB actions can be found in the <emphasis>Conversational Aware ESB</emphasis> section of the <emphasis>User Guide</emphasis> in the <filename>docs</filename> folder.
+	</para>
+	<para>
+To provide a simple demonstration of the conformance checking:
+	</para>
+	<orderedlist>
+		<listitem>
+Double click on <filename>purchasing-store[-stateful/less]/src/main/resources/META-INF/jboss-esb.xml</filename>
+		</listitem>
+		<listitem>
+Scroll down to the second action, within the first service. This represents a <emphasis>ReceiveMessageAction</emphasis> and has a property defining the message type to be received.
+		</listitem>
+		<listitem>
+Edit the 'messageType' property value, e.g. by adding an 'X' to the end of the value.
+		</listitem>
+		<listitem>
+Then save the file. This should result in an error being generated, complaining about a type mismatch.
+		</listitem>
+	</orderedlist>
+	<para>
+The information regarding the expected message type is obtained from the choreography description in the <filename>purchasing-models</filename> project. To identify the precise interaction within the choreography that this error relates to, select the context menu associated with the error and choose the Quick Fix menu item. This will display a dialog with a list of fixes, select the <emphasis>Show referenced description</emphasis> option and press OK. This will cause the relevant interaction within the choreography description to be displayed.
+	</para>
+	<para>
+Another Quick Fix option associated with this error is <emphasis>Update from Referenced Description</emphasis>. By selecting this option, you will notice that the message type is changed back to the value without the 'X'.
+	</para>
+    </section>
+    
+	<section>
+		<title>Running the Example</title>
+		<para>
+		 This example has two versions, stateful and stateless. in the sample folder, you will find the samples were grouped in stateful and stateless folder.
+		 One is the stateful purchasing example (this is the example that we had since M1 release),the other is stateless purchasing example that is introduced in the M2 release.		 
+		</para>
+		<orderedlist>
+			<listitem>
+		First step is to install the ESB services. (Presumely the JBoss ESB server started already)
+		In a command window, Go to the the <filename>$Overlord/samples/stateful</filename> folder (or <filename>$Overlord/sample/stateless</filename> in the stateless approach), execute the <emphasis role="bold">ant deploy-purchasing</emphasis>.
+			</listitem>
+			<listitem>
+		Go to the <filename>$Overlord/samples/client</filename> folder and execute <emphasis role="bold">ant runPurchasingClient</emphasis> (or <emphasis role="bold"> ant runStatelessPurchasingClient</emphasis> in stateless approach.), which will send a 'BuyRequest' message to the Store, which will then perform the credit check before returning a response to the client.
+			</listitem>
+		</orderedlist>
+
+		<para>
+To see a different response from the client, change the <emphasis>isCreditValid</emphasis> method on the <emphasis>CreditAgencyPurchase</emphasis> class to return <emphasis>false</emphasis>, within the <filename>common/creditAgency</filename> ESB service implementation, and then re-deploy the Credit Agency service. Then when the client is re-run, a 'BuyFailed' message will be returned.
+		</para>
+		
+		<tip>
+		  <para>You can undeploy the corresponding esb artifact by through command <command>ant undeploy-purchasing</command> in the <filename>$Overlord/samples/stateful</filename> folder or <filename>$Overlord/samples/stateless</filename> folder respectively.</para>
+		</tip>
+
+	</section>
+
+  </section>
+
+  <section>
+	<title>Brokerage Example</title>
+    
+    <section>
+     <title>Overview</title>
+	
+	<para>
+The brokerage example describes the interactions between a Customer, Broker, Supplier and Credit Agency. The flow for this example would be:
+	</para>
+
+	<itemizedlist>
+		<listitem>
+Customer sends an 'enquiry' request to Broker
+		</listitem>
+		<listitem>
+Broker sends the request to one or more Suppliers concurrently
+		</listitem>
+		<listitem>
+When all of the quote responses have been received, or a timeout expires, the available information is returned to the Customer
+		</listitem>
+		<listitem>
+Customer decides whether to:
+			<itemizedlist>
+				<listitem>
+	Cancel the transaction, or
+				</listitem>
+				<listitem>
+	Send a 'buy' request to the Broker
+				</listitem>
+			</itemizedlist>
+		</listitem>
+		<listitem>
+If a 'buy' request is received by the Broker, it will send a 'credit check' request to the Credit Agency
+		</listitem>
+		<listitem>
+If the Credit Agency returns a successful message, then the Broker sends a 'buy' request to the Supplier selected by the Customer (in the 'buy' request), followed by a confirmation back to the Customer
+		</listitem>
+		<listitem>
+If the Credit Agency returns a failed message, then the Broker will inform the Customer
+		</listitem>
+	</itemizedlist>
+
+	<para>
+To check conformance, we need to refer to the model and service implementation projects in the Eclipse environment.
+The <filename>brokerage-models</filename> project contains the CDL used to perform conformance checking on the <filename>src/main/resources/META-INF/jboss-esb.xml</filename> files within the other brokerage projects. A full explanation of the conversation aware ESB actions can be found in the <emphasis>Conversational Aware ESB</emphasis> section of the <emphasis>User Guide</emphasis> in the <filename>docs</filename> folder.
+	</para>
+	<para>
+To provide a simple demonstration of the conformance checking:
+	</para>
+	<orderedlist>
+		<listitem>
+Double click on <filename>brokerage-broker[-stateful/less]/src/main/resources/META-INF/jboss-esb.xml</filename>
+		</listitem>
+		<listitem>
+Scroll down to the second action, within the first service. This represents a <emphasis>ReceiveMessageAction</emphasis> and has a property defining the message type to be received.
+		</listitem>
+		<listitem>
+Edit the 'messageType' property value, e.g. by adding an 'X' to the end of the value.
+		</listitem>
+		<listitem>
+Then save the file. This should result in an error being generated, complaining about a type mismatch.
+		</listitem>
+	</orderedlist>
+	<para>
+The information regarding the expected message type is obtained from the choreography description in the <filename>brokerage-models</filename> project. To identify the precise interaction within the choreography that this error relates to, select the context menu associated with the error and choose the Quick Fix menu item. This will display a dialog with a list of fixes, select the <emphasis>Show referenced description</emphasis> option and press OK. This will cause the relevant interaction within the choreography description to be displayed.
+	</para>
+    </section>
+    
+	<section>
+		<title>Running the Example</title>
+		<para>
+		 This example has two versions, stateful and stateless. in the sample folder, you will find the samples were grouped in stateful and stateless folder.
+		 one is the sateful broker example (this is the example that we had since M1 release), the other is stateless broker example that is introduced in the M2 release.		 
+		</para>
+		<orderedlist>
+			<listitem>
+			First step is to install the ESB services (Presumely the JBoss ESB server started already) 
+			In a command window, Go to the <filename>$Overlord/samples/stateful</filename> folder (or <filename>$Overlord/samples/stateless</filename> in the stateless approach), execute <emphasis role="bold">ant deploy-broker</emphasis>
+			</listitem>
+			<listitem>
+			Go to the <filename>$Overlord/samples/client</filename> folder and execute <emphasis role="bold">ant runBrokerageClient</emphasis> (or <emphasis role="bold"> ant runStatelessBrokerageClient</emphasis> in stateless approach), which will initially send an 'enquiry' message to the Broker, which will communicate with the set of Suppliers to obtain the best quote. The client will then send a 'buy' request, which will result in the Broker performing a credit check before returning a response to the client.
+			</listitem>
+		</orderedlist>
+		
+		<tip>
+		  <para>You can undeploy the corresponding esb artifact by through command <command>ant undeploy-broker</command> in $Overlord/samples/stateful or $Overlord/samples/stateless respectively.</para>
+		</tip>
+	</section>
+
+  </section>
+
+</chapter>

Modified: runtime/trunk/pom.xml
===================================================================
--- runtime/trunk/pom.xml	2009-11-24 23:47:13 UTC (rev 91)
+++ runtime/trunk/pom.xml	2009-11-25 22:14:32 UTC (rev 92)
@@ -6,7 +6,7 @@
 	<artifactId>runtime</artifactId>
 	<version>1.0-SNAPSHOT</version>
 	<packaging>pom</packaging>
-	<name>Savara Runtime</name>
+	<name>Savara::Runtime</name>
 	<url>http://www.jboss.org/savara</url>
 	<description>
 		The JBoss SAVARA Runtime. 

Modified: runtime/trunk/samples/jbossesb/brokerage/broker/pom.xml
===================================================================
--- runtime/trunk/samples/jbossesb/brokerage/broker/pom.xml	2009-11-24 23:47:13 UTC (rev 91)
+++ runtime/trunk/samples/jbossesb/brokerage/broker/pom.xml	2009-11-25 22:14:32 UTC (rev 92)
@@ -5,7 +5,7 @@
 	<groupId>org.jboss.savara.runtime.samples</groupId>
 	<artifactId>samples-broker</artifactId>
 	<packaging>jar</packaging>
-	<name>Savara::Samples::Broker</name>
+	<name>Savara::Runtime::Samples::Broker</name>
 	
 	<parent>
 		<groupId>org.jboss.savara.runtime</groupId>

Modified: tools/eclipse/trunk/docs/userguide/src/main/master.xml
===================================================================
--- tools/eclipse/trunk/docs/userguide/src/main/master.xml	2009-11-24 23:47:13 UTC (rev 91)
+++ tools/eclipse/trunk/docs/userguide/src/main/master.xml	2009-11-25 22:14:32 UTC (rev 92)
@@ -12,9 +12,8 @@
   
   <toc/>
   <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="module/overview.xml"/>
-  <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="module/bpel-governance.xml"/>
-  <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="module/cdlconformance.xml"/>
+  <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="module/bpel.xml"/>
   <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="module/conversation-aware-esb.xml"/>
-  <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="module/conversation-validation-with-cdl.xml"/>
+  <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="module/conversation-validation.xml"/>
 
 </book>

Deleted: tools/eclipse/trunk/docs/userguide/src/main/module/bpel-governance.xml
===================================================================
--- tools/eclipse/trunk/docs/userguide/src/main/module/bpel-governance.xml	2009-11-24 23:47:13 UTC (rev 91)
+++ tools/eclipse/trunk/docs/userguide/src/main/module/bpel-governance.xml	2009-11-25 22:14:32 UTC (rev 92)
@@ -1,71 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
-]>
-<chapter id="bpelgovernance">
-	<title>BPEL Governance</title>
-
-	<section>
-		<title>Overview</title>
-		<para>
-This section will describe governance features related to WS-BPEL. This initial release provides basic support for generating BPEL processes from a choreography description. Subsequent releases will also provide conformance checking, to ensure that changes to a BPEL process are validated to ensure the process remains conformant with the choreography.
-		</para>
-	</section>
-
-	<section>
-      	<title>Generating a BPEL process from CDL</title>
-		<section>
-			<title>Overview</title>
-			<para>
-This section explains how to generate a template BPEL process from a pi4soa choreography description (.cdm) file.
-			</para>
-		</section>
-		<section>
-			<title>Generating the BPEL Process</title>
-			<para>
-When the choreography description has been completed, and has no errors, the user should select the "Overlord->Generate->WS-BPEL" menu item from the popup menu associated with the choreography description (.cdm) file.
-			</para>
-
-		<imageobject>
-			<imagedata fileref="images/genbpel1.png" width="4in" />
-		</imageobject>
-
-			<para>
-When the dialog window is displayed, it will contain the list of services that can be generated, along with the project names that will be created. The user can unselect the services they do not wish to generate (also using the 'Check All' or 'Clear All' buttons).
-			</para>
-
-		<imageobject>
-			<imagedata fileref="images/genbpel2.png" />
-		</imageobject>
-
-			<para>
-The user can also select their preferred build system, which will create the relevant build structure.
-		</para>
-		<para>
-If there is a problem with the name of the project select, such as invalid characters used in the name, or the project name already exists, then it will be displayed in red.
-			</para>
-
-		<para>
-Once the BPEL is generated, it can be viewed using the Eclipse BPEL editor, e.g.
-		</para>
-
-		<imageobject>
-			<imagedata fileref="images/genbpel3.png" />
-		</imageobject>
-
-		</section>
-
-		<section>
-			<title>Limitations with the current CDL to BPEL mapping</title>
-
-			<para>
-This initial version of the BPEL generation is primarily targeted at generating the interactions and grouping constructs. These are the important components that will be required when doing conformance checking as part of the next milestone.
-			</para>
-
-			<para>
-This means that assignments and conditional expressions are not currently generated. The 'when' construct in CDL (also known as the blocking workunit) is also not currently handled. This may possible be implemented using flow links.
-			</para>
-		</section>
-	</section>
-
-</chapter>
-

Copied: tools/eclipse/trunk/docs/userguide/src/main/module/bpel.xml (from rev 91, tools/eclipse/trunk/docs/userguide/src/main/module/bpel-governance.xml)
===================================================================
--- tools/eclipse/trunk/docs/userguide/src/main/module/bpel.xml	                        (rev 0)
+++ tools/eclipse/trunk/docs/userguide/src/main/module/bpel.xml	2009-11-25 22:14:32 UTC (rev 92)
@@ -0,0 +1,87 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
+]>
+<chapter id="bpel">
+	<title>BPEL</title>
+
+	<section>
+		<title>Overview</title>
+		<para>
+This section will describe generation and conformance checking features related to WS-BPEL.
+		</para>
+		
+		<para>
+This initial release provides basic support for generating BPEL processes from a choreography 
+description. Subsequent releases will also provide conformance checking, to ensure that changes 
+to a BPEL process are validated to ensure the process remains conformant with the choreography.
+		</para>
+	</section>
+
+	<section>
+      	<title>Generating a BPEL process</title>
+		<section>
+			<title>Overview</title>
+			<para>
+This section explains how to generate a template BPEL process from architectural and design
+artifacts.
+			</para>
+		</section>
+		<section>
+			<title>Generating the BPEL Process from a Choreography Description</title>
+			<para>
+When the choreography description has been completed, and has no errors, the user should select
+the "SAVARA->Generate->WS-BPEL" menu item from the popup menu associated with the choreography
+description (.cdm) file.
+			</para>
+
+		<imageobject>
+			<imagedata fileref="images/genbpel1.png" width="4in" />
+		</imageobject>
+
+			<para>
+When the dialog window is displayed, it will contain the list of services that can be generated,
+along with the project names that will be created. The user can unselect the services they do not 
+wish to generate (also using the 'Check All' or 'Clear All' buttons).
+			</para>
+
+		<imageobject>
+			<imagedata fileref="images/genbpel2.png" />
+		</imageobject>
+
+			<para>
+The user can also select their preferred build system, which will create the relevant build structure.
+		</para>
+		<para>
+If there is a problem with the name of the project select, such as invalid characters used in the name, 
+or the project name already exists, then it will be displayed in red.
+			</para>
+
+		<para>
+Once the BPEL is generated, it can be viewed using the Eclipse BPEL editor, e.g.
+		</para>
+
+		<imageobject>
+			<imagedata fileref="images/genbpel3.png" />
+		</imageobject>
+
+		</section>
+
+		<section>
+			<title>Limitations with the current CDL to BPEL mapping</title>
+
+			<para>
+This initial version of the BPEL generation is primarily targeted at generating the interactions 
+and grouping constructs. These are the important components that will be required when doing 
+conformance checking as part of the next milestone.
+			</para>
+
+			<para>
+This means that assignments and conditional expressions are not currently generated. The 'when' 
+construct in CDL (also known as the blocking workunit) is also not currently handled. This may possible 
+be implemented using flow links.
+			</para>
+		</section>
+	</section>
+
+</chapter>
+

Deleted: tools/eclipse/trunk/docs/userguide/src/main/module/cdlconformance.xml
===================================================================
--- tools/eclipse/trunk/docs/userguide/src/main/module/cdlconformance.xml	2009-11-24 23:47:13 UTC (rev 91)
+++ tools/eclipse/trunk/docs/userguide/src/main/module/cdlconformance.xml	2009-11-25 22:14:32 UTC (rev 92)
@@ -1,192 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
-]>
-<chapter id="cdlconformance">
-  <title>CDL Conformance</title>
-
-  <para>
-There are two examples to demonstrate the conversation aware ESB actions(for both stateful and stateless), and the conformance checking against a choreography.
-  </para>
-  <para> 
-These are <filename>purchasing</filename>, a simple customer/supplier example with two associated Eclipse projects (<filename>purchasing-store-stateful/less</filename> and <filename>purchasing-models</filename>), and <filename>brokerage</filename> which extends the purchasing example through the introduction of a broker that mediates between potentially multiple suppliers to find the best deal, defined within three Eclipse projects (<filename>brokerage-broker-stateful/less</filename>, <filename>brokerage-supplier-stateful/less</filename> and <filename>brokerage-models</filename>).
-  </para>
-  <para>
-These examples make use of a common <emphasis>Credit Agency</emphasis> service, defined within the <filename>common-creditAgency-stateful/less</filename> Eclipse project, and are executed through the use of client applications defined in the <filename>${OverlordCDL}/samples/client</filename> folder.
-  </para>
-
-   <warning>
-	   At the moment, the conversation aware ESB runtime doesn't support the hot-deploy. That means if you update the business pojo class, such as <emphasis role="bold">$creditAgency/src/main/com/acme/services/creditAgency/CreditAgencyPurchase.java</emphasis> file,
-	   You need to re-deploy it, and then <emphasis role="bold">restart the server </emphasis> to cause it to take effect. This issue has been tracked under <ulink url="https://jira.jboss.org/jira/browse/SOAG-72">https://jira.jboss.org/jira/browse/SOAG-72</ulink>. Will be fixed in the next release.
-   </warning>	
-	
-  <section>
-	<title>Purchasing Example</title>
-    <section>
-     <title>Overview</title>
-	<para>
-The purchasing example describes the interactions between a Buyer, Store and Credit Agency. The flow for this example would be:
-	</para>
-	<itemizedlist>
-		<listitem>
-Buyer send a 'buy' request to Store
-		</listitem>
-		<listitem>
-Store send a 'credit check' request to the Credit Agency.
-		</listitem>
-		<listitem>
-If the Credit Agency returns a successful message, then the Store will send a 'BuyConfirmed' to user.
-		</listitem>
-		<listitem>
-If the Credit Agency returns a failed message, then the Store will send a 'BuyFailed' to user.
-		</listitem>
-	</itemizedlist>
-
-	<para>
-To check conformance, we need to refer to the model and service implementation projects in the Eclipse environment.
-The <filename>purchasing-models</filename> project contains the CDL used to perform conformance checking on the <filename>src/main/resources/META-INF/jboss-esb.xml</filename> files within the other projects. A full explanation of the conversation aware ESB actions can be found in the <emphasis>Conversational Aware ESB</emphasis> section of the <emphasis>User Guide</emphasis> in the <filename>docs</filename> folder.
-	</para>
-	<para>
-To provide a simple demonstration of the conformance checking:
-	</para>
-	<orderedlist>
-		<listitem>
-Double click on <filename>purchasing-store[-stateful/less]/src/main/resources/META-INF/jboss-esb.xml</filename>
-		</listitem>
-		<listitem>
-Scroll down to the second action, within the first service. This represents a <emphasis>ReceiveMessageAction</emphasis> and has a property defining the message type to be received.
-		</listitem>
-		<listitem>
-Edit the 'messageType' property value, e.g. by adding an 'X' to the end of the value.
-		</listitem>
-		<listitem>
-Then save the file. This should result in an error being generated, complaining about a type mismatch.
-		</listitem>
-	</orderedlist>
-	<para>
-The information regarding the expected message type is obtained from the choreography description in the <filename>purchasing-models</filename> project. To identify the precise interaction within the choreography that this error relates to, select the context menu associated with the error and choose the Quick Fix menu item. This will display a dialog with a list of fixes, select the <emphasis>Show referenced description</emphasis> option and press OK. This will cause the relevant interaction within the choreography description to be displayed.
-	</para>
-	<para>
-Another Quick Fix option associated with this error is <emphasis>Update from Referenced Description</emphasis>. By selecting this option, you will notice that the message type is changed back to the value without the 'X'.
-	</para>
-    </section>
-    
-	<section>
-		<title>Running the Example</title>
-		<para>
-		 This example has two versions, stateful and stateless. in the sample folder, you will find the samples were grouped in stateful and stateless folder.
-		 One is the stateful purchasing example (this is the example that we had since M1 release),the other is stateless purchasing example that is introduced in the M2 release.		 
-		</para>
-		<orderedlist>
-			<listitem>
-		First step is to install the ESB services. (Presumely the JBoss ESB server started already)
-		In a command window, Go to the the <filename>$Overlord/samples/stateful</filename> folder (or <filename>$Overlord/sample/stateless</filename> in the stateless approach), execute the <emphasis role="bold">ant deploy-purchasing</emphasis>.
-			</listitem>
-			<listitem>
-		Go to the <filename>$Overlord/samples/client</filename> folder and execute <emphasis role="bold">ant runPurchasingClient</emphasis> (or <emphasis role="bold"> ant runStatelessPurchasingClient</emphasis> in stateless approach.), which will send a 'BuyRequest' message to the Store, which will then perform the credit check before returning a response to the client.
-			</listitem>
-		</orderedlist>
-
-		<para>
-To see a different response from the client, change the <emphasis>isCreditValid</emphasis> method on the <emphasis>CreditAgencyPurchase</emphasis> class to return <emphasis>false</emphasis>, within the <filename>common/creditAgency</filename> ESB service implementation, and then re-deploy the Credit Agency service. Then when the client is re-run, a 'BuyFailed' message will be returned.
-		</para>
-		
-		<tip>
-		  <para>You can undeploy the corresponding esb artifact by through command <command>ant undeploy-purchasing</command> in the <filename>$Overlord/samples/stateful</filename> folder or <filename>$Overlord/samples/stateless</filename> folder respectively.</para>
-		</tip>
-
-	</section>
-
-  </section>
-
-  <section>
-	<title>Brokerage Example</title>
-    
-    <section>
-     <title>Overview</title>
-	
-	<para>
-The brokerage example describes the interactions between a Customer, Broker, Supplier and Credit Agency. The flow for this example would be:
-	</para>
-
-	<itemizedlist>
-		<listitem>
-Customer sends an 'enquiry' request to Broker
-		</listitem>
-		<listitem>
-Broker sends the request to one or more Suppliers concurrently
-		</listitem>
-		<listitem>
-When all of the quote responses have been received, or a timeout expires, the available information is returned to the Customer
-		</listitem>
-		<listitem>
-Customer decides whether to:
-			<itemizedlist>
-				<listitem>
-	Cancel the transaction, or
-				</listitem>
-				<listitem>
-	Send a 'buy' request to the Broker
-				</listitem>
-			</itemizedlist>
-		</listitem>
-		<listitem>
-If a 'buy' request is received by the Broker, it will send a 'credit check' request to the Credit Agency
-		</listitem>
-		<listitem>
-If the Credit Agency returns a successful message, then the Broker sends a 'buy' request to the Supplier selected by the Customer (in the 'buy' request), followed by a confirmation back to the Customer
-		</listitem>
-		<listitem>
-If the Credit Agency returns a failed message, then the Broker will inform the Customer
-		</listitem>
-	</itemizedlist>
-
-	<para>
-To check conformance, we need to refer to the model and service implementation projects in the Eclipse environment.
-The <filename>brokerage-models</filename> project contains the CDL used to perform conformance checking on the <filename>src/main/resources/META-INF/jboss-esb.xml</filename> files within the other brokerage projects. A full explanation of the conversation aware ESB actions can be found in the <emphasis>Conversational Aware ESB</emphasis> section of the <emphasis>User Guide</emphasis> in the <filename>docs</filename> folder.
-	</para>
-	<para>
-To provide a simple demonstration of the conformance checking:
-	</para>
-	<orderedlist>
-		<listitem>
-Double click on <filename>brokerage-broker[-stateful/less]/src/main/resources/META-INF/jboss-esb.xml</filename>
-		</listitem>
-		<listitem>
-Scroll down to the second action, within the first service. This represents a <emphasis>ReceiveMessageAction</emphasis> and has a property defining the message type to be received.
-		</listitem>
-		<listitem>
-Edit the 'messageType' property value, e.g. by adding an 'X' to the end of the value.
-		</listitem>
-		<listitem>
-Then save the file. This should result in an error being generated, complaining about a type mismatch.
-		</listitem>
-	</orderedlist>
-	<para>
-The information regarding the expected message type is obtained from the choreography description in the <filename>brokerage-models</filename> project. To identify the precise interaction within the choreography that this error relates to, select the context menu associated with the error and choose the Quick Fix menu item. This will display a dialog with a list of fixes, select the <emphasis>Show referenced description</emphasis> option and press OK. This will cause the relevant interaction within the choreography description to be displayed.
-	</para>
-    </section>
-    
-	<section>
-		<title>Running the Example</title>
-		<para>
-		 This example has two versions, stateful and stateless. in the sample folder, you will find the samples were grouped in stateful and stateless folder.
-		 one is the sateful broker example (this is the example that we had since M1 release), the other is stateless broker example that is introduced in the M2 release.		 
-		</para>
-		<orderedlist>
-			<listitem>
-			First step is to install the ESB services (Presumely the JBoss ESB server started already) 
-			In a command window, Go to the <filename>$Overlord/samples/stateful</filename> folder (or <filename>$Overlord/samples/stateless</filename> in the stateless approach), execute <emphasis role="bold">ant deploy-broker</emphasis>
-			</listitem>
-			<listitem>
-			Go to the <filename>$Overlord/samples/client</filename> folder and execute <emphasis role="bold">ant runBrokerageClient</emphasis> (or <emphasis role="bold"> ant runStatelessBrokerageClient</emphasis> in stateless approach), which will initially send an 'enquiry' message to the Broker, which will communicate with the set of Suppliers to obtain the best quote. The client will then send a 'buy' request, which will result in the Broker performing a credit check before returning a response to the client.
-			</listitem>
-		</orderedlist>
-		
-		<tip>
-		  <para>You can undeploy the corresponding esb artifact by through command <command>ant undeploy-broker</command> in $Overlord/samples/stateful or $Overlord/samples/stateless respectively.</para>
-		</tip>
-	</section>
-
-  </section>
-
-</chapter>

Deleted: tools/eclipse/trunk/docs/userguide/src/main/module/conversation-validation-with-cdl.xml
===================================================================
--- tools/eclipse/trunk/docs/userguide/src/main/module/conversation-validation-with-cdl.xml	2009-11-24 23:47:13 UTC (rev 91)
+++ tools/eclipse/trunk/docs/userguide/src/main/module/conversation-validation-with-cdl.xml	2009-11-25 22:14:32 UTC (rev 92)
@@ -1,301 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
-]>
-<chapter id="conversationvalidationwithcdl">
-	<title>Conversation Validation with CDL</title>
-	<section>
-      	<title>Overview</title>
-		<para>
-Conversation validation is a form of runtime governance concerned with the dynamic behaviour of a system.
-		</para>
-		<para>
-When coupled with a choreography description model of a system, this means having the ability to ensure that the way a collection of services interact correctly adheres to a description of the business process being enacted.
-		</para>
-		<para>
-This section introduces the choreography description language (CDL) defined by W3C, and the <emphasis>pi4soa</emphasis> open source project which provides an editor for creating choreography descriptions, as well as utilizing these descriptions for runtime validation and execution purposes.
-
-		</para>
-
-	</section>
-
-	<section>
-		<title>Configuration of Conversation Validation</title>
-
-		<para>
-		This section explains how to configure the conversation validation mechanism to validate ESB services
-		against a choreography description. The first sub-section describes how the mechanism is hooked into the
-		JBossESB environment. The following two sub-sections explain two alternate ways that relevant endpoint
-		references can be configured for validation.
-		</para>
-
-		<section>
-			<title>Installing the Conversation Validation Mechanism</title>
-			<para>
-The principle mechanism used for validating conversations within an ESB is through the use of a global filter registered with the <emphasis>jbossesb-properties.xml</emphasis>. This file is located in the <emphasis>$JBossESB/server/default/deploy/jbossesb.sar</emphasis> folder.
-		</para>
-			<informalexample>
-  				<programlisting role="XML" ><![CDATA[
-	<properties name="filters">
-		...
-		<property name="org.jboss.soa.esb.filter.10" 
-				value="org.jboss.soa.overlord.validator.jbossesb.ValidatorFilter"/>
-	</properties>
- 				 ]]></programlisting>
-			</informalexample>
-
-		<para>
-This filter is installed as part of the installation process for the Overlord-CDL distribution.
-		</para>
-		</section>
-
-		<section>
-			<title>Explicit Configuration</title>
-
-		<para>
-The information concerning which destinations will be validated, and to which model/role they relate, can be explicitly
-defined within the <emphasis>validator-config.xml</emphasis> file, contained within the <emphasis>overlord-cdl-validator.esb</emphasis> bundle.
-		</para>
-		<para>
-An example of the contents of this file, that would related to the TrailBlazer example, is:
-		</para>
-			<informalexample>
-  				<programlisting role="XML" ><![CDATA[
-	<validator mode="monitor" replyToTimeout="10000" >
-		<service model="TrailBlazer.cdm" 
-					role="LoanBrokerParticipant" >
-			<output epr="jms:queue/esb-tb-creditAgencyQueue" />
-			<input epr="jms:queue/esb-tb-creditAgencyQueue_reply" />
-			<output epr="jms:queue/esb-tb-jmsBankRequestQueue" />
-			<output epr="jms:queue/esb-tb-fileBankRequestQueue" />
-			<input epr="jms:queue/esb-tb-jmsBankResponseQueue" />
-			<output epr="jms:queue/esb-tb-customerNotifier" />
-			<input epr="jms:queue/esb-tb-fileBankResponseQueue" />
-		</service>
-		<service model="TrailBlazer.cdm" 
-					role="CreditAgencyParticipant" >
-			<input epr="jms:queue/esb-tb-creditAgencyQueue" />
-			<output epr="jms:queue/esb-tb-creditAgencyQueue_reply" />
-		</service>
-		<service model="TrailBlazer.cdm" 
-					role="BankParticipant" >
-			<input epr="jms:queue/esb-tb-jmsBankRequestQueue" />
-			<input epr="jms:queue/esb-tb-fileBankRequestQueue" />
-			<output epr="jms:queue/esb-tb-jmsBankResponseQueue" />
-			<output epr="jms:queue/esb-tb-fileBankResponseQueue" />
-		</service>
-		<service model="TrailBlazer.cdm" 
-					role="NotifierParticipant" >
-			<input epr="jms:queue/esb-tb-customerNotifier" />
-		</service>
-	</validator>
- 				 ]]></programlisting>
-			</informalexample>
-
-			<para>
-The 'validator' element has an optional attribute called 'mode', with the possible values of 'monitor' or 'manage'. If the
-mode is 'monitor' (which is the default), then any messages that result in validation errors being detected will continue to be received or sent, with the errors only be reported for information purposes. If the mode is 'manage', then any erronous messages detected during validation, that conflict with the behaviour as described in the choreography, will be prevented from being received or sent.
-		</para>
-		<note>
-			<para>
-			It is important to note that if 'manage' validation mode is used, then the validation mechanism will be an integral part of the message flow. This may have a slight performance impact on the delivery of messages between services.
-			</para>
-		</note>
-
-		<para>
-The optional 'replyToTimeout' (defined in milliseconds) is used to determine how long a dynamic reply-to destination should be monitored for validation purposes. In some message exchanges, the response destination will not always be known in advance. Therefore the configuration can identify such situations, and monitor the reply-to destination for the response. However, if a response is not delivered in a particular time period, we need to be able to discontinue the validation of the dynamic endpoint. If this did not occur, then over time too many endpoints would be monitored, which may result in out-of-memory problems. The default timeout period is 10 seconds.
-		</para>
-		<para>
-Within the 'validator' element is a list of 'service' elements, one per service being validated. The behaviour of the service being validated is identified by specifying the model (e.g. choreography description file) and the role (e.g. participant type) within the model. Therefore, within the above configuration, the first set of destinations (eprs) are associated with the <emphasis>LoanBrokerParticipant</emphasis> defined within the choreography description model found in the file <filename>TrailBlazer.cdm</filename>, which will be located within the <filename>models</filename> folder contained within the
-<emphasis>overlord-cdl-validator.esb</emphasis> bundle.
-		</para>
-		<para>
-The elements contained within the 'service' element define the <emphasis>input</emphasis> and <emphasis>output</emphasis> eprs (Endpoint References) that are associated with the service. The <emphasis>input</emphasis> eprs are the destinations on which messages will be received and the <emphasis>output</emphasis> eprs are the destinations on which messages will be sent by the service.
-		</para>
-		<para>
-The format of the 'epr' attribute will be specific to the type of transport used for the ESB aware destination. Currently only JMS is supported, and can be identified by the protocol prefix 'jms:'.
-		</para>
-		<para>
-Each 'input' and 'output' element can also define an optional 'dynamicReplyTo' boolean attribute. If defined, it will indicate to the Service Validator that the message on the specified endpoint (epr) will contain a dynamically defined 'reply-to' destination that needs to be monitored for a response.
-		</para>
-
-		</section>
-
-		<section>
-			<title>Defining the Validator Configuration within a Choreography</title>
-
-		<para>
-		The first step to configuring the validator is to associate the endpoint references (EPRs)
-		against the relevant choreography interactions. This is achieved by defining an
-		annotation for each 'exchange details' component (i.e. each request and response/notification).
-		</para>
-
-		<imageobject>
-			<imagedata fileref="images/editvalidatorann.png" width="5in" />
-		</imageobject>
-
-		<para>
-		When the annotation editor is displayed for the relevant 'exchange details' component,
-		the <emphasis>jbossesb</emphasis> annotation should be added. This is achieved by
-		selecting the popup menu associated with the background of the lefthand panel,
-		and selecting the <emphasis>Add Defined Annotation</emphasis> menu item.
-		</para>
-
-		<imageobject>
-			<imagedata fileref="images/editvalidatoranndiag.png" width="5in" />
-		</imageobject>
-
-		<para>
-		When the list of defined annotations is displayed, select the
-		<emphasis>jbossesb</emphasis> annotation.
-		</para>
-
-		<imageobject>
-			<imagedata fileref="images/editvalidatorannselect.png" width="3in" />
-		</imageobject>
-
-		<para>
-		After pressing the <emphasis>Ok</emphasis> button, the annotation editor
-		will configure the righthand panel with the parameters associated with this
-		annotation.
-		</para>
-
-		<imageobject>
-			<imagedata fileref="images/SVJBossESBAnnotation.jpg" width="5in" />
-		</imageobject>
-
-		<para>
-		To specify the EPR for a particular message exchange, enter the EPR into the
-		<emphasis>Destination</emphasis> field. If the exchange is a request, that
-		will result in a response being sent on a dynamically provided "reply-to"
-		destination, then the <emphasis>Dynamic Reply-To</emphasis> checkbox should be selected.
-		</para>
-
-		<para>
-		Once the annotation has been defined, then press the <emphasis>Save</emphasis>
-		button to save the annotation against the interaction's exchange details.
-		</para>
-
-		<para>
-		When all of the relevant 'exchange details' components have been configured with
-		a <emphasis>jbossesb</emphasis> annotation, defining the EPR to be validated,
-		then the choreography description file can be copied into the
-		<filename>overlord-cdl-validator.esb/models</filename> folder. This will cause
-		the validation mechanism to derive the configuration information from the choreography
-		description model, and begin validating the defined destinations against that
-		choreography description model.
-		</para>
-
-		</section>
-
-	</section>
-
-	<section>
-		<title>Monitoring the Choreography Description</title>
-<para>
-Once the JBossESB environment has been configured, to perform service validation of a set of ESB services against a choreography
-description, and the server has been started, then the next step is to launch a tool to view the correlated information from
-the service validators - and determine if the transactions are being correctly executed.
-</para>
-<para>
-Within an Eclipse Java project, that contains the choreography description to be monitored, a configuration file called <emphasis>pi4soa.xml</emphasis> needs to be defined on the project's classpath. This file provides details of the JMS configuration parameters required to subscribe for the information generated by the service validators. The contents of this file is:
-</para>
-			<informalexample>
-  				<programlisting role="XML" ><![CDATA[
-<pi4soa>
-   	<tracker>
-	   	<jndi>
-			<initialContextFactory>org.jnp.interfaces.NamingContextFactory</initialContextFactory>
-	      		<providerURL>jnp://localhost:1099</providerURL>
-	      		<factoryURLPackages>org.jboss.naming:org.jnp.interfaces</factoryURLPackages>
-	    	</jndi>
-	   	<jms>
-	     		<connectionFactory>ConnectionFactory</connectionFactory>
-	     		<connectionFactoryAlternate>ConnectionFactory</connectionFactoryAlternate>
-	     		<destination>topic/tracker</destination>
-	   	</jms>
-	</tracker> 
-</pi4soa>
- 				 ]]></programlisting>
-			</informalexample>
-
-<para>
-The destination defined in this file must match the one configured in the <emphasis>pi4soa.sar/pi4soa.xml</emphasis> file within the server.
-</para>
-		<para>
-The next step is to launch the monitoring tool. This is located on the popup menu, for the choreography description (i.e. .cdm) file, by selecting the Choreography->Monitor menu item. Once the tool has been launched, it will load the choreography description, subscribe to the relevant event destination, and then indicate via a message in the bottom status line that it is ready to monitor.
-		</para>
-
-		<imageobject>
-			<imagedata fileref="images/monitorui.png" width="5in" />
-		</imageobject>
-
-		<para>
-	When the information is received, from the service validators representing the different participants (services), it is correlated to show the global status of the business transaction. The list of correlated interactions is show in reverse time order in the image, so in this example a <emphasis>LoanBroker</emphasis> sends a <emphasis>creditCheck</emphasis> message to a <emphasis>CreditAgency</emphasis>, followed by a <emphasis>creditCheckResult</emphasis> being returned.
-		</para>
-		<para>
-If any <emphasis>out of sequence</emphasis> or other error situations arise, these are displayed in red.
-		</para>
-	</section>
-
-	<section>
-		<title>Configuration for Conversation Recording</title>
-
-		<para>
-		As well as validating the interactions between a set of
-		services, against a pre-defined choreography description,
-		it is also possible to use the <emphasis>Service Validators</emphasis>
-		in a non-validating record mode.
-		</para>
-
-		<para>
-		This will be useful in situations where a choreography
-		description does not currently exist, and we wish to
-		use the stream of business events being sent and received
-		by each identified service (or participant type) to
-		gain an understanding of the current business process.
-		</para>
-
-		<para>
-		An example of this type of configuration, associated
-		with the TrailBlazer example, is:
-		</para>
-			<informalexample>
-  				<programlisting role="XML" ><![CDATA[
-	<validator>
-		<service role="LoanBrokerParticipant" validate="false" >
-			<output epr="jms:queue/esb-tb-creditAgencyQueue" />
-			<input epr="jms:queue/esb-tb-creditAgencyQueue_reply" />
-			<output epr="jms:queue/esb-tb-jmsBankRequestQueue" />
-			<output epr="jms:queue/esb-tb-fileBankRequestQueue" />
-			<input epr="jms:queue/esb-tb-jmsBankResponseQueue" />
-			<output epr="jms:queue/esb-tb-customerNotifier" />
-			<input epr="jms:queue/esb-tb-fileBankResponseQueue" />
-		</service>
-		<service role="CreditAgencyParticipant" validate="false" >
-			<input epr="jms:queue/esb-tb-creditAgencyQueue" />
-			<output epr="jms:queue/esb-tb-creditAgencyQueue_reply" />
-		</service>
-		<service role="BankParticipant" validate="false" >
-			<input epr="jms:queue/esb-tb-jmsBankRequestQueue" />
-			<input epr="jms:queue/esb-tb-fileBankRequestQueue" />
-			<output epr="jms:queue/esb-tb-jmsBankResponseQueue" />
-			<output epr="jms:queue/esb-tb-fileBankResponseQueue" />
-		</service>
-		<service role="NotifierParticipant" validate="false" >
-			<input epr="jms:queue/esb-tb-customerNotifier" />
-		</service>
-	</validator>
- 				 ]]></programlisting>
-			</informalexample>
-
-		<para>
-		To define a <emphasis>Service Validator</emphasis> in record
-		only mode, the <emphasis>model</emphasis> attribute
-		is not specified (because no choreography description exists
-		to be validated against), and the optional <emphasis>validate</emphasis>
-		attribute should be set to <emphasis role="bold">false</emphasis> (by default
-		this attribute is <emphasis role="bold">true</emphasis>).
-		</para>
-	</section>
-
-</chapter>

Copied: tools/eclipse/trunk/docs/userguide/src/main/module/conversation-validation.xml (from rev 91, tools/eclipse/trunk/docs/userguide/src/main/module/conversation-validation-with-cdl.xml)
===================================================================
--- tools/eclipse/trunk/docs/userguide/src/main/module/conversation-validation.xml	                        (rev 0)
+++ tools/eclipse/trunk/docs/userguide/src/main/module/conversation-validation.xml	2009-11-25 22:14:32 UTC (rev 92)
@@ -0,0 +1,301 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
+]>
+<chapter id="conversationvalidationwithcdl">
+	<title>Conversation Validation with CDL</title>
+	<section>
+      	<title>Overview</title>
+		<para>
+Conversation validation is a form of runtime governance concerned with the dynamic behaviour of a system.
+		</para>
+		<para>
+When coupled with a choreography description model of a system, this means having the ability to ensure that the way a collection of services interact correctly adheres to a description of the business process being enacted.
+		</para>
+		<para>
+This section introduces the choreography description language (CDL) defined by W3C, and the <emphasis>pi4soa</emphasis> open source project which provides an editor for creating choreography descriptions, as well as utilizing these descriptions for runtime validation and execution purposes.
+
+		</para>
+
+	</section>
+
+	<section>
+		<title>Configuration of Conversation Validation</title>
+
+		<para>
+		This section explains how to configure the conversation validation mechanism to validate ESB services
+		against a choreography description. The first sub-section describes how the mechanism is hooked into the
+		JBossESB environment. The following two sub-sections explain two alternate ways that relevant endpoint
+		references can be configured for validation.
+		</para>
+
+		<section>
+			<title>Installing the Conversation Validation Mechanism</title>
+			<para>
+The principle mechanism used for validating conversations within an ESB is through the use of a global filter registered with the <emphasis>jbossesb-properties.xml</emphasis>. This file is located in the <emphasis>$JBossESB/server/default/deploy/jbossesb.sar</emphasis> folder.
+		</para>
+			<informalexample>
+  				<programlisting role="XML" ><![CDATA[
+	<properties name="filters">
+		...
+		<property name="org.jboss.soa.esb.filter.10" 
+				value="org.jboss.savara.validator.jbossesb.ValidatorFilter"/>
+	</properties>
+ 				 ]]></programlisting>
+			</informalexample>
+
+		<para>
+This filter is installed as part of the installation process for the SAVARA-Validator distribution.
+		</para>
+		</section>
+
+		<section>
+			<title>Explicit Configuration</title>
+
+		<para>
+The information concerning which destinations will be validated, and to which model/role they relate, can be explicitly
+defined within the <emphasis>validator-config.xml</emphasis> file, contained within the <emphasis>savara-validator-jbossesb.esb</emphasis> bundle.
+		</para>
+		<para>
+An example of the contents of this file, that would related to the TrailBlazer example, is:
+		</para>
+			<informalexample>
+  				<programlisting role="XML" ><![CDATA[
+	<validator mode="monitor" replyToTimeout="10000" >
+		<service model="TrailBlazer.cdm" 
+					role="LoanBrokerParticipant" >
+			<output epr="jms:queue/esb-tb-creditAgencyQueue" />
+			<input epr="jms:queue/esb-tb-creditAgencyQueue_reply" />
+			<output epr="jms:queue/esb-tb-jmsBankRequestQueue" />
+			<output epr="jms:queue/esb-tb-fileBankRequestQueue" />
+			<input epr="jms:queue/esb-tb-jmsBankResponseQueue" />
+			<output epr="jms:queue/esb-tb-customerNotifier" />
+			<input epr="jms:queue/esb-tb-fileBankResponseQueue" />
+		</service>
+		<service model="TrailBlazer.cdm" 
+					role="CreditAgencyParticipant" >
+			<input epr="jms:queue/esb-tb-creditAgencyQueue" />
+			<output epr="jms:queue/esb-tb-creditAgencyQueue_reply" />
+		</service>
+		<service model="TrailBlazer.cdm" 
+					role="BankParticipant" >
+			<input epr="jms:queue/esb-tb-jmsBankRequestQueue" />
+			<input epr="jms:queue/esb-tb-fileBankRequestQueue" />
+			<output epr="jms:queue/esb-tb-jmsBankResponseQueue" />
+			<output epr="jms:queue/esb-tb-fileBankResponseQueue" />
+		</service>
+		<service model="TrailBlazer.cdm" 
+					role="NotifierParticipant" >
+			<input epr="jms:queue/esb-tb-customerNotifier" />
+		</service>
+	</validator>
+ 				 ]]></programlisting>
+			</informalexample>
+
+			<para>
+The 'validator' element has an optional attribute called 'mode', with the possible values of 'monitor' or 'manage'. If the
+mode is 'monitor' (which is the default), then any messages that result in validation errors being detected will continue to be received or sent, with the errors only be reported for information purposes. If the mode is 'manage', then any erronous messages detected during validation, that conflict with the behaviour as described in the choreography, will be prevented from being received or sent.
+		</para>
+		<note>
+			<para>
+			It is important to note that if 'manage' validation mode is used, then the validation mechanism will be an integral part of the message flow. This may have a slight performance impact on the delivery of messages between services.
+			</para>
+		</note>
+
+		<para>
+The optional 'replyToTimeout' (defined in milliseconds) is used to determine how long a dynamic reply-to destination should be monitored for validation purposes. In some message exchanges, the response destination will not always be known in advance. Therefore the configuration can identify such situations, and monitor the reply-to destination for the response. However, if a response is not delivered in a particular time period, we need to be able to discontinue the validation of the dynamic endpoint. If this did not occur, then over time too many endpoints would be monitored, which may result in out-of-memory problems. The default timeout period is 10 seconds.
+		</para>
+		<para>
+Within the 'validator' element is a list of 'service' elements, one per service being validated. The behaviour of the service being validated is identified by specifying the model (e.g. choreography description file) and the role (e.g. participant type) within the model. Therefore, within the above configuration, the first set of destinations (eprs) are associated with the <emphasis>LoanBrokerParticipant</emphasis> defined within the choreography description model found in the file <filename>TrailBlazer.cdm</filename>, which will be located within the <filename>models</filename> folder contained within the
+<emphasis>savara-validator-jbossesb.esb</emphasis> bundle.
+		</para>
+		<para>
+The elements contained within the 'service' element define the <emphasis>input</emphasis> and <emphasis>output</emphasis> eprs (Endpoint References) that are associated with the service. The <emphasis>input</emphasis> eprs are the destinations on which messages will be received and the <emphasis>output</emphasis> eprs are the destinations on which messages will be sent by the service.
+		</para>
+		<para>
+The format of the 'epr' attribute will be specific to the type of transport used for the ESB aware destination. Currently only JMS is supported, and can be identified by the protocol prefix 'jms:'.
+		</para>
+		<para>
+Each 'input' and 'output' element can also define an optional 'dynamicReplyTo' boolean attribute. If defined, it will indicate to the Service Validator that the message on the specified endpoint (epr) will contain a dynamically defined 'reply-to' destination that needs to be monitored for a response.
+		</para>
+
+		</section>
+
+		<section>
+			<title>Defining the Validator Configuration within a Choreography</title>
+
+		<para>
+		The first step to configuring the validator is to associate the endpoint references (EPRs)
+		against the relevant choreography interactions. This is achieved by defining an
+		annotation for each 'exchange details' component (i.e. each request and response/notification).
+		</para>
+
+		<imageobject>
+			<imagedata fileref="images/editvalidatorann.png" width="5in" />
+		</imageobject>
+
+		<para>
+		When the annotation editor is displayed for the relevant 'exchange details' component,
+		the <emphasis>jbossesb</emphasis> annotation should be added. This is achieved by
+		selecting the popup menu associated with the background of the lefthand panel,
+		and selecting the <emphasis>Add Defined Annotation</emphasis> menu item.
+		</para>
+
+		<imageobject>
+			<imagedata fileref="images/editvalidatoranndiag.png" width="5in" />
+		</imageobject>
+
+		<para>
+		When the list of defined annotations is displayed, select the
+		<emphasis>jbossesb</emphasis> annotation.
+		</para>
+
+		<imageobject>
+			<imagedata fileref="images/editvalidatorannselect.png" width="3in" />
+		</imageobject>
+
+		<para>
+		After pressing the <emphasis>Ok</emphasis> button, the annotation editor
+		will configure the righthand panel with the parameters associated with this
+		annotation.
+		</para>
+
+		<imageobject>
+			<imagedata fileref="images/SVJBossESBAnnotation.jpg" width="5in" />
+		</imageobject>
+
+		<para>
+		To specify the EPR for a particular message exchange, enter the EPR into the
+		<emphasis>Destination</emphasis> field. If the exchange is a request, that
+		will result in a response being sent on a dynamically provided "reply-to"
+		destination, then the <emphasis>Dynamic Reply-To</emphasis> checkbox should be selected.
+		</para>
+
+		<para>
+		Once the annotation has been defined, then press the <emphasis>Save</emphasis>
+		button to save the annotation against the interaction's exchange details.
+		</para>
+
+		<para>
+		When all of the relevant 'exchange details' components have been configured with
+		a <emphasis>jbossesb</emphasis> annotation, defining the EPR to be validated,
+		then the choreography description file can be copied into the
+		<filename>savara-validator-jbossesb.esb/models</filename> folder. This will cause
+		the validation mechanism to derive the configuration information from the choreography
+		description model, and begin validating the defined destinations against that
+		choreography description model.
+		</para>
+
+		</section>
+
+	</section>
+
+	<section>
+		<title>Monitoring the Choreography Description</title>
+<para>
+Once the JBossESB environment has been configured, to perform service validation of a set of ESB services against a choreography
+description, and the server has been started, then the next step is to launch a tool to view the correlated information from
+the service validators - and determine if the transactions are being correctly executed.
+</para>
+<para>
+Within an Eclipse Java project, that contains the choreography description to be monitored, a configuration file called <emphasis>pi4soa.xml</emphasis> needs to be defined on the project's classpath. This file provides details of the JMS configuration parameters required to subscribe for the information generated by the service validators. The contents of this file is:
+</para>
+			<informalexample>
+  				<programlisting role="XML" ><![CDATA[
+<pi4soa>
+   	<tracker>
+	   	<jndi>
+			<initialContextFactory>org.jnp.interfaces.NamingContextFactory</initialContextFactory>
+	      		<providerURL>jnp://localhost:1099</providerURL>
+	      		<factoryURLPackages>org.jboss.naming:org.jnp.interfaces</factoryURLPackages>
+	    	</jndi>
+	   	<jms>
+	     		<connectionFactory>ConnectionFactory</connectionFactory>
+	     		<connectionFactoryAlternate>ConnectionFactory</connectionFactoryAlternate>
+	     		<destination>topic/tracker</destination>
+	   	</jms>
+	</tracker> 
+</pi4soa>
+ 				 ]]></programlisting>
+			</informalexample>
+
+<para>
+The destination defined in this file must match the one configured in the <emphasis>pi4soa.sar/pi4soa.xml</emphasis> file within the server.
+</para>
+		<para>
+The next step is to launch the monitoring tool. This is located on the popup menu, for the choreography description (i.e. .cdm) file, by selecting the Choreography->Monitor menu item. Once the tool has been launched, it will load the choreography description, subscribe to the relevant event destination, and then indicate via a message in the bottom status line that it is ready to monitor.
+		</para>
+
+		<imageobject>
+			<imagedata fileref="images/monitorui.png" width="5in" />
+		</imageobject>
+
+		<para>
+	When the information is received, from the service validators representing the different participants (services), it is correlated to show the global status of the business transaction. The list of correlated interactions is show in reverse time order in the image, so in this example a <emphasis>LoanBroker</emphasis> sends a <emphasis>creditCheck</emphasis> message to a <emphasis>CreditAgency</emphasis>, followed by a <emphasis>creditCheckResult</emphasis> being returned.
+		</para>
+		<para>
+If any <emphasis>out of sequence</emphasis> or other error situations arise, these are displayed in red.
+		</para>
+	</section>
+
+	<section>
+		<title>Configuration for Conversation Recording</title>
+
+		<para>
+		As well as validating the interactions between a set of
+		services, against a pre-defined choreography description,
+		it is also possible to use the <emphasis>Service Validators</emphasis>
+		in a non-validating record mode.
+		</para>
+
+		<para>
+		This will be useful in situations where a choreography
+		description does not currently exist, and we wish to
+		use the stream of business events being sent and received
+		by each identified service (or participant type) to
+		gain an understanding of the current business process.
+		</para>
+
+		<para>
+		An example of this type of configuration, associated
+		with the TrailBlazer example, is:
+		</para>
+			<informalexample>
+  				<programlisting role="XML" ><![CDATA[
+	<validator>
+		<service role="LoanBrokerParticipant" validate="false" >
+			<output epr="jms:queue/esb-tb-creditAgencyQueue" />
+			<input epr="jms:queue/esb-tb-creditAgencyQueue_reply" />
+			<output epr="jms:queue/esb-tb-jmsBankRequestQueue" />
+			<output epr="jms:queue/esb-tb-fileBankRequestQueue" />
+			<input epr="jms:queue/esb-tb-jmsBankResponseQueue" />
+			<output epr="jms:queue/esb-tb-customerNotifier" />
+			<input epr="jms:queue/esb-tb-fileBankResponseQueue" />
+		</service>
+		<service role="CreditAgencyParticipant" validate="false" >
+			<input epr="jms:queue/esb-tb-creditAgencyQueue" />
+			<output epr="jms:queue/esb-tb-creditAgencyQueue_reply" />
+		</service>
+		<service role="BankParticipant" validate="false" >
+			<input epr="jms:queue/esb-tb-jmsBankRequestQueue" />
+			<input epr="jms:queue/esb-tb-fileBankRequestQueue" />
+			<output epr="jms:queue/esb-tb-jmsBankResponseQueue" />
+			<output epr="jms:queue/esb-tb-fileBankResponseQueue" />
+		</service>
+		<service role="NotifierParticipant" validate="false" >
+			<input epr="jms:queue/esb-tb-customerNotifier" />
+		</service>
+	</validator>
+ 				 ]]></programlisting>
+			</informalexample>
+
+		<para>
+		To define a <emphasis>Service Validator</emphasis> in record
+		only mode, the <emphasis>model</emphasis> attribute
+		is not specified (because no choreography description exists
+		to be validated against), and the optional <emphasis>validate</emphasis>
+		attribute should be set to <emphasis role="bold">false</emphasis> (by default
+		this attribute is <emphasis role="bold">true</emphasis>).
+		</para>
+	</section>
+
+</chapter>

Added: validator/trunk/docs/pom.xml
===================================================================
--- validator/trunk/docs/pom.xml	                        (rev 0)
+++ validator/trunk/docs/pom.xml	2009-11-25 22:14:32 UTC (rev 92)
@@ -0,0 +1,22 @@
+<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/xsd/maven-4.0.0.xsd">
+
+    <modelVersion>4.0.0</modelVersion>
+
+    <groupId>org.jboss.savara.validator</groupId>
+    <artifactId>docs</artifactId>
+    <packaging>pom</packaging>
+    <name>Savara::Validator::Docs</name>
+    
+    <parent>
+	  <groupId>org.jboss.savara</groupId>
+	  <artifactId>validator</artifactId>
+      <version>1.0-SNAPSHOT</version>
+	</parent>
+  
+    <modules>
+	  <module>samplesguide</module>
+    </modules>
+
+</project>

Added: validator/trunk/docs/samplesguide/pom.xml
===================================================================
--- validator/trunk/docs/samplesguide/pom.xml	                        (rev 0)
+++ validator/trunk/docs/samplesguide/pom.xml	2009-11-25 22:14:32 UTC (rev 92)
@@ -0,0 +1,85 @@
+<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/xsd/maven-4.0.0.xsd">
+
+    <modelVersion>4.0.0</modelVersion>
+
+    <groupId>org.jboss.savara.validator.docs</groupId>
+    <artifactId>samplesguide</artifactId>
+    <packaging>jdocbook</packaging>
+    <name>Savara::Validator::Docs::SamplesGuide</name>
+
+   <parent>
+    <groupId>org.jboss.savara.validator</groupId>
+    <artifactId>docs</artifactId>
+    <version>1.0-SNAPSHOT</version>
+   </parent>
+
+
+    <build>
+        <plugins>
+            <plugin>
+			<groupId>org.jboss.maven.plugins</groupId>
+			<artifactId>maven-jdocbook-plugin</artifactId>
+			<version>2.1.2</version>
+			<extensions>true</extensions>
+			<executions>
+			  <execution>
+			    <id>generate-docbook</id>
+			    <phase>package</phase>
+			    <goals>
+			      <goal>resources</goal>
+			      <goal>generate</goal>
+			    </goals>
+			  </execution>
+			</executions>
+			<dependencies>
+			  <dependency>
+			    <groupId>org.jboss</groupId>
+			    <artifactId>jbossorg-docbook-xslt</artifactId>
+			    <version>1.1.0</version>
+			  </dependency>
+			  <dependency>
+			    <groupId>org.jboss</groupId>
+			    <artifactId>jbossorg-jdocbook-style</artifactId>
+			    <version>1.1.0</version>
+			    <type>jdocbook-style</type>
+			  </dependency>
+			</dependencies>
+			<configuration>
+			  <sourceDocumentName>master.xml</sourceDocumentName>
+			  <sourceDirectory>${basedir}/src/main</sourceDirectory>
+			  <imageResource>
+			    <directory>${basedir}/src/main</directory>
+			    <includes>
+			      <include>images/**/*</include>
+			    </includes>
+			  </imageResource>
+		            <formats>
+		                <format>
+		                    <formatName>pdf</formatName>
+		                    <stylesheetResource>file:///${basedir}/src/main/xslt/pdf.xsl</stylesheetResource>
+				            <finalName>SAVARA-Validator-SamplesGuide.pdf</finalName>
+		                </format>
+						<format>
+						    <formatName>html</formatName>
+							<stylesheetResource>classpath:/xslt/org/jboss/xhtml.xsl</stylesheetResource>
+							<finalName>index.html</finalName>
+						</format>
+		                <format>
+		                    <formatName>html_single</formatName>
+		                    <stylesheetResource>classpath:/xslt/org/jboss/xhtml-single.xsl</stylesheetResource>
+		                    <finalName>index.html</finalName>
+		                </format>
+		            </formats>
+			  <options>
+			    <xincludeSupported>true</xincludeSupported>
+			    <xmlTransformerType>saxon</xmlTransformerType>
+			    <docbookVersion>1.72.0</docbookVersion>
+			  </options>
+			</configuration>
+            </plugin>           
+        </plugins>
+    </build>
+
+</project>

Added: validator/trunk/docs/samplesguide/src/main/images/ChoreoMonReady.jpg
===================================================================
(Binary files differ)


Property changes on: validator/trunk/docs/samplesguide/src/main/images/ChoreoMonReady.jpg
___________________________________________________________________
Name: svn:mime-type
   + application/octet-stream

Added: validator/trunk/docs/samplesguide/src/main/images/MonitorMenu.jpg
===================================================================
(Binary files differ)


Property changes on: validator/trunk/docs/samplesguide/src/main/images/MonitorMenu.jpg
___________________________________________________________________
Name: svn:mime-type
   + application/octet-stream

Added: validator/trunk/docs/samplesguide/src/main/images/TrailblazerWebPage.jpg
===================================================================
(Binary files differ)


Property changes on: validator/trunk/docs/samplesguide/src/main/images/TrailblazerWebPage.jpg
___________________________________________________________________
Name: svn:mime-type
   + application/octet-stream

Added: validator/trunk/docs/samplesguide/src/main/master.xml
===================================================================
--- validator/trunk/docs/samplesguide/src/main/master.xml	                        (rev 0)
+++ validator/trunk/docs/samplesguide/src/main/master.xml	2009-11-25 22:14:32 UTC (rev 92)
@@ -0,0 +1,17 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
+<!ENTITY % RH-ENTITIES SYSTEM "Common_Config/rh-entities.ent">
+]>
+
+<book lang="en">
+  <bookinfo>
+    <title>SAVARA Validator 1.0-SNAPSHOT</title>
+    <subtitle>Samples Guide</subtitle>
+    <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="module/author_group.xml"/>
+  </bookinfo>
+  
+  <toc/>
+  <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="module/overview.xml"/>
+  <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="module/cdlvalidator.xml"/>
+
+</book>

Added: validator/trunk/docs/samplesguide/src/main/module/author_group.xml
===================================================================
--- validator/trunk/docs/samplesguide/src/main/module/author_group.xml	                        (rev 0)
+++ validator/trunk/docs/samplesguide/src/main/module/author_group.xml	2009-11-25 22:14:32 UTC (rev 92)
@@ -0,0 +1,7 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE authorgroup PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
+]>
+<authorgroup>
+	<corpauthor>Gary Brown</corpauthor>
+	<corpauthor>Jeff Yu</corpauthor>
+</authorgroup>

Added: validator/trunk/docs/samplesguide/src/main/module/cdlvalidator.xml
===================================================================
--- validator/trunk/docs/samplesguide/src/main/module/cdlvalidator.xml	                        (rev 0)
+++ validator/trunk/docs/samplesguide/src/main/module/cdlvalidator.xml	2009-11-25 22:14:32 UTC (rev 92)
@@ -0,0 +1,132 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
+]>
+<chapter id="cdlvalidator">
+  <title>CDL Validator</title>
+
+  <section>
+	<title>Trailblazer Example</title>
+
+	<para>
+This example can be found in the <filename>trailblazer</filename> folder, which contains an enhanced version of the trailblazer example found in the JBossESB distribution. See the TrailBlazer Guide in the JBossESB distribution (<filename>$JBossESB/docs/samples/TBGuide.pdf</filename>) for more information about the example. The main changes are the introduction of a File Based Bank, and modifications to the message structures to enable a consistent conversation id to be carried with the messages.
+	</para>
+
+<note>
+	<para>
+The choreography description for the Trailblazer example can be found in the <emphasis>trailblazer-models</emphasis> project in the Eclipse environment. If the project has not yet been imported, then please refer to the instructions in the <emphasis>Getting Started Guide</emphasis>.
+	</para>
+	<para>
+You can open the choreography for the trailblazer (trailblazer.cdm) and also a scenario representing a valid transaction associated with the choreography (LoanRequest.scn). In the choreography description editor, view the "Choreography Flows" tab to see the structure of the process.
+	</para>
+	<para>
+To simulate the scenario against the choreography, to ensure that the choreography correctly caters for the valid business scenario, the user should press the green 'play' button in the toolbar, associated with the Scenario Editor.
+	</para>
+</note>
+
+
+  <orderedlist>
+	  <listitem>
+Update the <filename>$JBossAS/server/default/deploy/jbossesb.sar/jbossesb-properties.xml</filename> file, in the section entitled "transports" and specify all of the SMTP mail server settings for your environment.
+	</listitem>
+	<listitem>
+Update the <filename>trailblazer/trailblazer.properties</filename>
+	<para>
+Update the <property>file.bank.monitored.directory</property> and <property>file.output.directory</property> properties. These are folders used by the File Based Bank, and are set to <filename>/tmp/input</filename> and <filename>/tmp/output</filename> by default. If the selected folders do not exist, then please ensure they are created prior to running the example.
+	</para>
+	</listitem>
+	<listitem>
+Update the <filename>trailblazer/esb/conf/jboss-esb.xml</filename>
+	<para>
+There is a <emphasis>fs-provider</emphasis> block, update the <property>directory</property> attribute value to be the same as the <property>file.output.directory</property> value in <filename>trailblazer.properties</filename> file.
+	</para>
+	</listitem>
+	<listitem>
+Start the JBossAS server
+	</listitem>
+	<listitem>
+From the <filename>trailblazer</filename> folder, execute the command to start the ESB: <emphasis role="bold">ant deploy</emphasis>
+	<para>
+this should deploy the ESB and WAR files to your JBoss AS <filename>server/default</filename>.
+	</para>
+	</listitem>
+	<listitem>
+From the <filename>trailblazer/banks</filename> folder, execute the command to start the JMS Bank service: <emphasis role="bold">ant runJMSBank</emphasis>.
+	</listitem>
+	<listitem>
+From the <filename>trailblazer/banks</filename> folder, execute the command to start the JMS Bank service: <emphasis role="bold">ant runFileBank</emphasis>.
+	</listitem>
+	<listitem>
+		<para>
+In the Eclipse environment, select the popup menu associated with the <filename>trailblazer.cdm</filename> file, and choose the <emphasis>Choreography->Monitor</emphasis> menu item.
+		</para>
+
+		<imageobject>
+			<imagedata fileref="images/MonitorMenu.jpg" align="center" width="2in" />
+		</imageobject>
+
+		<para>
+Wait for the monitor window to start, and indicate that the choreography is being monitored, shown in the status line at the bottom of the window.
+		</para>
+
+		<imageobject>
+			<imagedata fileref="images/ChoreoMonReady.jpg" align="center" width="4in" />
+		</imageobject>
+
+	</listitem>
+	<listitem>
+		<para>
+Start a browser and enter the URL: <ulink url="http://localhost:8080/trailblazer">localhost:8080/trailblazer</ulink>.
+		</para>
+
+		<imageobject>
+			<imagedata fileref="images/TrailblazerWebPage.jpg" align="center" width="4in" />
+		</imageobject>
+
+	</listitem>
+	<listitem>
+Now you can submit quotes, You will see either a loan request rejected (single email) because the score is less than 4, or two emails (one from JMS bank and one from FileBased bank) with valid quotes. When entering subsequent quotes, make sure that the quote reference is updated, so that each session has a unique id.
+	</listitem>
+     </orderedlist>
+	<para>
+To demonstrate what occurs when the implementation deviates from the expected behaviour as defined in the choreography description, try the following steps:
+	</para>
+    <orderedlist>
+	<listitem>
+		Run the ant task <emphasis role="bold">ant deploy-error-client</emphasis> to redeploy the trailblaizer example.
+	</listitem>	
+	<listitem>
+		Run the commands from step 6 above.
+	</listitem>
+	</orderedlist>
+	<para>
+		The above steps show how changing the service implementation without updating a choreography can result in behavioural validation errors being detected. 	
+	</para>
+	<tip>
+	   <title>What is changed when we run ant deploy-error-client</title>
+		<para>
+			Compared to command of <emphasis role="bold">ant deploy</emphasis>, basically, we have just updated the following code in
+			<emphasis role="bold">$Overlord/samples/trailblazer/client/src/org/jboss/soa/esb/samples/trailblazer/loanbroker/LoanBroker.java</emphasis> file.
+		</para>
+		<para>
+		In the following code within the <emphasis role="bold">processLoanRequest</emphasis> method, we've changed the "4" to "7"
+		
+<programlisting>
+        //step 2 - check if score is acceptable        
+        if (score >= 4) {
+</programlisting>
+		</para>
+	</tip>  
+	
+	<para>
+	Issue further loan requests, remembering to change the quote reference each time, until a Credit Check result of between 4 and 6 inclusive occurs, which will result in an out of sequence message being reported (in red) to the Choreography Monitor
+
+	<note>
+		<para>
+		It is currently a requirement that the choreography used within the Choreography Monitor is the same as the description used to locally monitor the services (i.e. within the overlord-cdl-validator.esb/models directory).
+		</para>
+	</note>	
+	</para>
+
+  </section>
+	
+</chapter>

Added: validator/trunk/docs/samplesguide/src/main/module/overview.xml
===================================================================
--- validator/trunk/docs/samplesguide/src/main/module/overview.xml	                        (rev 0)
+++ validator/trunk/docs/samplesguide/src/main/module/overview.xml	2009-11-25 22:14:32 UTC (rev 92)
@@ -0,0 +1,30 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
+]>
+<chapter id="overview">
+  <title>Overview</title>
+  <para>The Overlord CDL distribution contains two main types of functionality:</para>
+  <orderedlist>
+	  <listitem>
+		  the ability to validate executing services against a choreography description (an example of runtime governance).
+	  </listitem>
+	  <listitem>
+		  the ability to build an ESB using 'conversation aware' actions which can be checked for conformance against a choreography description (an example of design time governance).
+	  </listitem>
+  </orderedlist>	
+	
+	<para>
+		This document will describe the samples available to demonstrate each aspect of the functionality.
+	</para>
+	<para>
+		Further information about configuring the runtime validation of services against a choreography can be found in the <emphasis role="bold">UserGuide</emphasis>. 
+		Information regarding the conversation aware ESB actions, and how to use them in conjunction with conformance checking against a choreography description, can also be found in the <emphasis role="bold">UserGuide</emphasis>.
+	</para>
+	
+	<note>
+		<para>
+			Before attempting to install and run these examples, you must follow the instructions in the <emphasis role="bold">"Installation" Chapter</emphasis> of the <emphasis role="bold">Getting Started Guide</emphasis> regarding installing Overlord CDL into a JBossAS environment, and importing the samples into the Eclipse environment.
+		</para>
+	</note>
+	
+</chapter>

Added: validator/trunk/docs/samplesguide/src/main/xslt/pdf.xsl
===================================================================
--- validator/trunk/docs/samplesguide/src/main/xslt/pdf.xsl	                        (rev 0)
+++ validator/trunk/docs/samplesguide/src/main/xslt/pdf.xsl	2009-11-25 22:14:32 UTC (rev 92)
@@ -0,0 +1,91 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" 
+                xmlns:fo="http://www.w3.org/1999/XSL/Format"
+                version="1.0">
+
+  <xsl:import href="http://docbook.sourceforge.net/release/xsl/1.72.0/fo/docbook.xsl" />
+  <xsl:import href="classpath:/xslt/org/jboss/pdf.xsl" />
+
+  <!-- Override the default font settings -->
+  <xsl:param name="body.font.family" select="'Times New Roman, serif'" />
+  <xsl:param name="monospace.font.family" select="'DejaVu Sans Mono, monospace'" />
+  <xsl:param name="sans.font.family" select="'Arial, sans-serif'" />
+  <xsl:param name="title.font.family" select="$body.font.family" />
+  <xsl:param name="programlisting.font" select="$monospace.font.family" />
+  <xsl:param name="programlisting.font.size" select="'75%'" />
+
+  <!-- Remove the blank pages between the chapters -->
+  <xsl:param name="double.sided" select="0" />
+
+  <!-- Use SVG for callout images instead of PNG -->
+  <xsl:param name="callout.graphics" select="1" />
+  <xsl:param name="callout.graphics.extension" select="'.svg'" />
+
+  <!-- Hide URL -->
+  <xsl:param name="ulink.show" select="0"/>
+
+  <!-- Don't use italic font for links -->
+  <xsl:attribute-set name="xref.properties">
+    <xsl:attribute name="font-style">normal</xsl:attribute>
+  </xsl:attribute-set>
+
+  <!-- Decrease the link font size in the program listing -->
+  <xsl:attribute-set name="monospace.properties">
+    <xsl:attribute name="font-size">1em</xsl:attribute>
+    <xsl:attribute name="font-family">
+        <xsl:value-of select="$monospace.font.family"/>
+    </xsl:attribute>
+  </xsl:attribute-set>
+  
+  <!-- Add some spacing between callout listing items -->
+  <xsl:template match="callout">
+    <xsl:variable name="id"><xsl:call-template name="object.id"/></xsl:variable>
+    <fo:list-item id="{$id}" space-before="1em">
+      <fo:list-item-label end-indent="label-end()">
+        <fo:block>
+          <xsl:call-template name="callout.arearefs">
+            <xsl:with-param name="arearefs" select="@arearefs"/>
+          </xsl:call-template>
+        </fo:block>
+      </fo:list-item-label>
+      <fo:list-item-body start-indent="body-start()">
+        <fo:block padding-top="0.2em">
+          <xsl:apply-templates/>
+        </fo:block>
+      </fo:list-item-body>
+    </fo:list-item>
+  </xsl:template>
+  
+  <!-- Slight baseline-shift for callouts in the program listing -->
+  <xsl:template name="callout-bug">
+    <xsl:param name="conum" select='1'/>
+    <xsl:choose>
+      <xsl:when test="$conum &lt;= $callout.graphics.number.limit">
+        <xsl:variable name="filename"
+                      select="concat($callout.graphics.path, $conum,
+                                     $callout.graphics.extension)"/>
+
+        <fo:external-graphic content-width="{$callout.icon.size}"
+                             width="{$callout.icon.size}"
+                             padding="0.0em" margin="0.0em"
+                             baseline-shift="-0.375em">
+          <xsl:attribute name="src">
+            <xsl:choose>
+              <xsl:when test="$passivetex.extensions != 0
+                              or $fop.extensions != 0
+                              or $arbortext.extensions != 0">
+                <xsl:value-of select="$filename"/>
+              </xsl:when>
+              <xsl:otherwise>
+                <xsl:text>url(</xsl:text>
+                <xsl:value-of select="$filename"/>
+                <xsl:text>)</xsl:text>
+              </xsl:otherwise>
+            </xsl:choose>
+          </xsl:attribute>
+        </fo:external-graphic>
+      </xsl:when>
+    </xsl:choose>
+  </xsl:template>
+</xsl:stylesheet>
+

Added: validator/trunk/pom.xml
===================================================================
--- validator/trunk/pom.xml	                        (rev 0)
+++ validator/trunk/pom.xml	2009-11-25 22:14:32 UTC (rev 92)
@@ -0,0 +1,230 @@
+<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>
+	<groupId>org.jboss.savara</groupId>
+	<artifactId>validator</artifactId>
+	<version>1.0-SNAPSHOT</version>
+	<packaging>pom</packaging>
+	<name>Savara::Validator</name>
+	<url>http://www.jboss.org/savara</url>
+	<description>
+		The JBoss SAVARA Validator. 
+	</description>
+	<scm>
+		<connection>scm:svn:https://svn.jboss.org/repos/savara/validator</connection>
+	</scm>
+	<developers>
+		<developer>
+			<name>Jeff Yu</name>
+			<id>jeff.yuchang</id>
+			<email>cyu at redhat.com</email>
+			<organization>Red Hat</organization>
+			<roles>
+				<role>Developer</role>
+			</roles>
+			<timezone>+8</timezone>
+		</developer>
+		<developer>
+		    <name>Gary Brown</name>
+		    <id>objectiser</id>
+		    <email>gbrown at redhat.com</email>
+		    <organization>Red Hat</organization>
+		    <roles>
+		        <role>Developer</role>
+		    </roles>
+		    <timezone>+1</timezone>
+		</developer>
+	</developers>
+	<modules>
+		<module>jbossesb</module>
+		<!-- module>samples</module -->
+		<module>docs</module>
+		<!-- module>distribution</module -->
+	</modules>
+
+	<profiles>
+		<profile>
+		    <!-- 
+			This profile is activated when the "generate.docs" property is set,
+			as in "mvn ... -Dgenerate.docs=true ..."
+		    -->
+	      <id>docs</id>
+	      <activation>
+	        <property>
+	          <name>generate.docs</name>
+	        </property>
+	      </activation>
+	      <modules>
+	        <module>docs</module>
+	      </modules>
+		  <reporting>
+		    <plugins>
+		      <plugin>
+		        <groupId>org.apache.maven.plugins</groupId>
+		        <artifactId>maven-javadoc-plugin</artifactId>
+		        <configuration>
+		          <aggregate>true</aggregate>
+				  <show>public</show>
+				  <title>JBoss Savara ${project.version}</title>
+		        </configuration>
+		      </plugin>
+		    </plugins>
+		  </reporting>
+	    </profile>
+	</profiles>
+
+	<build>
+		<!-- This section defines the default plugin settings inherited by child projects. -->
+		<pluginManagement>
+			<plugins>
+				<!-- Fixes how test resources of a project can be used in projects dependent on it  -->
+				<plugin>
+					<groupId>org.apache.maven.plugins</groupId>
+					<artifactId>maven-jar-plugin</artifactId>
+					<version>2.2</version>
+				</plugin>
+				<plugin>
+					<groupId>org.apache.maven.plugins</groupId>
+					<artifactId>maven-javadoc-plugin</artifactId>
+					<version>2.2</version>
+					<configuration>
+						<aggregate>true</aggregate>
+					</configuration>
+				</plugin>
+			</plugins>
+		</pluginManagement>
+		<plugins>
+			<!-- Specify the compiler options and settings -->
+			<plugin>
+				<groupId>org.apache.maven.plugins</groupId>
+				<artifactId>maven-compiler-plugin</artifactId>
+                <version>2.0.2</version>
+				<configuration>
+					<source>1.5</source>
+					<target>1.5</target>
+					<showDeprecation>false</showDeprecation>
+					<showWarnings>false</showWarnings>
+				</configuration>
+			</plugin>
+			<!-- Produce source jars during the 'verify' phase -->
+			<plugin>
+				<groupId>org.apache.maven.plugins</groupId>
+				<artifactId>maven-source-plugin</artifactId>
+				<executions>
+					<execution>
+						<id>attach-sources</id>
+						<phase>verify</phase>
+						<goals>
+							<goal>jar</goal>
+						</goals>
+					</execution>
+				</executions>
+			</plugin>
+			<plugin>
+				<artifactId>maven-surefire-plugin</artifactId>
+				<configuration>
+					<includes>
+						<include>**/*TestCase.java</include>
+						<include>**/*Test.java</include>
+					</includes>
+				</configuration>
+			</plugin>
+		</plugins>
+	</build>
+
+	<properties>
+		<savara-version>1.0-SNAPSHOT</savara-version>
+		<junit.version>4.4</junit.version>
+		<rosetta.version>4.5</rosetta.version>
+		<log4j.version>1.2.14</log4j.version>
+        <mvel.version>1.3.4-java1.5</mvel.version>
+	</properties>
+
+	<dependencyManagement>
+	  <dependencies>
+        <dependency>
+            <groupId>junit</groupId>
+            <artifactId>junit</artifactId>
+            <version>${junit.version}</version>
+            <scope>test</scope>
+        </dependency>
+	    <dependency>
+	    	<groupId>org.jboss.overlord.dependencies.org.jboss.esb</groupId>
+	    	<artifactId>jbossesb-rosetta</artifactId>
+	    	<version>${rosetta.version}</version>
+	    </dependency>
+	    <dependency>
+	    	<groupId>log4j</groupId>
+	    	<artifactId>log4j</artifactId>
+	    	<version>${log4j.version}</version>
+	    </dependency>
+	    <dependency>
+	    	<groupId>org.mvel</groupId>
+	    	<artifactId>mvel</artifactId>
+	    	<version>${mvel.version}</version>
+	    </dependency>    
+	  </dependencies>
+	</dependencyManagement>
+
+
+	<reporting>
+		<plugins>
+			<plugin>
+				<groupId>org.apache.maven.plugins</groupId>
+				<artifactId>maven-surefire-report-plugin</artifactId>
+			</plugin>
+	    </plugins>
+	</reporting>
+	
+	<repositories>
+		<repository>
+			<id>jboss</id>
+			<url>http://repository.jboss.com/maven2/</url>
+			<snapshots>
+			  <enabled>false</enabled>
+			</snapshots>
+		</repository>
+		
+		<repository>
+			<id>jboss-snapshot</id>
+			<url>http://snapshots.jboss.org/maven2</url>
+			<snapshots>
+			  <enabled>true</enabled>
+			</snapshots>
+		</repository>
+
+	    <repository>
+	        <id>maven.repo</id>
+	        <name>maven repository</name>
+	        <url>http://repo1.maven.org/maven2</url>
+	    </repository>
+
+	    <repository>
+	        <id>ibiblio</id>
+	        <name>ibiblio repository</name>
+	        <url>http://mirrors.ibiblio.org/pub/mirrors/maven2</url>
+	    </repository>
+
+		<repository>
+		    <id>codehaus</id>
+			<name>codehaus repository</name>
+			<url>http://repo1.maven.org/maven2</url>
+		</repository>
+
+	</repositories>
+
+  <distributionManagement>
+    <repository>
+      <id>jboss</id>
+      <name>JBoss Maven Repository</name>
+      <url>file://${jboss.maven.repository}</url>
+    </repository>
+    <snapshotRepository>
+      <id>jboss-snapshots</id>
+      <name>JBoss Snapshot Repository</name>
+      <url>dav:https://snapshots.jboss.org/maven2</url>
+    </snapshotRepository>
+  </distributionManagement>
+	
+</project>



More information about the savara-commits mailing list