docs/org.eclipse.wst.validation.doc.isv/overview.html - webtools-common/webtools.common - Git at Google

 <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.4 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>
	<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.4 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 "anded" 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>