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(a)lists.jboss.org
>>>>
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>> _______________________________________________
>>> jbosstools-dev mailing list
>>> jbosstools-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>> _______________________________________________
>> jbosstools-dev mailing list
>> jbosstools-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/jbosstools-dev