Re: [technology-pmc] eclipse scout and jshint

[Gunnar Wagenknecht <gunnar@xxxxxxxxxxxxxxx>]

Konstantin,

Per your definition below, would the following be a declarative API?

#1: 
/*jshint -W079 */

#2:
 /* vi: tabstop=4
 */

Also it would be interesting to know why you consider the Eclipse Findbugs plug-in a dev-time tool but the JShint not? I don't see any difference except the language they are targeting.

-Gunnar

> Am 13.10.2015 um 16:52 schrieb Konstantin Komissarchik <konstantin.komissarchik@xxxxxxxxxx>:
> 
> Gunnar,
>  
> I disagree with your assessment that there is zero additional functionality provided by these comments/annotations. These are there for a reason of improving end-user experience when jshint is installed. It is important that we do not have different treatment of a direct method invocation from a declarative comment/annotation as more and more software relies on a declarative api. Consider if your assessment would be different if the effect in question was accomplished through a method call into jshint instead.
>  
> As to you concern that works with might apply to strictly dev-time tools if code is annotated accordingly, I don’t know whether it would or it would not. I seem to recall there being a special carve-out in the process for dev-time tools, but I don’t see where that’s documented. We certainly don’t have every project declaring a prereq dependency on Ant or Maven, because they build wit it.
>  
> Thanks,
>  
> - Konstantin
>  
>  
> 
> From: Gunnar Wagenknecht
> Sent: Monday, October 12, 2015 11:24 PM
> To: Konstantin Komissarchik
> Cc: Matthias.Zimmermann@xxxxxxxxxxxxxxxx;Technology PMC
> Subject: Re: [technology-pmc] eclipse scout and jshint
>  
>  
> Konstantin,
>  
> I understand the use case. But that is not a works-with in my definition. There is zero additional functionality provided by the code whether or not jshint is installed. It's really just configuration for tooling. 
>  
> Now, the reason I'm giving you a hard time is the following. I'm concerned that this will set a precedence case. If we continue and go down that path, we also have to ask every project to file works-with CQs for vim/emacs/findbugs/sonar/whatever-tool instructions in source code.
>  
> -Gunnar
>  
> -- 
> Gunnar Wagenknecht
> gunnar@xxxxxxxxxxxxxxx, http://guw.io/
>  
>  
>  
>  
>  
>  
> > Am 12.10.2015 um 21:05 schrieb Konstantin Komissarchik <konstantin.komissarchik@xxxxxxxxxx>:
> > 
> > In this particular case, the comment was added for the express purpose of ensuring that end users do not see certain validation messages when jshint is installed. It’s a pretty clear-cut case of a works with dependency. The project is integrating with jshint, but jshint is not required for full functionality, so works with.
> >  
> > - Konstantin
> >  
> >  
> > 
> > From: Gunnar Wagenknecht
> > Sent: Monday, October 12, 2015 11:49 AM
> > To: Konstantin Komissarchik
> > Cc: Matthias.Zimmermann@xxxxxxxxxxxxxxxx;Technology PMC
> > Subject: Re: [technology-pmc] eclipse scout and jshint
> >  
> >  
> > > Am 12.10.2015 um 20:39 schrieb Konstantin Komissarchik <konstantin.komissarchik@xxxxxxxxxx>:
> > > 
> > > The issue is that this in the code that’s delivered to end users.
> >  
> > So is all code at Eclipse.  git.eclipse.org.
> >  
> > I still don't see a need for a CQ. All that comment does is configure a code scanning/analysis plug-in in some IDE. 
> >  
> > What if that JavaScript file would contain:
> >  
> > /* vi: tabstop=4
> > */
> >  
> > Does that require a works-with CQ for vim? 
> >  
> > -Gunnar