Re: [jbosstools-dev] Common Validation: Help needed

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