<html>
<head>
<title>Validation Framework Overview</title>
</head>
<body>
<p>A framework for calling validators that are build based.</p>
<h2>Approach</h2>
<p>In WTP 3.0 a new validation framework has been added. This was developed at 
the request of validator owners and end users. To ease the transition to this 
new framework, that approach that has been taken is to support both the old and 
the new frameworks for a while. This means that the old validators work exactly 
like they used to. They can still plug into the old framework and will continue 
to be run by the old framework. This allows validator owners to migrate at their 
own pace.</p>
<p>For validator owners that wish to exploit the new framework, it has been 
designed n such a way to minimize the transition from the old framework to the 
new framework. There is a new extension point that needs to be specified, and a 
new abstract class that needs to be extended.</p>
<h3>Benefits</h3>
<p>What benefits does the new framework have to offer? Or asked another way, as 
a validator owner, why would I want to switch?</p>
<h4>Performance</h4>
<h5>Tuning</h5>
<p>The main reason for creating a new framework was to improve performance. As 
more and more validators are added, validation is consuming a bigger slice of 
the resources that it takes to perform a build.</p>
<p>The best performance improvement is eliminating unnecessary work. We 
eliminate work, by providing significantly more tuning options. Validation 
owners can tune which resources they are called on. This is done through the use 
of filter rules. These filter rules are grouped into inclusion and exclusion 
groups. If you have multiple inclusion groups they are &quot;anded&quot; together, meaning 
that each of the inclusion groups must have at least one successful filter rule. 
Exclusion groups are used to specify what doesn't get validated. Exclusion 
groups have a higher precedence than inclusion groups. If an exclusion group 
excludes a resource than it is excluded no matter what the inclusion groups may 
say.</p>
<p>They are several different types of filter rules:</p>
<ul>
	<li><strong>File extension</strong> - Rules based on the file extension. For 
	example, include all the files with extension *.xml.</li>
	<li><strong>Folder or File name</strong> - Rules based on the folder or file 
	name. For example exclude all the resources in the build folder. File names 
	can be fully qualified, project relative names, e.g. <strong>WebContent/WEB-INF/web.xml</strong>, 
	or simple names, <strong>web.xml</strong>.</li>
	<li><strong>Project nature</strong> - Projects with certain natures can be 
	either included or excluded.</li>
	<li><strong>Facet</strong> - Projects with certain facets can be either 
	included or excluded.</li>
	<li><strong>Content Type </strong>- Resources of a particular content type 
	can be included or excluded.</li>
</ul>
<p>The filter rules and groups form the building blocks of what gets validated.
</p>
<p>In terms of tuning however, the end user has the final say. The validator 
owners specify the default filter rules and groups for their validator, but the 
end user through the use of preferences can override these settings. </p>
<h5>Caching</h5>
<p>Another way that performance is improved is through more effective caching. 
With the previous framework we were noticing that different validators would be 
opening and processing the same file, but that this would happen far enough 
apart, that caches weren't effective. Even if files were being cached, the 
second (or third, or forth, ...) open would happen far enough a means that way 
that the file would have already been evicted from the cache. In the new 
framework, the processing order is more tightly controlled. The framework calls 
the validator and tells it what to validate. This way files are processed in 
order, which means that the chance of them being a cache is much higher. Every 
validator that is interested in file A processes it, and then we move on and 
every validator that is interested in file B processes it, etc.</p>
<p>Also because state information is kept for the lifetime of the validation 
operation, validators can cache expensive operations, like model creation, that 
might be needed as part of validating several files. </p>
<h5>Job Control</h5>
<p>With the earlier framework, there were too many jobs/threads running 
concurrently. This is now more tightly controlled.</p>
<h4>Dependency Support</h4>
<p>Another new feature is dependency support. A validator can now assert that a 
resource is dependant on some other resources. For example that a XML file is 
dependant on a XSD file. Now if the XSD file changes the XML can be revalidated. 
As the user comes to trust this dependency support, they wont perform as many 
clean builds.</p>
<h4>Primary Framework</h4>
<p>This is the primary validation framework. At some point, the earlier 
framework will be deprecated and then removed. All the new investment will 
happen in this framework. </p>
<p>The framework collateral will continue to be enhanced (junit testcases, 
documentation, performance improvements, ...)</p>
</body>
</html>