ws-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From veit...@apache.org
Subject svn commit: r1689248 [3/8] - in /webservices/website/woden-staging: ./ css/ dev/ dev/1.0/ fonts/ images/ images/logos/ images/profiles/ img/ js/ skin/
Date Sun, 05 Jul 2015 12:35:56 GMT
Modified: webservices/website/woden-staging/dev/devprocess.html
URL: http://svn.apache.org/viewvc/webservices/website/woden-staging/dev/devprocess.html?rev=1689248&r1=1689247&r2=1689248&view=diff
==============================================================================
--- webservices/website/woden-staging/dev/devprocess.html (original)
+++ webservices/website/woden-staging/dev/devprocess.html Sun Jul  5 12:35:55 2015
@@ -1,1119 +1,1091 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
-<html>
-<head>
-<META http-equiv="Content-Type" content="text/html; charset=UTF-8">
-<meta content="Apache Forrest" name="Generator">
-<meta name="Forrest-version" content="0.8">
-<meta name="Forrest-skin-name" content="pelt">
-<title>Woden Decision Making and Development Processes</title>
-<link type="text/css" href="../skin/basic.css" rel="stylesheet">
-<link media="screen" type="text/css" href="../skin/screen.css" rel="stylesheet">
-<link media="print" type="text/css" href="../skin/print.css" rel="stylesheet">
-<link type="text/css" href="../skin/profile.css" rel="stylesheet">
-<script src="../skin/getBlank.js" language="javascript" type="text/javascript"></script><script src="../skin/getMenu.js" language="javascript" type="text/javascript"></script><script src="../skin/fontsize.js" language="javascript" type="text/javascript"></script>
-<link rel="shortcut icon" href="../">
-</head>
-<body onload="init()">
-<script type="text/javascript">ndeSetTextSize();</script>
-<div id="top">
-<!--+
-    |breadtrail
-    +-->
-<div class="breadtrail">
-<a href="http://www.apache.org/">apache</a> &gt; <a href="http://ws.apache.org/">ws.apache</a><script src="../skin/breadcrumbs.js" language="JavaScript" type="text/javascript"></script>
-</div>
-<!--+
-    |header
-    +-->
-<div class="header">
-<!--+
-    |start group logo
-    +-->
-<div class="grouplogo">
-<a href="http://ws.apache.org/"><img class="logoImage" alt="Web Services" src="../images/ws-logo.gif" title="Web Services @ Apache"></a>
-</div>
-<!--+
-    |end group logo
-    +-->
-<!--+
-    |start Project Logo
-    +-->
-<div class="projectlogo">
-<a href="http://incubator.apache.org/woden/"><img class="logoImage" alt="Woden" src="../images/wodentitle.png" title="Woden is a WSDL 2.0 validating parser."></a>
-</div>
-<!--+
-    |end Project Logo
-    +-->
-<!--+
-    |start Search
-    +-->
-<div class="searchbox">
-<form action="http://www.google.com/search" method="get" class="roundtopsmall">
-<input value="ws.apache.org" name="sitesearch" type="hidden"><input onFocus="getBlank (this, 'Search the site with google');" size="25" name="q" id="query" type="text" value="Search the site with google">&nbsp; 
-                    <input name="Search" value="Search" type="submit">
-</form>
-</div>
-<!--+
-    |end search
-    +-->
-<!--+
-    |start Tabs
-    +-->
-<ul id="tabs">
-<li>
-<a class="unselected" href="../index.html">Woden</a>
-</li>
-<li class="current">
-<a class="selected" href="../dev/index.html">Development</a>
-</li>
-</ul>
-<!--+
-    |end Tabs
-    +-->
-</div>
-</div>
-<div id="main">
-<div id="publishedStrip">
-<!--+
-    |start Subtabs
-    +-->
-<div id="level2tabs"></div>
-<!--+
-    |end Endtabs
-    +-->
-<script type="text/javascript"><!--
-document.write("Last Published: " + document.lastModified);
-//  --></script>
-</div>
-<!--+
-    |breadtrail
-    +-->
-<div class="breadtrail">
-
-             &nbsp;
-           </div>
-<!--+
-    |start Menu, mainarea
-    +-->
-<!--+
-    |start Menu
-    +-->
-<div id="menu">
-<div onclick="SwitchMenu('menu_selected_1.1', '../skin/')" id="menu_selected_1.1Title" class="menutitle" style="background-image: url('../skin/images/chapter_open.gif');">General</div>
-<div id="menu_selected_1.1" class="selectedmenuitemgroup" style="display: block;">
-<div class="menuitem">
-<a href="../dev/index.html" title="Woden Development Overview">Woden Development</a>
-</div>
-<div class="menupage">
-<div class="menupagetitle">Development Processes</div>
-</div>
-<div class="menuitem">
-<a href="../mailinglists.html" title="Woden Mailing Lists">Mailing Lists</a>
-</div>
-<div class="menuitem">
-<a href="../version_control.html" title="Woden - Version Control">Version Control</a>
-</div>
-<div class="menuitem">
-<a href="../issue_tracking.html" title="Woden - Issue Tracking">Issue Tracking</a>
-</div>
-</div>
-<div onclick="SwitchMenu('menu_1.2', '../skin/')" id="menu_1.2Title" class="menutitle">Woden 1.0</div>
-<div id="menu_1.2" class="menuitemgroup">
-<div class="menuitem">
-<a href="../dev/1.0/milestoneplan.html" title="Woden 1.0 Milestone Plan">Milestone Plan</a>
-</div>
-<div class="menuitem">
-<a href="../dev/1.0/builds.html" title="Woden 1.0 builds">Builds</a>
-</div>
-</div>
-<div id="credit"></div>
-<div id="roundbottom">
-<img style="display: none" class="corner" height="15" width="15" alt="" src="../skin/images/rc-b-l-15-1body-2menu-3menu.png"></div>
-<!--+
-  |alternative credits
-  +-->
-<div id="credit2"></div>
-</div>
-<!--+
-    |end Menu
-    +-->
-<!--+
-    |start content
-    +-->
-<div id="content">
-<div title="Portable Document Format" class="pdflink">
-<a class="dida" href="devprocess.pdf"><img alt="PDF -icon" src="../skin/images/pdfdoc.gif" class="skin"><br>
-        PDF</a>
-</div>
-<h1>Woden Decision Making and Development Processes</h1>
-<div id="minitoc-area">
-<ul class="minitoc">
-<li>
-<a href="#Introduction">Introduction</a>
-</li>
-<li>
-<a href="#Open+Development">Open Development</a>
-</li>
-<li>
-<a href="#Project+Status">Project Status</a>
-</li>
-<li>
-<a href="#Project+Discussion+and+Communication">Project Discussion and Communication</a>
-</li>
-<li>
-<a href="#Development+Process">Development Process</a>
-</li>
-<li>
-<a href="#Bug+Tracking+and+Work+Items">Bug Tracking and Work Items</a>
-</li>
-<li>
-<a href="#Source+Code">Source Code</a>
-</li>
-<li>
-<a href="#Building">Building</a>
-</li>
-<li>
-<a href="#Testing">Testing</a>
-</li>
-<li>
-<a href="#Release+Process">Release Process</a>
-</li>
-<li>
-<a href="#Connection+with+W3C+WSDL+Working+Group">Connection with W3C WSDL Working Group</a>
-</li>
-</ul>
-</div> 
-  	
-<a name="N1000D"></a><a name="Introduction"></a>
-<h2 class="boxed">Introduction</h2>
-<div class="section">
-<p>
-      	This document summarizes the Woden decision making and development processes. It is expected that this
-      	document will be useful to 
-      </p>
-<ol>
-      	
-<li>Hold current committers accountable to the established Woden processes</li>
-      	
-<li>Assist new contributors in getting up-to-speed with the Woden development processes 
-      		in order to ensure all Woden contributors are doing things the Woden way and more 
-      		generally the Apache way</li>
-      	
-<li>Provide a clear view of the way in which Woden is developed for the Open Source community</li>
-      
-</ol>
-</div>
-    
-<a name="N10023"></a><a name="Open+Development"></a>
-<h2 class="boxed">Open Development</h2>
-<div class="section">
-<p>
-      	Apache Woden is an Open Source project and the development of Woden is therefore being conducted 
-      	in an open fashion. This theme should be evident
-      	as you read through this guide of the Woden decision making and development processes.
-      	At a high level what Open development means is that the entire development process of Woden is open to the
-      	community. Nothing is kept behind closed doors and information is readily available via the Woden
-      	Web site, mailing list, and wiki. The key here is transparency. If you (that's right, YOU) think the
-      	Woden development team is not being transparent it is your right to identify in what way we are not
-      	being transparent and hold us accountable to 
-      	<a href="http://incubator.apache.org/learn/theapacheway.html">The Apache Way</a>.
-      </p>
-</div>
-    
-<a name="N10031"></a><a name="Project+Status"></a>
-<h2 class="boxed">Project Status</h2>
-<div class="section">
-<p>
-      	Woden's status is currently available from a number of sources:
-      </p>
-<ul>
-      	
-<li>
-<a href="http://wiki.apache.org/ws/FrontPage/BoardReports">Apache Web Service Project board reports</a>. Reports are currently produced every 3 months.</li>
-      	
-<li>
-<a href="http://wiki.apache.org/incubator/">Apache Incubator board reports</a>. Reports are currently produced every 3 months.</li>
-      	
-<li>
-<a href="http://incubator.apache.org/projects/woden.html">Woden Incubation Status File</a>
-</li>
-      	
-<li>
-<a href="../">Woden Web site</a>
-</li>
-      	
-<li>
-<a href="../mailinglists.html">woden-dev mailing list posts</a>
-</li>
-      
-</ul>
-</div>
-    
-<a name="N10059"></a><a name="Project+Discussion+and+Communication"></a>
-<h2 class="boxed">Project Discussion and Communication</h2>
-<div class="section">
-<p>
-      	All project wide communication is done in the open. This is not to suggest that one-on-one conversations
-      	amoung Woden committers and contributors is not allowed. This type of conversation is extremely valuable to
-      	the project's development and is encouraged. However, when anything other than a trivial decision is to be 
-      	made it must be done in the presence of the Woden community.
-      </p>
-<p>
-      	There are 3 methods of communicating openly with the Woden development team and community:
-      </p>
-<ol>
-      	
-<li>the woden-dev mailing list</li>
-      	
-<li>the weekly public status telecons</li>
-      	
-<li>IRC</li>
-      
-</ol>
-</div>
-    
-<a name="N10072"></a><a name="Development+Process"></a>
-<h2 class="boxed">Development Process</h2>
-<div class="section">
-<p>
-      	Woden follows a milestone develoment process. The key to milestone development is that there are a number
-      	of milestone defining criteria specified at the beginning of the milestone process. The milestone can only
-      	be declared once those milestone defining criteria are met. For example, in Woden M8 the priority 1 defining
-      	criteria are that Woden must pass all 'good' and 'bad' test cases in the WSDL 2.0 test suite.
-      </p>
-<p>
-      	Woden milestone plans are communicated through the woden-dev mailing list and posted to the 
-      	<a href="1.0/milestoneplan.html">Woden Web site</a>. In addition, all plan items are recorded in Jira,
-      	Woden's bug tracking system.
-      </p>
-<p>
-      	The Woden milestone planning process is an Open process. Woden takes into account the needs of adopter,
-      	like Apache Axis2, when planning. Please communicate requirements via Jira and the woden-dev list.
-      </p>
-</div>
-    
-<a name="N10086"></a><a name="Bug+Tracking+and+Work+Items"></a>
-<h2 class="boxed">Bug Tracking and Work Items</h2>
-<div class="section">
-<p>
-      	All bugs and work items are stored in <a href="../issue_tracking.html">Jira</a>. It is a Woden best 
-      	practice to associate a Jira entry with every code change.
-      </p>
-</div>
-    
-<a name="N10094"></a><a name="Source+Code"></a>
-<h2 class="boxed">Source Code</h2>
-<div class="section">
-<p>
-      	Woden uses Subversion (SVN) for source control and all Woden code is stored in the 
-      	<a href="../version_control.html">Woden SVN repository</a>. See the "SVN Client Configuration" section
-      	at this link for action required to handle EOL characters in a platform-neutral way.
-      </p>
-<p>
-      	All code developed as part of Woden is licensed under the Apache Software License v2.0 (ASL v2.0). All
-      	Woden source files must include the Apache boilerplate at the top of the file:
-      </p>
-<p>
-
-<span class="codefrag">/**</span>
-<br>
-
-<span class="codefrag">&nbsp;* Licensed to the Apache Software Foundation (ASF) under one or more</span>
-<br>
-
-<span class="codefrag">&nbsp;* contributor license agreements.  See the NOTICE file distributed with</span>
-<br>
-
-<span class="codefrag">&nbsp;* this work for additional information regarding copyright ownership.</span>
-<br>
-
-<span class="codefrag">&nbsp;* The ASF licenses this file to You under the Apache License, Version 2.0</span>
-<br>
-
-<span class="codefrag">&nbsp;* (the "License"); you may not use this file except in compliance with</span>
-<br>
-
-<span class="codefrag">&nbsp;* the License.  You may obtain a copy of the License at</span>
-<br>
-
-<span class="codefrag">&nbsp;* </span>
-<br>
-
-<span class="codefrag">&nbsp;*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;http://www.apache.org/licenses/LICENSE-2.0 </span>
-<br>
-
-<span class="codefrag">&nbsp;* </span>
-<br>
-
-<span class="codefrag">&nbsp;* Unless required by applicable law or agreed to in writing, software </span>
-<br>
-
-<span class="codefrag">&nbsp;* distributed under the License is distributed on an "AS IS" BASIS, </span>
-<br>
-
-<span class="codefrag">&nbsp;* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. </span>
-<br>
-
-<span class="codefrag">&nbsp;* See the License for the specific language governing permissions and </span>
-<br>
-
-<span class="codefrag">&nbsp;* limitations under the License.</span>
-<br>
-
-<span class="codefrag">&nbsp;*/</span>
-      
-</p>
-<p>
-      	
-<strong>Woden Java coding conventions</strong>
-      
-</p>
-<p>
-        Woden uses common Java coding conventions. The main reason Woden needs an agreed set of coding conventions
-        is to avoid different auto-formatting results when using IDEs like Eclipse and IDEA. If different code 
-        formatting rules are applied to a file via auto-formatting, then reformatting changes may be made along 
-        with any functional changes. If both types of code change are committed to the repository at the same time, 
-        it can be difficult to identify the functional changes from a 'diff' of the file.
-      </p>
-<p>
-        To avoid this problem, the Woden project has 2 rules about coding conventions:
-      </p>
-<ol>
-      
-<li>
-        Use the agreed set of code formatting conventions, described below.
-      </li>
-      
-<li>
-        Don't include auto-reformatting changes and other changes in the same commit. 
-        Commit them separately, but close together to avoid merge conflicts. 
-        If you need to auto-reformat and apply a lot of new function, warn other developers about the files you're 
-        working on, then auto-reformat and commit to establish the no-op baseline, then apply your functional 
-        changes and commit.
-      </li>
-      
-</ol>
-<p>
-        
-<strong>Eclipse code formatter default settings</strong>
-      
-</p>
-<p>
-        Use the default code formatting provided with Eclipse 3.3, with one exception - the max line length should 
-        be 100 instead of 80. A subset of the most notable conventions (i.e. the ones that have caused us the most 
-        auto-reformatting problems) are described below. (TODO - check if there's a way to export these settings).
-      </p>
-<p>
-        To access these settings in Eclipse 3.3 navigate to menu Window-&gt;Preferences-&gt;Java-&gt;Code Style-&gt;Formatter. 
-      </p>
-<ul>
-      
-<li>click the 'Edit' button to see the settings on tabbed pages</li>
-      
-<li>on the 'Line Wrapping' and 'Comments' tabs, change the Max Line Length from 80 to 100</li>
-      
-</ul>
-<p>
-        
-<strong>Indentation</strong>
-      
-</p>
-<p>Tab Policy - 4 spaces (not Tab character).</p>
-<p>Indentation - 4 spaces for each indent.</p>
-<p>What to indent;</p>
-<ul>
-      
-<li>declarations within class body</li>
-      
-<li>statements within method/constructor body</li>
-      
-<li>statements within blocks (if/else, case, loops)</li>
-      
-</ul>
-<p>
-        
-<strong>Braces</strong>
-      
-</p>
-<p>
-        Opening brace '{' on the same line and closing brace '}' with same indentation as the statement the block 
-        applies to.
-      </p>
-<p>
-        Example:
-      </p>
-<pre class="code">
-        while(loop_condition) {
-            if(some_condition) {
-                ...
-            } else if(other_condition) {
-                ...
-            } else {
-                break;
-            }
-            ...
-        }
-      </pre>
-<p>
-        
-<strong>New Lines</strong>
-      
-</p>
-<p>
-        Keep 'else if' on one line.
-      </p>
-<p>
-        Example:
-      </p>
-<pre class="code">
-          } else if(other_condition) {
-      </pre>
-<p>
-        
-<strong>Line Wrapping</strong>
-      
-</p>
-<p>
-        Max line length (wrap after) 100 chars.<br>
-        Indentation for wrapped lines is 2 indents (e.g. 8 spaces).
-      </p>
-<p>
-        
-<strong>Accessor method names</strong>
-      
-</p>
-<p>
-        Use 'get' / 'set' prefix for public accessor methods (e.g. <span class="codefrag">getNamespace()</span>, 
-        <span class="codefrag">setNamepsace(URI)</span>).<br>
-        Use 'is' prefix for getters that return booleans (e.g. <span class="codefrag">isValid()</span>).
-      </p>
-<p>
-        
-<strong>Comments</strong>
-      
-</p>
-<p>
-        Do not auto-reformat existing comments, but note the max line convention above (100 chars).
-      </p>
-<p>
-        Use Javadoc comments for all public/protected API class, method and field declarations. For example;
-      </p>
-<ul>
-      
-<li>the class declaration for <span class="codefrag">org.apache.woden.wsdl20.Binding</span>
-</li>
-      
-<li>the method declaration for <span class="codefrag">org.apache.woden.wsdl20.Binding.getInterface()</span>
-</li>
-      
-<li>the static constant <span class="codefrag">org.apache.woden.WSDLReader.FEATURE_VERBOSE</span>
-</li>
-      
-</ul>
-<p>
-        Use Javadoc comments for all public/protected implementation class, method and field declarations. For example;
-      </p>
-<ul>
-      
-<li>content of <span class="codefrag">.internal.</span> packages, such as <span class="codefrag">org.apache.woden.internal.wsdl20.*</span>
-</li>
-      
-</ul>
-<p>
-        When implementing or overriding API methods, use the <span class="codefrag">@see</span> tag to specify the relevant method.
-        For example, for the implementation method <span class="codefrag">org.apache.woden.internal.wsdl20.BindingImpl.getInterface()</span> use:
-      </p>
-<ul>
-      
-<li>
-<span class="codefrag">@see org.apache.woden.wsdl20.Binding#getInterface()</span>
-</li>
-      
-</ul>
-<p>
-        For all private/package private declarations, where comments are required use non-Javadoc comments.
-      </p>
-</div>
-    
-<a name="N101AA"></a><a name="Building"></a>
-<h2 class="boxed">Building</h2>
-<div class="section">
-<p>
-        Woden defines an API and provides 2 implementations of it. One is based on the Document Object Model (DOM) 
-        and the other on the Axiom Object Model (OM).
-        </p>
-<p>The Woden build produces 3 binary jar files:</p>
-<ul>
-        
-<li>
-        
-<span class="codefrag">woden-api-[version].jar</span> - the WODEN API classes.
-        </li>
-        
-<li>
-        
-<span class="codefrag">woden-impl-dom-[version].jar</span> - the DOM-specific classes and any common implementation classes. 
-        </li>
-        
-<li>
-        
-<span class="codefrag">woden-impl-om-[version].jar</span> - the OM-specific classes and any common implementation classes.
-        </li>
-        
-</ul>
-<p>These jar files are packaged into 2 binary distributions (as zip and tar archives):</p>
-<ul>
-        
-<li>
-        
-<span class="codefrag">apache-woden-dom-[version].zip</span> - contains the API and DOM jar files and the relevant jar file dependencies.
-        </li>
-        
-<li> 
-        
-<span class="codefrag">apache-woden-om-[version].zip</span> - contains the API and OM jar files and the relevant jar file dependencies.
-        </li>
-        
-</ul>
-<p>
-        The Woden build also produces a source code distribution (zip and tar): 
-        </p>
-<ul>
-        
-<li>
-<span class="codefrag">apache-woden-src-[version].zip</span>
-</li>
-        
-</ul>
-<p>
-        Woden has <a href="http://ant.apache.org/">Ant</a> and <a href="http://maven.apache.org/">Maven</a> build processes.
-        The Ant build was created originally to produce the jar files and distribution archives.
-        The Maven build was introduced later to integrate the Woden build process with other
-        Apache projects that depend on Woden, like Axis2. 
-        We maintain both build processes so that developers can use the one they prefer.
-        Note however, that the Maven build just produces the 3 jar files (it does not produce the distribution archives).
-        </p>
-<p>
-        
-<strong>Ant</strong> uses a concept of targets to figure out what work to do when you want a certain task done,
-        they are defined inside a build.xml which is in the root of our source directory.
-        There are two main ways in which we run a target, from the command line or inside eclipse.
-        If you want to use the command line you need to download and install Ant from their download site above,
-        then you just use the command <span class="codefrag">ant [targetname]</span> to run a target called targetname.
-        If you want to use Eclipse you need to make sure you have the Ant plug-in, which should come by default
-        depending which package you downloaded, then to run a target you can use the "Run As" context menu on a build.xml file
-        to run it as a "Ant Build" which will run the default ant task or as a "Ant Build..." to specify which target(s) you wish to run.
-        </p>
-<p>The top level ant targets we have and their uses are :-</p>
-<ul>
-            
-<li>
-                
-<span class="codefrag">buildAll</span>
-                - Builds all Woden packages (API, DOM, and OM).
-            </li>
-            
-<li>
-                
-<span class="codefrag">buildAndTestAll</span>
-                - Builds all Woden packages (API, DOM, and OM) then runs all the tests as explained in the Testing section.
-            </li>
-            
-<li>
-                
-<span class="codefrag">distBuild</span>
-               - Builds all Woden packages (API, DOM, and OM) then creates the compressed archives for the DOM and OM distributions with dependencies.
-            </li>
-            
-<li>
-                
-<span class="codefrag">buildAPI</span>
-                - Builds the Woden API package.
-            </li>
-            
-<li>
-                
-<span class="codefrag">buildDOM</span>
-                - Builds the Woden DOM package.
-            </li>
-            
-<li>
-                
-<span class="codefrag">buildOM</span>
-                - Builds the Woden OM package.
-            </li>
-        
-</ul>
-<p>
-<br>These targets all use a common build directory to store their results in, its structure is :-</p>
-<ul>
-            
-<li>
-                
-<span class="codefrag">build/</span>
-                - Root of the build directory.
-            </li>
-            
-<li>
-                
-<span class="codefrag">build/classes/</span>
-                - Classes from building the java source code.
-            </li>
-            
-<li>
-                
-<span class="codefrag">build/dist/</span>
-                - Zip and Tar files of complete distributions in the
-                form apache-woden-[src/dom/om]-[version].[zip/.tar.gz].
-            </li>
-            
-<li>
-                
-<span class="codefrag">build/test/</span>
-                - Test results from Junit tests.
-            </li>
-            
-<li>
-                
-<span class="codefrag">build/jar/</span>
-                - Jar files for each package in for form
-                woden-[api/dom/om]-[version].jar .
-            </li>
-            
-<li>
-                
-<span class="codefrag">build/JavaDoc/</span>
-                - Java Doc pages for all the java classes.
-            </li>
-        
-</ul>
-<p>
-        
-<strong>Maven</strong> uses a set of conventions to simplify the build and deployment process and uses a concept of goals to figure out
-        what needs to be done. The layout of the project is defined in pom.xml files, each of which specifies one distribution.
-        In Woden we have three main distributors so have four pom.xml files, one in the root source directory
-        and one in each of the woden-api, woden-dom and woden-om sub directories. To use Maven you need to 
-        <a href="http://maven.apache.org/download.html">download</a> it, 
-        then run one of the maven goals with <span class="codefrag">mvn [goal]</span>.
-        If you run these from the Woden root directory the goal will be applied all three distributions.
-        </p>
-<p>The main goals you will use are :-</p>
-<ul>
-            
-<li>
-<span class="codefrag">compile</span> - Compiles all three distributions.</li>
-            
-<li>
-<span class="codefrag">test</span> - Compiles then tests all three distributions.</li>
-            
-<li>
-<span class="codefrag">package</span> - Compiles, tests then packages all three distributions.</li>
-        
-</ul>
-<p>
-<br>Woden's Maven build uses the following directory structure :-</p>
-<ul>
-            
-<li>
-<span class="codefrag">/</span> - Root source folder with the pom.xml linking all three distributions.</li>
-            
-<li>
-<span class="codefrag">/woden-api</span> - Woden API distribution, runs Maven goals on just the API java source.</li>
-            
-<li>
-<span class="codefrag">/woden-dom</span> - Woden DOM distribution, runs Maven goals on the DOM and Common java source.</li>
-            
-<li>
-<span class="codefrag">/woden-om</span> - Woden OM distribution, runs Maven goals on the OM and Common java source.</li>
-        
-</ul>
-</div>
-    
-<a name="N1028E"></a><a name="Testing"></a>
-<h2 class="boxed">Testing</h2>
-<div class="section">
-<p>
-        There are 2 test suites for Woden. The <strong>Woden JUnit Test Suite</strong> provided with Woden tests the 
-        Woden API and functionality of the Woden framework (configuration, factory, reader, error handling, etc). 
-        The <strong>W3C WSDL 2.0 Test Suite</strong> tests Woden's compliance with the WSDL 2.0 Recommendation 
-        (i.e. its WSDL 2.0 spec compliance).
-        </p>
-<p>
-        Both of these test suites <em>should</em> be run to test Woden thoroughly. 
-        It's not enough just to run the Woden JUnit tests, because while this suite will test some of the Woden framework 
-        implementation and that Woden implements all of its API, it will not perform a complete WSDL 2.0
-        functional test. That's the job of the W3C WSDL 2.0 Test suite. 
-        Both test suites <em>must</em> be run <em>before</em> committing code to the repository.
-        Code contributions submitted by non-committers as JIRA patches should also be tested against both test suites.
-        </p>
-<p>
-        The Woden JUnit test suite should test the entire Woden API. It should invoke every API method at least once.
-        So for any additions or changes to the API, the Woden JUnit test suite must be updated accordingly.
-        For any non-WSDL functionality added or changed in the Woden implementation(s), appropriate test cases should
-        also be included in the JUnit test suite where appropriate. 
-        </p>
-<p>
-        (TODO - maybe split the JUnit test
-        suite so that an API-only suite exists for use by projects that want to create their own implementation
-        of the Woden API).
-        </p>
-<p>
-        The Woden JUnit test cases <em>must be written using the Woden API</em> (i.e. the correct Woden programming
-        model), unless it's absolutely necessary to exercise the implementation class methods directly for a given
-        test case. This will ensure that the Woden development team can change the implementation at any point 
-        without major impact on the test suite. On several occassions in the past, we have had
-        to do significant, time-consuming rework on the test suite to fix compile breaks introduced when the 
-        implementation changed, because Woden developers had used the implementation classes directly when writing
-        test cases.
-        Our initial reasons for this were "we know the code, so it's okay", but as we've learnt, getting Woden 
-        client code to work is not the same as keeping it working. We expect Woden users to use the API only, so 
-        our test suite should set the right example.
-        </p>
-<p>
-        The W3C WSDL 2.0 Test Suite is complete for the 'good' WSDL test cases. It should now have WSDL test cases
-        that provide full coverage of what <em>is</em> allowed by the WSDL 2.0 specification.
-        The test suite does not yet fully cover the 'bad' WSDL test cases. That is, it does not yet have WSDL test
-        cases for every <em>assertion</em> specified by the WSDL 2.0 specification.
-        All of Woden's WSDL 2.0 functionality (i.e. handling good WSDL and detecting bad WSDL) must be tested against
-        the W3C WSDL 2.0 Test Suite.
-        If a new WSDL 2.0 test case is needed to test some WSLD 2.0 functionality in Woden, Woden developers should
-        create the required test case and then contribute it as a patch to the 
-        <a href="http://dev.w3.org/cvsweb/2002/ws/desc/">W3C WSDL 2.0 CVS repository</a>.  
-        The patch can be submitted via the <a href="http://www.w3.org/Bugs/W3C">W3C Bugzilla system</a>
-        (select the 'WSDL' category when creating a new bug report).
-        </p>
-<p>
-        
-<strong>Woden JUnit Tests</strong> are located in the test/ directory which is structured to mirror the src/ directory
-        for the parts of code tests are written for. There are two ways these can be run; either inside Eclipse or directly from Ant.
-        </p>
-<p>Inside Eclipse the JUnit test(s) can be run by selecting "JUnit Test" in the "Run As" context menu for one test, whole packages,
-        or the entire test folder. Then the tests results with any error messages and stack traces will be displayed in the JUnit panel. 
-        You can also debug JUnit tests from inside Eclipse by selecting the "JUnit Test" from the "Debug As" context menu.
-        </p>
-<p>You can also run the JUnit tests using Ant from the command line or inside Eclipse as described in the
-        <a href="#Building">building</a> section above. The Ant script is the build.xml file in the Woden project's root directory.
-        This script has three test targets which each run a particular subset of the Woden JUnit tests. 
-        </p>
-<ul>
-           
-<li>
-<span class="codefrag">runAllJUnitTests</span> - This runs all of the JUnit tests for both the DOM and OM implementations of Woden.</li>
-           
-<li>
-<span class="codefrag">runOMTests</span> - This runs all the JUnit tests for the OM implementation.</li>
-           
-<li>
-<span class="codefrag">runDOMTests</span> - This runs all of the JUnit tests for the DOM implementation.</li>
-        
-</ul>
-<p>
-        These Ant targets produce an HTML report of the tests results in the file build/test-results/(24 hour)_(minute)_(second)/junit-noframes.html.
-        </p>
-<p>
-        
-<strong>W3C WSDL 2.0 Test Suite</strong> is a collection of WSDL 2.0 documents used to test that a WSDL 2.0 processor complies with 
-        the W3C WSDL 2.0 Recommendation. The processor must successfully process all of the documents in the test suite to demonstrate its 
-        compliance. Each WSDL document represents a test case for some aspect of the WSDL 2.0 spec. These include <em>good</em> test cases, 
-        containing valid WSDL which collectively demonstrate all of the types of WSDL 2.0 syntax permitted by the spec. They also include 
-        <em>bad</em> test cases, containing invalid WSDL which violates one of the WSDL 2.0 assertions defined in the spec. There should be at
-        least one <em>bad</em> test case for each assertion, but the <em>bad</em> test suite is not yet complete. The Woden project will contribute
-        further assertion test cases to the W3C as development of Woden's WSDL validation continues.
-        </p>
-<p> 
-        To demonstrate its spec-compliance, a WSDL 2.0 processor should correctly parse all <em>good</em> WSDL documents and should detect 
-        the correct assertion violation for all <em>bad</em> WSDL documents. The W3C WSDL 2.0 test framework can check that the processor
-        complies in this way. The WSDL 2.0 processor simply needs to capture its results from processing the test suite in some XML formats
-        that the W3C WSDL 2.0 test framework will evaluate against baseline XML results. It will then generate a compliance report based
-        on this comparison.  
-        </p>
-<p>
-        The Woden code tree is setup to facilate using the W3C WSDL 2.0 test suite in this way. It uses ANT scripts to download
-        the W3C WSDL 2.0 test suite (the good and bad WSDL documents), run Woden against this test suite and generate the Woden result files,
-        then copy the result files to your local copy of the W3C project that contains the WSDL 2.0 test framework. This W3C project 
-        is a CVS project called 'desc', short for Description - more on this later. The last step is then to run an ANT script in the 'desc' 
-        project to evaluate Woden's results and generate the HTML reports which compare Woden's results to the W3C baseline. 
-        </p>
-<p>
-        The official versions of these compliance reports are published on the 
-        <a href="http://dev.w3.org/2002/ws/desc/test-suite/Dashboard.html">WSDL 2.0 Interop Dashboard</a>, where the 
-        <em>Component Model Test Results</em> show the results for the <em>good</em> WSDL test suite and the 
-        <em>Validation Test Results</em> show the results for the <em>bad</em> WSDL test suite.
-        </p>
-<p>
-        Here are the steps to run Woden against the W3C WSDL 2.0 Test suite:
-        </p>
-<ol> 
-        
-<li>
-        You need to have run Ant to build Woden as described in the <a href="#Building">building</a> section above.
-        This will not only build the Woden jar's to test against, but it will also ensure that the W3C WSDL 2.0 test suite 
-        has been downloaded by the <span class="codefrag">getW3cWsdl20</span> target in the main build.xml script.
-        </li>
-        
-<li>
-        Run the default target in ant-test/build.xml. This will generate the xml files containing the Woden results.
-        The <em>good</em> test suite result can be found in the ant-test/results/ directory or zipped in the ant-test/test-suite-results.zip
-        file and the <em>bad</em> test suite results are in the ant-test/validation-results.xml file.
-        </li>
-        
-<li>
-        Checkout the 'desc' project from the W3C WSDL 2.0 CVS repository to your local development environment
-        (:pserver:anonymous@dev.w3.org:/sources/public/2002/ws/desc). 
-        Ensure the 'desc' project is in the same local directory as the woden project (e.g.
-        /workspace/woden and /workspace/desc).
-        The WSDL 2.0 test suite and test framework are located in /desc/test-suite directory.
-        </li>
-        
-<li>
-        Run the "copyResultsToW3C" target in Woden's ant-test/build.xml script. This will copy the ant-test/test-suite-results.zip and 
-        ant-test/validation-results.xml files from the woden project to the test-suite/results/downloads/Woden directory in the 
-        'desc' project, then extract these files to the test-suite/results/Woden directory. 
-        </li>
-        
-<li>
-        Run the targets "canonicalize-Woden", "evaluate-Woden", "Interchange.html" and "Validation.html" in the test-suite/results/build.xml 
-        script in the 'desc' project. These will prepare the Woden results for baseline comparison, do the baseline comparison, then
-        generate the <em>good</em> and <em>bad</em> test suite reports. 
-        </li>
-        
-<li>
-        View the reports in test-suite/results/Interchange.html and test-suite/results/Validation.html and check that no regressions
-        have been introduced by the latest Woden build being tested.
-        </li>
-        
-</ol>
-<p>
-        Periodically the W3C WSDL 2.0 Interop Dashboard is republished, using the Woden result files in the ant-test/ directory
-        in the Woden repository. Therefore, these files should be committed periodically to reflect the up-to-date Woden results.
-        (these ant-test/ files include the test-suite-results.zip and validation-results.xml files mentioned above).
-        </p>
-</div>
-    
-<a name="N1034B"></a><a name="Release+Process"></a>
-<h2 class="boxed">Release Process</h2>
-<div class="section">
-<p>
-      	The Woden release process involves many steps and checks. To keep compliant with Apache process requirements
-      	of WS and incubator projects it is important that it is followed.
-      </p>
-<ol>
-      	
-<li>
-      		Build and test the current Woden release candidate. The 'buildDist' ANT target will 
-      		create the binary and source archives  (.zip, .tar.gz, .tar.bz2) and the hash digests 
-      		(md5, sha1) for each archive file.
-		</li>
-		
-<li>
-			Sign the binary and source archives, which will create a .asc signature file for each archive file.<br>
-			
-<br>
-			e.g.<br>
-			
-<span class="codefrag">gpg --armor --output apache-woden-incubating-1.0M7a.zip.asc --detach-sig apache-woden-incubating-1.0M7a.zip</span>
-<br>
-			
-<span class="codefrag">gpg --verify apache-woden-incubating-1.0M7a.zip.asc apache-woden-incubating-1.0M7a.zip</span>
-		
-</li>
-		
-<li>
-			Upload the binary and source archives and their hash digests and signature files to 
-			people.apache.org into some directory path under your public_html directory so that you can include a 
-			link to the files in the [VOTE] request email. Also upload the KEYS file and release-notes.html 
-			from [woden root] and junit-noframes.html from the [woden root]/build/test-results/html directory.
-			Make sure you chmod the file permissions so others can read them (e.g. 744).<br>
-			
-<br>
-			e.g.<br>
-			
-<span class="codefrag">[jkaputin home]/public_html/woden/milestones/1.0M7a-incubating</span>
-<br>
-			...is accessible at url...<br>
-			
-<a href="http://people.apache.org/~jkaputin/woden/milestones/1.0M7a-incubating/">http://people.apache.org/~jkaputin/woden/milestones/1.0M7a-incubating/</a>
-<br>
-			
-<br>
-			Note, because Woden is in incubation you must not upload these files to the Woden project on the 
-			file server until the Incubator PMC vote has passed....so you upload to your own space, then move 
-			to Woden space after voting.
-		</li>
-		
-<li>
-			Check that you can download/unzip the files.<br>
-			Create hash digests of the downloaded archives and check them against the downloaded hash files.<br>
-			
-<br>
-			e.g.<br>
-			
-<span class="codefrag">$ dir</span>
-<br>
-			
-<span class="codefrag">apache-woden-incubating-1.0M7a.zip  apache-woden-incubating-1.0M7a.zip.MD5</span>
-<br>
-			
-<span class="codefrag">$ cat apache-woden-incubating-1.0M7a.zip.MD5</span>
-<br>
-			
-<span class="codefrag">3009d6f6fea14b7536c22028944bb03a</span>
-<br>
-			
-<span class="codefrag">$ md5sum apache-woden-incubating-1.0M7a.zip</span>
-<br>
-			
-<span class="codefrag">3009d6f6fea14b7536c22028944bb03a *apache-woden-incubating-1.0M7a.zip</span>
-		
-</li>
-		
-<li>
-			Post a vote request email to woden-dev asking devs to vote on the proposed M7b release. 
-			Post the voting results.<br>
-			When posting a vote request to any mailing list, start the subject line with the eye-catcher [VOTE].
-		</li>
-		
-<li>
-			If woden-dev vote successful, post to general@ws.apache.org asking the WSPMC to approve a Woden 
-			release. Post the voting results.<br>
-			When posting a vote request to any mailing list, start the subject line with the eye-catcher [VOTE].
-		</li>
-		
-<li>
-			If WSPMC vote successful, post to IPMC at general@incubator. Be specific about timeframe (usually 3 days).
-			Post the results afterwards. Success criteria is at least 3 binding IPMC votes (i.e. 3 x +1 from IPMC 
-			members). Remember, Dims, Sanjiva and Paul F are IPMC members as well as WSPMC.<br>
-			When posting a vote request to any mailing list, start the subject line with the eye-catcher [VOTE].
-		</li>
-		
-<li>
-			If IPMC vote successful, move all the release files from your public_html directory to the Woden 
-			file space on people.apache.org.<br>
-			
-<br>
-			
-<span class="codefrag">cd /www/people.apache.org/dist/ws/woden</span>
-<br>
-			
-<span class="codefrag">cd milestones</span>
-<br>
-			Create a new directory for the release (e.g. /1.0M7a-incubating)<br>
-			Move the release files to this new directory.<br>
-			Copy the file release-notes.html to a new file called README.html in this new directory 
-			(this will ensure the release notes are displayed after the list of files, when this 
-			directory is accessed via the web).<br>
-			
-<br>
-			e.g.<br>
-			
-<span class="codefrag">/www/people.apache.org/dist/ws/woden/milestones/1.0M7a-incubating</span>
-<br>
-			...will be accessible via url...<br>
-			http://people.apache.org/dist/ws/woden/milestones/1.0M7a-incubating/
-		</li>
-		
-<li>
-			Once again, check that:
-			<ul>
-				
-<li>the file permissions are set correctly</li>
-				
-<li>you can download/unzip the files</li>
-				
-<li>the downloaded hash digests are correct</li>
-			
-</ul>
-		
-</li>
-		
-<li>
-			Update the Woden web site (add the release download to the Builds page and add a News item 
-			announcing the release to the Woden home page).
-		</li>
-		
-<li>
-			Post a release announcement to woden-dev, general@ws and general@incubator.
-		</li>
-		
-<li>
-			Final step, which Axis2 folks will do, it to upload Woden release binary jar to a maven 
-			repository...I think Dims can upload to ws.zones.
-		</li>
-	
-</ol>
-<p>
- 		Some example mailing list posts for reference:
- 	</p>
-<p>
-		
-<a href="http://mail-archives.apache.org/mod_mbox/ws-woden-dev/200704.mbox/%3c4c2ae8f80704160812h30e87b93je6e5d52607780265@mail.gmail.com%3e">[VOTE] woden-dev and WSPMC</a>
-	
-</p>
-<p>
-		
-<a href="http://mail-archives.apache.org/mod_mbox/ws-woden-dev/200704.mbox/%3c4c2ae8f80704170847r5f2440dbrc800fabd2298577b@mail.gmail.com%3e">[RESULT]</a>
-	
-</p>
-<p>
-		
-<a href="http://mail-archives.apache.org/mod_mbox/ws-woden-dev/200704.mbox/%3c4c2ae8f80704170938q74458582he93ce5e410e7fe2e@mail.gmail.com%3e">[VOTE] IPMC</a>
-	
-</p>
-<p>
-		
-<a href="http://mail-archives.apache.org/mod_mbox/ws-woden-dev/200704.mbox/%3c4c2ae8f80704230613l5e365f02gf15c3cba1086db2d@mail.gmail.com%3e">[ANNOUNCE]</a>
-	
-</p>
-</div>
-    
-<a name="N10408"></a><a name="Connection+with+W3C+WSDL+Working+Group"></a>
-<h2 class="boxed">Connection with W3C WSDL Working Group</h2>
-<div class="section">
-<p>
-      	Apache Woden was started to answer the W3C WSDL working group's 
-      	<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2006Jan/0023.html">call for implementations</a>.
-      	As such, Woden has been in close communication with the WSDL working group providing feedback on the
-      	WSDL 2.0 specification, requesting clarification, and contributing test cases to the WSDL 2.0 test suite.
-      </p>
-<p>
-      	WSDL 2.0 has been promoted to recommendation status and the WSDL working group has completed its work 
-      	and therefore closed on June 29, 2007. With the working group closed it is expected that a maintenance group
-      	will be set up. Woden will maintain close ties with the maintenance group as there may still be issues
-      	with the WSDL 2.0 specification and the test suite still requires work.
-      </p>
-<p>
-      	Any issues with the WSDL 2.0 specification or test suite should be reported via the WSDL mailing list 
-      	<a href="http://www.w3.org/2002/ws/desc/#lists">www-ws-desc@w3.org</a> and issue tracking repository 
-      	<a href="http://www.w3.org/Bugs/Public/">http://www.w3.org/Bugs/Public/</a>.
-      </p>
-</div>
-    
-  
-</div>
-<!--+
-    |end content
-    +-->
-<div class="clearboth">&nbsp;</div>
-</div>
-<div id="footer">
-<!--+
-    |start bottomstrip
-    +-->
-<div class="lastmodified">
-<script type="text/javascript"><!--
-document.write("Last Published: " + document.lastModified);
-//  --></script>
-</div>
-<div class="copyright">
-        Copyright &copy;
-         2005-2007 The Apache Software Foundation</div>
-<div id="feedback">
-    Send feedback about the website to:
-  <a id="feedbackto" href="mailto:woden-dev@ws.apache.org?subject=Woden-SiteFeedbackdev/devprocess.html">woden-dev@ws.apache.org</a>
-</div>
-<!--+
-    |end bottomstrip
-    +-->
-</div>
-</body>
-</html>
+<!DOCTYPE html>
+<!--
+ | Generated by Apache Maven Doxia at 2015-07-05 
+ | Rendered using Apache Maven Fluido Skin 1.4
+-->
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+  <head>
+    <meta charset="UTF-8" />
+    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
+    <meta name="Date-Revision-yyyymmdd" content="20150705" />
+    <meta http-equiv="Content-Language" content="en" />
+    <title>Woden &#x2013; Woden Decision Making and Development Processes</title>
+    <link rel="stylesheet" href="../css/apache-maven-fluido-1.4.min.css" />
+    <link rel="stylesheet" href="../css/site.css" />
+    <link rel="stylesheet" href="../css/print.css" media="print" />
+
+      
+    <script type="text/javascript" src="../js/apache-maven-fluido-1.4.min.js"></script>
+
+    
+                  </head>
+        <body class="topBarDisabled">
+          
+        
+    
+        <div class="container-fluid">
+          <div id="banner">
+        <div class="pull-left">
+                                                  <a href="../index.html" id="bannerLeft">
+                                                                                                <img src="../images/wodentitle.png"  alt="Apache Woden"/>
+                </a>
+                      </div>
+        <div class="pull-right">                                <a href="../../" id="bannerRight">
+                                                                                                <img src="../../images/project-logo.jpg" />
+                </a>
+      </div>
+        <div class="clear"><hr/></div>
+      </div>
+
+      <div id="breadcrumbs">
+        <ul class="breadcrumb">
+                
+                    
+                              <li class="">
+                    <a href="http://www.apache.org/" class="externalLink" title="Apache">
+        Apache</a>
+                    <span class="divider">/</span>
+      </li>
+            <li class="">
+                    <a href="../../" title="Web Services">
+        Web Services</a>
+                    <span class="divider">/</span>
+      </li>
+            <li class="">
+                    <a href="../" title="Woden">
+        Woden</a>
+                    <span class="divider">/</span>
+      </li>
+        <li class="active ">Woden Decision Making and Development Processes</li>
+        
+                
+                    
+                  <li id="publishDate" class="pull-right"><span class="divider">|</span> Last Published: 2015-07-05</li>
+              <li id="projectVersion" class="pull-right">
+                    Version: 1.0-SNAPSHOT
+        </li>
+            
+                            </ul>
+      </div>
+
+            
+      <div class="row-fluid">
+        <div id="leftColumn" class="span2">
+          <div class="well sidebar-nav">
+                
+                    
+                <ul class="nav nav-list">
+                    <li class="nav-header">Woden</li>
+                              
+      <li>
+  
+                          <a href="../index.html" title="Overview">
+          <span class="none"></span>
+        Overview</a>
+            </li>
+                
+      <li>
+  
+                          <a href="../proposal.html" title="Proposal">
+          <span class="none"></span>
+        Proposal</a>
+            </li>
+                
+      <li>
+  
+                          <a href="../mailinglists.html" title="Mailing Lists">
+          <span class="none"></span>
+        Mailing Lists</a>
+            </li>
+                
+      <li>
+  
+                          <a href="../issue_tracking.html" title="Issue Tracking">
+          <span class="none"></span>
+        Issue Tracking</a>
+            </li>
+                
+      <li>
+  
+                          <a href="../version_control.html" title="Version Control">
+          <span class="none"></span>
+        Version Control</a>
+            </li>
+                
+      <li>
+  
+                          <a href="../projectteam.html" title="Project Team">
+          <span class="none"></span>
+        Project Team</a>
+            </li>
+                
+      <li>
+  
+                          <a href="../projectsusingwoden.html" title="Projects Using Woden">
+          <span class="none"></span>
+        Projects Using Woden</a>
+            </li>
+                              <li class="nav-header">Downloads</li>
+                              
+      <li>
+  
+                          <a href="../dev/1.0/builds.html" title="Builds">
+          <span class="none"></span>
+        Builds</a>
+            </li>
+                              <li class="nav-header">Documentation</li>
+                              
+      <li>
+  
+                          <a href="../userguide.html" title="User Guide">
+          <span class="none"></span>
+        User Guide</a>
+            </li>
+                              <li class="nav-header">Development</li>
+                              
+      <li>
+  
+                          <a href="../dev/index.html" title="Woden Development">
+          <span class="none"></span>
+        Woden Development</a>
+            </li>
+                
+      <li class="active">
+  
+            <a href="#"><span class="none"></span>Development Processes</a>
+          </li>
+                
+      <li>
+  
+                          <a href="../dev/1.0/milestoneplan.html" title="Milestone Plan">
+          <span class="none"></span>
+        Milestone Plan</a>
+            </li>
+                              <li class="nav-header">Apache</li>
+                              
+      <li>
+  
+                          <a href="http://www.apache.org/licenses/LICENSE-2.0.html" class="externalLink" title="License">
+          <span class="none"></span>
+        License</a>
+            </li>
+                
+      <li>
+  
+                          <a href="http://www.apache.org/foundation/sponsorship.html" class="externalLink" title="Sponsorship">
+          <span class="none"></span>
+        Sponsorship</a>
+            </li>
+                
+      <li>
+  
+                          <a href="http://www.apache.org/foundation/thanks.html" class="externalLink" title="Thanks">
+          <span class="none"></span>
+        Thanks</a>
+            </li>
+                
+      <li>
+  
+                          <a href="http://www.apache.org/security/" class="externalLink" title="Security">
+          <span class="none"></span>
+        Security</a>
+            </li>
+            </ul>
+                
+                    
+                
+          <hr />
+
+           <div id="poweredBy">
+                            <div class="clear"></div>
+                            <div class="clear"></div>
+                            <div class="clear"></div>
+                            <div class="clear"></div>
+                             <a href="http://maven.apache.org/" title="Built by Maven" class="poweredBy">
+        <img class="builtBy" alt="Built by Maven" src="../images/logos/maven-feather.png" />
+      </a>
+                  </div>
+          </div>
+        </div>
+        
+                
+        <div id="bodyColumn"  class="span10" >
+                                  
+            <!-- Copyright 2002-2004 The Apache Software Foundation
+
+  Licensed under the Apache License, Version 2.0 (the "License");
+  you may not use this file except in compliance with the License.
+  You may obtain a copy of the License at
+
+      http://www.apache.org/licenses/LICENSE-2.0
+
+  Unless required by applicable law or agreed to in writing, software
+  distributed under the License is distributed on an "AS IS" BASIS,
+  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+  See the License for the specific language governing permissions and
+  limitations under the License. --> 
+   
+  	<div class="section">
+<h2><a name="Introduction"></a>Introduction</h2>
+      
+<p>
+      	This document summarizes the Woden decision making and development processes. It is expected that this
+      	document will be useful to 
+      </p>
+      
+<ol style="list-style-type: decimal">
+      	
+<li>Hold current committers accountable to the established Woden processes</li>
+      	
+<li>Assist new contributors in getting up-to-speed with the Woden development processes 
+      		in order to ensure all Woden contributors are doing things the Woden way and more 
+      		generally the Apache way</li>
+      	
+<li>Provide a clear view of the way in which Woden is developed for the Open Source community</li>
+      </ol>
+    </div>
+    
+<div class="section">
+<h2><a name="Open_Development"></a>Open Development</h2>
+      
+<p>
+      	Apache Woden is an Open Source project and the development of Woden is therefore being conducted 
+      	in an open fashion. This theme should be evident
+      	as you read through this guide of the Woden decision making and development processes.
+      	At a high level what Open development means is that the entire development process of Woden is open to the
+      	community. Nothing is kept behind closed doors and information is readily available via the Woden
+      	Web site, mailing list, and wiki. The key here is transparency. If you (that's right, YOU) think the
+      	Woden development team is not being transparent it is your right to identify in what way we are not
+      	being transparent and hold us accountable to 
+      	<a class="externalLink" href="http://incubator.apache.org/learn/theapacheway.html">The Apache Way</a>.
+      </p>
+    </div>
+    
+<div class="section">
+<h2><a name="Project_Status"></a>Project Status</h2>
+      
+<p>
+      	Woden's status is currently available from a number of sources:
+      </p>
+      
+<ul>
+      	
+<li><a class="externalLink" href="http://wiki.apache.org/ws/FrontPage/BoardReports">Apache Web Service Project board reports</a>. Reports are currently produced every 3 months.</li>
+      	
+<li><a class="externalLink" href="http://wiki.apache.org/incubator/">Apache Incubator board reports</a>. Reports are currently produced every 3 months.</li>
+      	
+<li><a class="externalLink" href="http://incubator.apache.org/projects/woden.html">Woden Incubation Status File</a></li>
+      	
+<li><a href="../">Woden Web site</a></li>
+      	
+<li><a href="../mailinglists.html">woden-dev mailing list posts</a></li>
+      </ul>
+    </div>
+    
+<div class="section">
+<h2><a name="Project_Discussion_and_Communication"></a>Project Discussion and Communication</h2>
+      
+<p>
+      	All project wide communication is done in the open. This is not to suggest that one-on-one conversations
+      	amoung Woden committers and contributors is not allowed. This type of conversation is extremely valuable to
+      	the project's development and is encouraged. However, when anything other than a trivial decision is to be 
+      	made it must be done in the presence of the Woden community.
+      </p>
+      
+<p>
+      	There are 3 methods of communicating openly with the Woden development team and community:
+      </p>
+      
+<ol style="list-style-type: decimal">
+      	
+<li>the woden-dev mailing list</li>
+      	
+<li>the weekly public status telecons</li>
+      	
+<li>IRC</li>
+      </ol>
+    </div>
+    
+<div class="section">
+<h2><a name="Development_Process"></a>Development Process</h2>
+      
+<p>
+      	Woden follows a milestone develoment process. The key to milestone development is that there are a number
+      	of milestone defining criteria specified at the beginning of the milestone process. The milestone can only
+      	be declared once those milestone defining criteria are met. For example, in Woden M8 the priority 1 defining
+      	criteria are that Woden must pass all 'good' and 'bad' test cases in the WSDL 2.0 test suite.
+      </p>
+      
+<p>
+      	Woden milestone plans are communicated through the woden-dev mailing list and posted to the 
+      	<a href="1.0/milestoneplan.html">Woden Web site</a>. In addition, all plan items are recorded in Jira,
+      	Woden's bug tracking system.
+      </p>
+      
+<p>
+      	The Woden milestone planning process is an Open process. Woden takes into account the needs of adopter,
+      	like Apache Axis2, when planning. Please communicate requirements via Jira and the woden-dev list.
+      </p>
+    </div>
+    
+<div class="section">
+<h2><a name="Bug_Tracking_and_Work_Items"></a>Bug Tracking and Work Items</h2>
+      
+<p>
+      	All bugs and work items are stored in <a href="../issue_tracking.html">Jira</a>. It is a Woden best 
+      	practice to associate a Jira entry with every code change.
+      </p>
+    </div>
+    
+<div class="section">
+<h2><a name="Source_Code"></a>Source Code</h2>
+      
+<p>
+      	Woden uses Subversion (SVN) for source control and all Woden code is stored in the 
+      	<a href="../version_control.html">Woden SVN repository</a>. See the &quot;SVN Client Configuration&quot; section
+      	at this link for action required to handle EOL characters in a platform-neutral way.
+      </p>
+      
+<p>
+      	All code developed as part of Woden is licensed under the Apache Software License v2.0 (ASL v2.0). All
+      	Woden source files must include the Apache boilerplate at the top of the file:
+      </p>
+      
+<p>
+<tt>/**</tt><br />
+<tt>&#160;* Licensed to the Apache Software Foundation (ASF) under one or more</tt><br />
+<tt>&#160;* contributor license agreements.  See the NOTICE file distributed with</tt><br />
+<tt>&#160;* this work for additional information regarding copyright ownership.</tt><br />
+<tt>&#160;* The ASF licenses this file to You under the Apache License, Version 2.0</tt><br />
+<tt>&#160;* (the &quot;License&quot;); you may not use this file except in compliance with</tt><br />
+<tt>&#160;* the License.  You may obtain a copy of the License at</tt><br />
+<tt>&#160;* </tt><br />
+<tt>&#160;*&#160;&#160;&#160;&#160;&#160;http://www.apache.org/licenses/LICENSE-2.0 </tt><br />
+<tt>&#160;* </tt><br />
+<tt>&#160;* Unless required by applicable law or agreed to in writing, software </tt><br />
+<tt>&#160;* distributed under the License is distributed on an &quot;AS IS&quot; BASIS, </tt><br />
+<tt>&#160;* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. </tt><br />
+<tt>&#160;* See the License for the specific language governing permissions and </tt><br />
+<tt>&#160;* limitations under the License.</tt><br />
+<tt>&#160;*/</tt>
+      </p>
+      
+      
+<p>
+      	<b>Woden Java coding conventions</b>
+      </p>
+      
+<p>
+        Woden uses common Java coding conventions. The main reason Woden needs an agreed set of coding conventions
+        is to avoid different auto-formatting results when using IDEs like Eclipse and IDEA. If different code 
+        formatting rules are applied to a file via auto-formatting, then reformatting changes may be made along 
+        with any functional changes. If both types of code change are committed to the repository at the same time, 
+        it can be difficult to identify the functional changes from a 'diff' of the file.
+      </p>
+      
+<p>
+        To avoid this problem, the Woden project has 2 rules about coding conventions:
+      </p>
+      
+<ol style="list-style-type: decimal">
+      
+<li>
+        Use the agreed set of code formatting conventions, described below.
+      </li>
+      
+<li>
+        Don't include auto-reformatting changes and other changes in the same commit. 
+        Commit them separately, but close together to avoid merge conflicts. 
+        If you need to auto-reformat and apply a lot of new function, warn other developers about the files you're 
+        working on, then auto-reformat and commit to establish the no-op baseline, then apply your functional 
+        changes and commit.
+      </li>
+      </ol>
+      
+      
+<p>
+        <b>Eclipse code formatter default settings</b>
+      </p>
+      
+<p>
+        Use the default code formatting provided with Eclipse 3.3, with one exception - the max line length should 
+        be 100 instead of 80. A subset of the most notable conventions (i.e. the ones that have caused us the most 
+        auto-reformatting problems) are described below. (TODO - check if there's a way to export these settings).
+      </p>
+      
+<p>
+        To access these settings in Eclipse 3.3 navigate to menu Window-&gt;Preferences-&gt;Java-&gt;Code Style-&gt;Formatter. 
+      </p>
+      
+<ul>
+      
+<li>click the 'Edit' button to see the settings on tabbed pages</li>
+      
+<li>on the 'Line Wrapping' and 'Comments' tabs, change the Max Line Length from 80 to 100</li>
+      </ul>
+      
+      
+<p>
+        <b>Indentation</b>
+      </p>
+      
+<p>Tab Policy - 4 spaces (not Tab character).</p>
+      
+<p>Indentation - 4 spaces for each indent.</p>
+      
+<p>What to indent;</p>
+      
+<ul>
+      
+<li>declarations within class body</li>
+      
+<li>statements within method/constructor body</li>
+      
+<li>statements within blocks (if/else, case, loops)</li>
+      </ul>
+      
+      
+<p>
+        <b>Braces</b>
+      </p>
+      
+<p>
+        Opening brace '{' on the same line and closing brace '}' with same indentation as the statement the block 
+        applies to.
+      </p>
+      
+<p>
+        Example:
+      </p>
+      
+<div class="source"><pre class="prettyprint">
+        while(loop_condition) {
+            if(some_condition) {
+                ...
+            } else if(other_condition) {
+                ...
+            } else {
+                break;
+            }
+            ...
+        }
+      </pre></div>
+      
+      
+<p>
+        <b>New Lines</b>
+      </p>
+      
+<p>
+        Keep 'else if' on one line.
+      </p>
+      
+<p>
+        Example:
+      </p>
+      
+<div class="source"><pre class="prettyprint">
+          } else if(other_condition) {
+      </pre></div>
+      
+      
+<p>
+        <b>Line Wrapping</b>
+      </p>
+      
+<p>
+        Max line length (wrap after) 100 chars.<br />
+        Indentation for wrapped lines is 2 indents (e.g. 8 spaces).
+      </p>
+      
+      
+<p>
+        <b>Accessor method names</b>
+      </p>
+      
+<p>
+        Use 'get' / 'set' prefix for public accessor methods (e.g. <tt>getNamespace()</tt>, 
+        <tt>setNamepsace(URI)</tt>).<br />
+        Use 'is' prefix for getters that return booleans (e.g. <tt>isValid()</tt>).
+      </p>
+      
+      
+<p>
+        <b>Comments</b>
+      </p>
+      
+<p>
+        Do not auto-reformat existing comments, but note the max line convention above (100 chars).
+      </p>
+      
+<p>
+        Use Javadoc comments for all public/protected API class, method and field declarations. For example;
+      </p>
+      
+<ul>
+      
+<li>the class declaration for <tt>org.apache.woden.wsdl20.Binding</tt></li>
+      
+<li>the method declaration for <tt>org.apache.woden.wsdl20.Binding.getInterface()</tt></li>
+      
+<li>the static constant <tt>org.apache.woden.WSDLReader.FEATURE_VERBOSE</tt></li>
+      </ul>
+      
+<p>
+        Use Javadoc comments for all public/protected implementation class, method and field declarations. For example;
+      </p>
+      
+<ul>
+      
+<li>content of <tt>.internal.</tt> packages, such as <tt>org.apache.woden.internal.wsdl20.*</tt></li>
+      </ul>
+      
+<p>
+        When implementing or overriding API methods, use the <tt>@see</tt> tag to specify the relevant method.
+        For example, for the implementation method <tt>org.apache.woden.internal.wsdl20.BindingImpl.getInterface()</tt> use:
+      </p>
+      
+<ul>
+      
+<li><tt>@see org.apache.woden.wsdl20.Binding#getInterface()</tt></li>
+      </ul>
+      
+<p>
+        For all private/package private declarations, where comments are required use non-Javadoc comments.
+      </p>
+    </div>
+    
+<div class="section">
+<h2><a name="Building"></a>Building</h2>
+        
+<p>
+        Woden defines an API and provides 2 implementations of it. One is based on the Document Object Model (DOM) 
+        and the other on the Axiom Object Model (OM).
+        </p>
+        
+<p>The Woden build produces 3 binary jar files:</p>
+        
+<ul>
+        
+<li>
+        <tt>woden-api-[version].jar</tt> - the WODEN API classes.
+        </li>
+        
+<li>
+        <tt>woden-impl-dom-[version].jar</tt> - the DOM-specific classes and any common implementation classes. 
+        </li>
+        
+<li>
+        <tt>woden-impl-om-[version].jar</tt> - the OM-specific classes and any common implementation classes.
+        </li>
+        </ul>
+        
+<p>These jar files are packaged into 2 binary distributions (as zip and tar archives):</p> 
+        
+<ul>
+        
+<li>
+        <tt>apache-woden-dom-[version].zip</tt> - contains the API and DOM jar files and the relevant jar file dependencies.
+        </li>
+        
+<li> 
+        <tt>apache-woden-om-[version].zip</tt> - contains the API and OM jar files and the relevant jar file dependencies.
+        </li>
+        </ul>
+        
+<p>
+        The Woden build also produces a source code distribution (zip and tar): 
+        </p>
+        
+<ul>
+        
+<li><tt>apache-woden-src-[version].zip</tt></li>
+        </ul>
+        
+<p>
+        Woden has <a class="externalLink" href="http://ant.apache.org/">Ant</a> and <a class="externalLink" href="http://maven.apache.org/">Maven</a> build processes.
+        The Ant build was created originally to produce the jar files and distribution archives.
+        The Maven build was introduced later to integrate the Woden build process with other
+        Apache projects that depend on Woden, like Axis2. 
+        We maintain both build processes so that developers can use the one they prefer.
+        Note however, that the Maven build just produces the 3 jar files (it does not produce the distribution archives).
+        </p>
+        
+        
+<p>
+        <b>Ant</b> uses a concept of targets to figure out what work to do when you want a certain task done,
+        they are defined inside a build.xml which is in the root of our source directory.
+        There are two main ways in which we run a target, from the command line or inside eclipse.
+        If you want to use the command line you need to download and install Ant from their download site above,
+        then you just use the command <tt>ant [targetname]</tt> to run a target called targetname.
+        If you want to use Eclipse you need to make sure you have the Ant plug-in, which should come by default
+        depending which package you downloaded, then to run a target you can use the &quot;Run As&quot; context menu on a build.xml file
+        to run it as a &quot;Ant Build&quot; which will run the default ant task or as a &quot;Ant Build...&quot; to specify which target(s) you wish to run.
+        </p>
+        
+<p>The top level ant targets we have and their uses are :-</p>
+        
+<ul>
+            
+<li>
+                <tt>buildAll</tt>
+                - Builds all Woden packages (API, DOM, and OM).
+            </li>
+            
+<li>
+                <tt>buildAndTestAll</tt>
+                - Builds all Woden packages (API, DOM, and OM) then runs all the tests as explained in the Testing section.
+            </li>
+            
+<li>
+                <tt>distBuild</tt>
+               - Builds all Woden packages (API, DOM, and OM) then creates the compressed archives for the DOM and OM distributions with dependencies.
+            </li>
+            
+<li>
+                <tt>buildAPI</tt>
+                - Builds the Woden API package.
+            </li>
+            
+<li>
+                <tt>buildDOM</tt>
+                - Builds the Woden DOM package.
+            </li>
+            
+<li>
+                <tt>buildOM</tt>
+                - Builds the Woden OM package.
+            </li>
+        </ul>
+        
+<p><br />These targets all use a common build directory to store their results in, its structure is :-</p>
+        
+<ul>
+            
+<li>
+                <tt>build/</tt>
+                - Root of the build directory.
+            </li>
+            
+<li>
+                <tt>build/classes/</tt>
+                - Classes from building the java source code.
+            </li>
+            
+<li>
+                <tt>build/dist/</tt>
+                - Zip and Tar files of complete distributions in the
+                form apache-woden-[src/dom/om]-[version].[zip/.tar.gz].
+            </li>
+            
+<li>
+                <tt>build/test/</tt>
+                - Test results from Junit tests.
+            </li>
+            
+<li>
+                <tt>build/jar/</tt>
+                - Jar files for each package in for form
+                woden-[api/dom/om]-[version].jar .
+            </li>
+            
+<li>
+                <tt>build/JavaDoc/</tt>
+                - Java Doc pages for all the java classes.
+            </li>
+        </ul>
+        
+        
+<p>
+        <b>Maven</b> uses a set of conventions to simplify the build and deployment process and uses a concept of goals to figure out
+        what needs to be done. The layout of the project is defined in pom.xml files, each of which specifies one distribution.
+        In Woden we have three main distributors so have four pom.xml files, one in the root source directory
+        and one in each of the woden-api, woden-dom and woden-om sub directories. To use Maven you need to 
+        <a class="externalLink" href="http://maven.apache.org/download.html">download</a> it, 
+        then run one of the maven goals with <tt>mvn [goal]</tt>.
+        If you run these from the Woden root directory the goal will be applied all three distributions.
+        </p>
+        
+<p>The main goals you will use are :-</p>
+        
+<ul>
+            
+<li><tt>compile</tt> - Compiles all three distributions.</li>
+            
+<li><tt>test</tt> - Compiles then tests all three distributions.</li>
+            
+<li><tt>package</tt> - Compiles, tests then packages all three distributions.</li>
+        </ul>
+        
+<p><br />Woden's Maven build uses the following directory structure :-</p>
+        
+<ul>
+            
+<li><tt>/</tt> - Root source folder with the pom.xml linking all three distributions.</li>
+            
+<li><tt>/woden-api</tt> - Woden API distribution, runs Maven goals on just the API java source.</li>
+            
+<li><tt>/woden-dom</tt> - Woden DOM distribution, runs Maven goals on the DOM and Common java source.</li>
+            
+<li><tt>/woden-om</tt> - Woden OM distribution, runs Maven goals on the OM and Common java source.</li>
+        </ul>
+    </div>
+    
+<div class="section">
+<h2><a name="Testing"></a>Testing</h2>
+        
+<p>
+        There are 2 test suites for Woden. The <b>Woden JUnit Test Suite</b> provided with Woden tests the 
+        Woden API and functionality of the Woden framework (configuration, factory, reader, error handling, etc). 
+        The <b>W3C WSDL 2.0 Test Suite</b> tests Woden's compliance with the WSDL 2.0 Recommendation 
+        (i.e. its WSDL 2.0 spec compliance).
+        </p>
+        
+<p>
+        Both of these test suites <i>should</i> be run to test Woden thoroughly. 
+        It's not enough just to run the Woden JUnit tests, because while this suite will test some of the Woden framework 
+        implementation and that Woden implements all of its API, it will not perform a complete WSDL 2.0
+        functional test. That's the job of the W3C WSDL 2.0 Test suite. 
+        Both test suites <i>must</i> be run <i>before</i> committing code to the repository.
+        Code contributions submitted by non-committers as JIRA patches should also be tested against both test suites.
+        </p>
+        
+<p>
+        The Woden JUnit test suite should test the entire Woden API. It should invoke every API method at least once.
+        So for any additions or changes to the API, the Woden JUnit test suite must be updated accordingly.
+        For any non-WSDL functionality added or changed in the Woden implementation(s), appropriate test cases should
+        also be included in the JUnit test suite where appropriate. 
+        </p>
+        
+<p>
+        (TODO - maybe split the JUnit test
+        suite so that an API-only suite exists for use by projects that want to create their own implementation
+        of the Woden API).
+        </p>
+        
+<p>
+        The Woden JUnit test cases <i>must be written using the Woden API</i> (i.e. the correct Woden programming
+        model), unless it's absolutely necessary to exercise the implementation class methods directly for a given
+        test case. This will ensure that the Woden development team can change the implementation at any point 
+        without major impact on the test suite. On several occassions in the past, we have had
+        to do significant, time-consuming rework on the test suite to fix compile breaks introduced when the 
+        implementation changed, because Woden developers had used the implementation classes directly when writing
+        test cases.
+        Our initial reasons for this were &quot;we know the code, so it's okay&quot;, but as we've learnt, getting Woden 
+        client code to work is not the same as keeping it working. We expect Woden users to use the API only, so 
+        our test suite should set the right example.
+        </p>
+        
+<p>
+        The W3C WSDL 2.0 Test Suite is complete for the 'good' WSDL test cases. It should now have WSDL test cases
+        that provide full coverage of what <i>is</i> allowed by the WSDL 2.0 specification.
+        The test suite does not yet fully cover the 'bad' WSDL test cases. That is, it does not yet have WSDL test
+        cases for every <i>assertion</i> specified by the WSDL 2.0 specification.
+        All of Woden's WSDL 2.0 functionality (i.e. handling good WSDL and detecting bad WSDL) must be tested against
+        the W3C WSDL 2.0 Test Suite.
+        If a new WSDL 2.0 test case is needed to test some WSLD 2.0 functionality in Woden, Woden developers should
+        create the required test case and then contribute it as a patch to the 
+        <a class="externalLink" href="http://dev.w3.org/cvsweb/2002/ws/desc/">W3C WSDL 2.0 CVS repository</a>.  
+        The patch can be submitted via the <a class="externalLink" href="http://www.w3.org/Bugs/W3C">W3C Bugzilla system</a>
+        (select the 'WSDL' category when creating a new bug report).
+        </p>
+        
+<p>
+        <b>Woden JUnit Tests</b> are located in the test/ directory which is structured to mirror the src/ directory
+        for the parts of code tests are written for. There are two ways these can be run; either inside Eclipse or directly from Ant.
+        </p>
+        
+<p>Inside Eclipse the JUnit test(s) can be run by selecting &quot;JUnit Test&quot; in the &quot;Run As&quot; context menu for one test, whole packages,
+        or the entire test folder. Then the tests results with any error messages and stack traces will be displayed in the JUnit panel. 
+        You can also debug JUnit tests from inside Eclipse by selecting the &quot;JUnit Test&quot; from the &quot;Debug As&quot; context menu.
+        </p>
+        
+<p>You can also run the JUnit tests using Ant from the command line or inside Eclipse as described in the
+        <a href="#Building">building</a> section above. The Ant script is the build.xml file in the Woden project's root directory.
+        This script has three test targets which each run a particular subset of the Woden JUnit tests. 
+        </p>
+        
+<ul>
+           
+<li><tt>runAllJUnitTests</tt> - This runs all of the JUnit tests for both the DOM and OM implementations of Woden.</li>
+           
+<li><tt>runOMTests</tt> - This runs all the JUnit tests for the OM implementation.</li>
+           
+<li><tt>runDOMTests</tt> - This runs all of the JUnit tests for the DOM implementation.</li>
+        </ul>
+        
+<p>
+        These Ant targets produce an HTML report of the tests results in the file build/test-results/(24 hour)_(minute)_(second)/junit-noframes.html.
+        </p>
+        
+<p>
+        <b>W3C WSDL 2.0 Test Suite</b> is a collection of WSDL 2.0 documents used to test that a WSDL 2.0 processor complies with 
+        the W3C WSDL 2.0 Recommendation. The processor must successfully process all of the documents in the test suite to demonstrate its 
+        compliance. Each WSDL document represents a test case for some aspect of the WSDL 2.0 spec. These include <i>good</i> test cases, 
+        containing valid WSDL which collectively demonstrate all of the types of WSDL 2.0 syntax permitted by the spec. They also include 
+        <i>bad</i> test cases, containing invalid WSDL which violates one of the WSDL 2.0 assertions defined in the spec. There should be at
+        least one <i>bad</i> test case for each assertion, but the <i>bad</i> test suite is not yet complete. The Woden project will contribute
+        further assertion test cases to the W3C as development of Woden's WSDL validation continues.
+        </p>
+        
+<p> 
+        To demonstrate its spec-compliance, a WSDL 2.0 processor should correctly parse all <i>good</i> WSDL documents and should detect 
+        the correct assertion violation for all <i>bad</i> WSDL documents. The W3C WSDL 2.0 test framework can check that the processor
+        complies in this way. The WSDL 2.0 processor simply needs to capture its results from processing the test suite in some XML formats
+        that the W3C WSDL 2.0 test framework will evaluate against baseline XML results. It will then generate a compliance report based
+        on this comparison.  
+        </p>
+        
+<p>
+        The Woden code tree is setup to facilate using the W3C WSDL 2.0 test suite in this way. It uses ANT scripts to download
+        the W3C WSDL 2.0 test suite (the good and bad WSDL documents), run Woden against this test suite and generate the Woden result files,
+        then copy the result files to your local copy of the W3C project that contains the WSDL 2.0 test framework. This W3C project 
+        is a CVS project called 'desc', short for Description - more on this later. The last step is then to run an ANT script in the 'desc' 
+        project to evaluate Woden's results and generate the HTML reports which compare Woden's results to the W3C baseline. 
+        </p>
+        
+<p>
+        The official versions of these compliance reports are published on the 
+        <a class="externalLink" href="http://dev.w3.org/2002/ws/desc/test-suite/Dashboard.html">WSDL 2.0 Interop Dashboard</a>, where the 
+        <i>Component Model Test Results</i> show the results for the <i>good</i> WSDL test suite and the 
+        <i>Validation Test Results</i> show the results for the <i>bad</i> WSDL test suite.
+        </p>
+        
+<p>
+        Here are the steps to run Woden against the W3C WSDL 2.0 Test suite:
+        </p>
+        
+<ol style="list-style-type: decimal"> 
+        
+<li>
+        You need to have run Ant to build Woden as described in the <a href="#Building">building</a> section above.
+        This will not only build the Woden jar's to test against, but it will also ensure that the W3C WSDL 2.0 test suite 
+        has been downloaded by the <tt>getW3cWsdl20</tt> target in the main build.xml script.
+        </li>
+        
+<li>
+        Run the default target in ant-test/build.xml. This will generate the xml files containing the Woden results.
+        The <i>good</i> test suite result can be found in the ant-test/results/ directory or zipped in the ant-test/test-suite-results.zip
+        file and the <i>bad</i> test suite results are in the ant-test/validation-results.xml file.
+        </li>
+        
+<li>
+        Checkout the 'desc' project from the W3C WSDL 2.0 CVS repository to your local development environment
+        (:pserver:anonymous@dev.w3.org:/sources/public/2002/ws/desc). 
+        Ensure the 'desc' project is in the same local directory as the woden project (e.g.
+        /workspace/woden and /workspace/desc).
+        The WSDL 2.0 test suite and test framework are located in /desc/test-suite directory.
+        </li>
+        
+<li>
+        Run the &quot;copyResultsToW3C&quot; target in Woden's ant-test/build.xml script. This will copy the ant-test/test-suite-results.zip and 
+        ant-test/validation-results.xml files from the woden project to the test-suite/results/downloads/Woden directory in the 
+        'desc' project, then extract these files to the test-suite/results/Woden directory. 
+        </li>
+        
+<li>
+        Run the targets &quot;canonicalize-Woden&quot;, &quot;evaluate-Woden&quot;, &quot;Interchange.html&quot; and &quot;Validation.html&quot; in the test-suite/results/build.xml 
+        script in the 'desc' project. These will prepare the Woden results for baseline comparison, do the baseline comparison, then
+        generate the <i>good</i> and <i>bad</i> test suite reports. 
+        </li>
+        
+<li>
+        View the reports in test-suite/results/Interchange.html and test-suite/results/Validation.html and check that no regressions
+        have been introduced by the latest Woden build being tested.
+        </li>
+        </ol>
+        
+<p>
+        Periodically the W3C WSDL 2.0 Interop Dashboard is republished, using the Woden result files in the ant-test/ directory
+        in the Woden repository. Therefore, these files should be committed periodically to reflect the up-to-date Woden results.
+        (these ant-test/ files include the test-suite-results.zip and validation-results.xml files mentioned above).
+        </p>
+    </div>
+    
+<div class="section">
+<h2><a name="Release_Process"></a>Release Process</h2>
+      
+<p>
+      	The Woden release process involves many steps and checks. To keep compliant with Apache process requirements
+      	of WS and incubator projects it is important that it is followed.
+      </p>
+      
+<ol style="list-style-type: decimal">
+      	
+<li>
+      		Build and test the current Woden release candidate. The 'buildDist' ANT target will 
+      		create the binary and source archives  (.zip, .tar.gz, .tar.bz2) and the hash digests 
+      		(md5, sha1) for each archive file.
+		</li>
+		
+<li>
+			Sign the binary and source archives, which will create a .asc signature file for each archive file.<br />
+			<br />
+			e.g.<br />
+			<tt>gpg --armor --output apache-woden-incubating-1.0M7a.zip.asc --detach-sig apache-woden-incubating-1.0M7a.zip</tt><br />
+			<tt>gpg --verify apache-woden-incubating-1.0M7a.zip.asc apache-woden-incubating-1.0M7a.zip</tt>
+		</li>
+		
+<li>
+			Upload the binary and source archives and their hash digests and signature files to 
+			people.apache.org into some directory path under your public_html directory so that you can include a 
+			link to the files in the [VOTE] request email. Also upload the KEYS file and release-notes.html 
+			from [woden root] and junit-noframes.html from the [woden root]/build/test-results/html directory.
+			Make sure you chmod the file permissions so others can read them (e.g. 744).<br />
+			<br />
+			e.g.<br />
+			<tt>[jkaputin home]/public_html/woden/milestones/1.0M7a-incubating</tt><br />
+			...is accessible at url...<br />
+			<a class="externalLink" href="http://people.apache.org/~jkaputin/woden/milestones/1.0M7a-incubating/">http://people.apache.org/~jkaputin/woden/milestones/1.0M7a-incubating/</a><br />
+			<br />
+			Note, because Woden is in incubation you must not upload these files to the Woden project on the 
+			file server until the Incubator PMC vote has passed....so you upload to your own space, then move 
+			to Woden space after voting.
+		</li>
+		
+<li>
+			Check that you can download/unzip the files.<br />
+			Create hash digests of the downloaded archives and check them against the downloaded hash files.<br />
+			<br />
+			e.g.<br />
+			<tt>$ dir</tt><br />
+			<tt>apache-woden-incubating-1.0M7a.zip  apache-woden-incubating-1.0M7a.zip.MD5</tt><br />
+			<tt>$ cat apache-woden-incubating-1.0M7a.zip.MD5</tt><br />
+			<tt>3009d6f6fea14b7536c22028944bb03a</tt><br />
+			<tt>$ md5sum apache-woden-incubating-1.0M7a.zip</tt><br />
+			<tt>3009d6f6fea14b7536c22028944bb03a *apache-woden-incubating-1.0M7a.zip</tt>
+		</li>
+		
+<li>
+			Post a vote request email to woden-dev asking devs to vote on the proposed M7b release. 
+			Post the voting results.<br />
+			When posting a vote request to any mailing list, start the subject line with the eye-catcher [VOTE].
+		</li>
+		
+<li>
+			If woden-dev vote successful, post to general@ws.apache.org asking the WSPMC to approve a Woden 
+			release. Post the voting results.<br />
+			When posting a vote request to any mailing list, start the subject line with the eye-catcher [VOTE].
+		</li>
+		
+<li>
+			If WSPMC vote successful, post to IPMC at general@incubator. Be specific about timeframe (usually 3 days).
+			Post the results afterwards. Success criteria is at least 3 binding IPMC votes (i.e. 3 x +1 from IPMC 
+			members). Remember, Dims, Sanjiva and Paul F are IPMC members as well as WSPMC.<br />
+			When posting a vote request to any mailing list, start the subject line with the eye-catcher [VOTE].
+		</li>
+		
+<li>
+			If IPMC vote successful, move all the release files from your public_html directory to the Woden 
+			file space on people.apache.org.<br />
+			<br />
+			<tt>cd /www/people.apache.org/dist/ws/woden</tt><br />
+			<tt>cd milestones</tt><br />
+			Create a new directory for the release (e.g. /1.0M7a-incubating)<br />
+			Move the release files to this new directory.<br />
+			Copy the file release-notes.html to a new file called README.html in this new directory 
+			(this will ensure the release notes are displayed after the list of files, when this 
+			directory is accessed via the web).<br />
+			<br />
+			e.g.<br />
+			<tt>/www/people.apache.org/dist/ws/woden/milestones/1.0M7a-incubating</tt><br />
+			...will be accessible via url...<br />
+			http://people.apache.org/dist/ws/woden/milestones/1.0M7a-incubating/
+		</li>
+		
+<li>
+			Once again, check that:
+			
+<ul>
+				
+<li>the file permissions are set correctly</li>
+				
+<li>you can download/unzip the files</li>
+				
+<li>the downloaded hash digests are correct</li>
+			</ul>
+		</li>
+		
+<li>
+			Update the Woden web site (add the release download to the Builds page and add a News item 
+			announcing the release to the Woden home page).
+		</li>
+		
+<li>
+			Post a release announcement to woden-dev, general@ws and general@incubator.
+		</li>
+		
+<li>
+			Final step, which Axis2 folks will do, it to upload Woden release binary jar to a maven 
+			repository...I think Dims can upload to ws.zones.
+		</li>
+	</ol>
+	
+<p>
+ 		Some example mailing list posts for reference:
+ 	</p>
+	
+<p>
+		<a class="externalLink" href="http://mail-archives.apache.org/mod_mbox/ws-woden-dev/200704.mbox/%3c4c2ae8f80704160812h30e87b93je6e5d52607780265@mail.gmail.com%3e">[VOTE] woden-dev and WSPMC</a>
+	</p> 
+	
+<p>
+		<a class="externalLink" href="http://mail-archives.apache.org/mod_mbox/ws-woden-dev/200704.mbox/%3c4c2ae8f80704170847r5f2440dbrc800fabd2298577b@mail.gmail.com%3e">[RESULT]</a>
+	</p>
+	
+<p>

[... 57 lines stripped ...]


Mime
View raw message