Thank you guys!
Could be a solution to mark those files as some CRAFTED_TEST_DATA in
licenseinfo.xml? I know we do not have that category (yet), but that
would be a mark in the sources that we actually care. Anyway, I'm going
to waive that issue for 11.0 and cut a vc3.
On 3/9/19 7:22 AM, Matthias Bläsing wrote:
Hi,
Am Samstag, den 09.03.2019, 13:59 +0100 schrieb Jan Lahoda:
Hi,
On Sat, Mar 9, 2019 at 11:50 AM Matthias Bläsing <mblaes...@doppel-helix.eu>
wrote:
[snip]
NETBEANS-1819 Incorrect License Headers in Test Sources
(https://issues.apache.org/jira/browse/NETBEANS-1819)
It was our decision to treat license related issues as blockers. If
Nothing against that - but what *exactly* is the license related issue
here? I mean, the policy allows test data without the headers. And for the
IDE, some of the test data may resemble source code files.
I read the policy as: for test files we tolerate missing license
headers, but it would be great if they are there.
possible we should see, that also the test sources contain correct
license headers. It would be great if the unittests for java.editor
could be fixed, then the addition of license headers to the data files
is a chore, but doable.
Well, is it really so simple? No doubts we should fix the tests for
java.editor (and other modules!), but is that really the main problem here?
When all the tests (for java.editor, as requested here!) are fixed, what is
next? Add the license header to all .java files in
java.editor/test/unit/data, run tests and adjust tests to pass? Ok, that is
a chore, but not that bad. But probably by far not enough: there are tests
that verify something does not happen (an error is *not* reported, list of
proposals is empty, etc.) These may vacuously pass when the license header
is added (i.e. the test may pass even if the problem is not fixed). So, it
may be necessary to check every single testcase to see if it still tests
what it should test. This starts to sound scary.
Moreover, is there a particular reason to believe this relates to the
java.editor module only? If yes, then OK, we can invest some effort to
resolve this for this particular module. But I don't see a reason to
believe this applies to only this module. There are many more Java-related
modules in a similar situation. But, even worse, is there a reason to
believe this applies only to Java modules? I see test data files without
license headers in javascript2.editor, php.editor. Are these for some
reason OK? Or is it that so far these were not brought up on the review,
and when they are brought up in some future round of review, we will be in
the same positions as we are now with java.editor?
Frankly, if I thought this can be resolved in few hours, I wouldn't push
back. But I don't think that's the case - I think this can easily cost us
thousands (or at least hundreds) of man-hours. And it is not clear to me if
we can afford that.
I think this is a fair assessment of the situation. I admit, that I was
focused on one/two modules and the assumption, that working (not
failing) tests are enough prove for correct working tests.
Having said this, adding that summary to the issue, it could be closed
as "Won't fix". At least I would be willing to defend that decision.
It should be made clear though, that when working on tests it is
expected, that at least an effort is made to work with license headers.
My POV: Noone can claim that there are existing unittest without
license headers and do the same for new code.
Greetings
Matthias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
