| Re: [technology-pmc] eclipse scout and jshint |
Both are examples of declarative API usage. The aspect that signified for me a need for a works with dependency is the fact that the artifact with the comment is part of project’s deliverable to end users. As such, it doesn’t qualify for the dev time tools exemption. - Konstantin
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 |