[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [technology-pmc] eclipse scout and jshint
|
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