You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@ws.apache.org by ve...@apache.org on 2015/07/05 14:35:56 UTC
svn commit: r1689248 [3/8] - in /webservices/website/woden-staging: ./ css/
dev/ dev/1.0/ fonts/ images/ images/logos/ images/profiles/ img/ js/ skin/
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> > <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">
- <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">
-
-
- </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"> * Licensed to the Apache Software Foundation (ASF) under one or more</span>
-<br>
-
-<span class="codefrag"> * contributor license agreements. See the NOTICE file distributed with</span>
-<br>
-
-<span class="codefrag"> * this work for additional information regarding copyright ownership.</span>
-<br>
-
-<span class="codefrag"> * The ASF licenses this file to You under the Apache License, Version 2.0</span>
-<br>
-
-<span class="codefrag"> * (the "License"); you may not use this file except in compliance with</span>
-<br>
-
-<span class="codefrag"> * the License. You may obtain a copy of the License at</span>
-<br>
-
-<span class="codefrag"> * </span>
-<br>
-
-<span class="codefrag"> * http://www.apache.org/licenses/LICENSE-2.0 </span>
-<br>
-
-<span class="codefrag"> * </span>
-<br>
-
-<span class="codefrag"> * Unless required by applicable law or agreed to in writing, software </span>
-<br>
-
-<span class="codefrag"> * distributed under the License is distributed on an "AS IS" BASIS, </span>
-<br>
-
-<span class="codefrag"> * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. </span>
-<br>
-
-<span class="codefrag"> * See the License for the specific language governing permissions and </span>
-<br>
-
-<span class="codefrag"> * limitations under the License.</span>
-<br>
-
-<span class="codefrag"> */</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->Preferences->Java->Code Style->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"> </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 ©
- 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 – 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 "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>
+<tt>/**</tt><br />
+<tt> * Licensed to the Apache Software Foundation (ASF) under one or more</tt><br />
+<tt> * contributor license agreements. See the NOTICE file distributed with</tt><br />
+<tt> * this work for additional information regarding copyright ownership.</tt><br />
+<tt> * The ASF licenses this file to You under the Apache License, Version 2.0</tt><br />
+<tt> * (the "License"); you may not use this file except in compliance with</tt><br />
+<tt> * the License. You may obtain a copy of the License at</tt><br />
+<tt> * </tt><br />
+<tt> *     http://www.apache.org/licenses/LICENSE-2.0 </tt><br />
+<tt> * </tt><br />
+<tt> * Unless required by applicable law or agreed to in writing, software </tt><br />
+<tt> * distributed under the License is distributed on an "AS IS" BASIS, </tt><br />
+<tt> * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. </tt><br />
+<tt> * See the License for the specific language governing permissions and </tt><br />
+<tt> * limitations under the License.</tt><br />
+<tt> */</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->Preferences->Java->Code Style->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 "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>
+ <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 "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 <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 "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><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 "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 <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 ...]