Hi Xavier,

There is a bug in our validator manager configuration which prevented WST builder invoking our validators for every resource of the project when you click on Project>Validate
I created an issue for that - https://issues.jboss.org/browse/JBIDE-12634
Fixed in trunk.

On 09/18/2012 05:38 AM, Xavier Coulon wrote:

Hi Alexey,

I'm trying to get the following behavior with the common-validator framework, but now I'm stuck: when I do "Project>Validate", I would like to trigger a full project validation, ie, I's expect my JaxrsMetamodelValidator#validateAll(ContextValidationHelper, IReporter, Set<IProject>) being called.

Instead of this, the ValidatorManager calls the JaxrsMetamodelValidator#validate(Set<IFile>, IProject, ContextValidationHelper, IProjectValidationContext, ValidatorManager, IReporter) method with the first resource found of my project, and after that, the ValidatorManager is never called again because the org.eclipse.wst.validation.Validator$V1#shouldSkipValidator(IResource, ValOperation)prevents further resource validation, although there are many more resources to validate (java files, xml files, folders, etc.).

And from what I understood of the Validator, the only way to have the JaxrsMetamodelValidator#validateAll(..) method being called would be validate the 'else if' condition in the following statement:

if((!validationHelper.isClasspathAffected() && (!changedFiles.isEmpty() || validationHelper.getURIs().length > 0))) {

status = validate(changedFiles, validationHelper, reporter, rootProjects);

} else if(!validationContextManager.getRegisteredFiles().isEmpty()) {

validationContextManager.clearAllResourceLinks(rootProjects);

status = validateAll(validationHelper, reporter, rootProjects);

}

How could I have a full validation from the 'Project>Validate' menu action ?

Thanks.

Best regards,

/Xavier

On Sep 17, 2012, at 9:50 PM, Alexey Kazakov wrote:

V2 has some disadvantages which are critical for our validators.
For example in case of incremental validation V2 validtor will be called for every changed resource. That's not ok for our validators. We need to get a full list of all the changed resources before we start to validate them.
WST validation V2 is too restricted and not so flexible as V1.


On 09/17/2012 12:34 PM, Rob Cernich wrote:

Cool.  Plain old validator framework supports this as well: ValidationResult.setDependsOn().

Of course, this is version 2 of the validator framework.

Best,

Rob

----- Original Message -----

BTW, we use KB for savings links between model artifacts which are

used

in incremental validation. Not for saving problem markers.

Suppose you have some relation between resource A and B. And if A is

changed then you should re-validate B too.

We save such links in KB project so we don't have to rebuild them

after

every Eclipse restart.

On 09/17/2012 12:15 PM, Rob Cernich wrote:

Hey Alexey,

If you're using the plain old WST validation framework, just make

sure your markers are "persistent" and extend

org.eclipse.wst.validation.problemmarker (and problemmarker2, if

applicable) and that you're validator is enabled for build.  Also,

make sure your include/exclude rules are configured appropriately.

Best,

Rob

----- Original Message -----

Alexey, Rob,

Thanks for your replies. I understand that our validators (JAX-RS

is

now part of them) are called during wst validation, and that I

shouldn't trigger costly validation of all projects for the sole

purpose of JAX-RS. I'll look at the options you suggested

(explicit

call of validateAll vs state saving/using KB)

Thanks

Best regards,

/Xavier

On Sep 17, 2012, at 7:24 PM, Alexey Kazakov wrote:

We don't call our validators (CDI, EL, JSF, Seam, ...) directly.

These validators are registered in plugin.xml's and managed by

org.jboss.tools.common.validation.ValidatorManager

This manager is called by eclipse wst validation builder.

You could call ValidatorManager.validateInJob(IValidationContext

helper, IReporter reporter) with proper helper

(validationHelper.getValidationContextManager().getRegisteredFiles()

should be empty) but in this case you will start all the

validators

to validate the entire projects! So it's not the way you are

looking

for.

So you have two options here:

1. Call your validator directly validateAll(..) when you need it

w/o

builder

or

2. Save the validation state between sessions and relay on wst

builder/ValidationManager.

In CDI/JSF/Seam tools we use KB project framework to save states.

This framework is not a part of common-validation framework, so

it's

up to you if you want to use KB project or your own solution to

save

the state.

On 09/17/2012 08:27 AM, Xavier Coulon wrote:

Never mind, I found the reason why the validate(..) method is

called:

some xml files need to be checked. They are not part of the

'changedFiles', but they are returned by the

validationHelper.getURIs() method.

So, instead, I'd like to ask: how can I force the validation

framework to trigger a validateAll() at workbench startup ?

Thanks.

Best regards,

/Xavier

On Sep 17, 2012, at 4:49 PM, Xavier Coulon wrote:

Hi !

The JAX-RS tooling is now aligned on the CDI tooling and relies

on

the common-validation plugin to validate the JAX-RS elements.

So far, so good, but I have this issue that I'd like to solve:

at

workbench start-up, the method

public IStatus validate(Set<IFile> changedFiles, IProject

project,

ContextValidationHelper validationHelper,

IProjectValidationContext context, ValidatorManager manager,

IReporter reporter) throws ValidationException

of my validator is called, but with an empty set of

'changedFiles'.

Wouldn't it make more sense to call the

public IStatus validateAll(IProject project,

ContextValidationHelper

validationHelper,

IProjectValidationContext validationContext, ValidatorManager

manager, IReporter reporter)

throws ValidationException

method instead ?

I can workaround that and call validateAll(..) when

changesFiles.isEmpty() in the validate(..) method call, but I

don't

think it's the best approach.

WDYT ?

Thanks.

Best regards,

/Xavier

_______________________________________________

jbosstools-dev mailing list jbosstools-dev@lists.jboss.org

https://lists.jboss.org/mailman/listinfo/jbosstools-dev

_______________________________________________

jbosstools-dev mailing list

jbosstools-dev@lists.jboss.org

https://lists.jboss.org/mailman/listinfo/jbosstools-dev

_______________________________________________

jbosstools-dev mailing list

jbosstools-dev@lists.jboss.org

https://lists.jboss.org/mailman/listinfo/jbosstools-dev