Bugzilla – Full Text Bug Listing
| Summary: | [validation] Validation Framework: cleanup framework for API stabilization | ||
|---|---|---|---|
| Product: | [WebTools] WTP Common Tools | Reporter: | John Lanuti <jlanuti> |
| Component: | wst.validation | Assignee: | Hari Shankar <hshanka> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | ccc, chris.chiu, valentinbaciu |
| Version: | 0.7 | ||
| Target Milestone: | Future | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
Will not happen for WTP 1.0 We would like to use the Validation API framework when it is stablized and made public. We are using it to check for the dependencies of custom resource files in a faceted dynamic web project. The check is performed whenever the file is updated or a build is required. If missing dependencies are detected, we will flag warnings or errors in the error pane. This enhancement is about the old validation framework code. Starting with WTP 3.0 the majority of the effort was and will be on enhancing the new validation framework. As such, we will be minimizing the old framework development effort and focus on maintenance. |
Many method signatures are deprecated. This defect should do the following: 1. Clean up those deprecations, 2. Change the OneValidatorOperation & ValidatorSubsetOperation to throw an exception if they can't validate. Today, they just return quietly and the user has no indication that validation was not performed. 3. Move all of the internal classes into packages with the word "internal" in them. i.e., the entire "com.ibm.etools.validate.registry" package needs to be renamed to "com.ibm.etools.validate.internal.registry", and several classes were marked "deprecated" to phase them out into "internal" packages. The deprecated classes should be deleted. 4. Several places in the code have "TODO" comments or references from "ToDo" classes. The "ToDo" classes should be deleted, and any to-do work flagged by these comments or classes should be finished. 5. The ValidatorManager class should have all of its utility methods moved to the ValidationUtility class if those utility methods are meant to be public. Methods that are meant to be used only by the framework need to be moved to the InternalValidatorManager class. 6. The ValidatorManager class should, in the end, have only the suspension methods and any other methods that actually manage validation.