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) > > > > > > The NETBEANS-1819 could be an easy pick for anyone to take just > requires > > > insert header into test files and make sure that the test still works > > > with the header. > > > > > > > Frankly, I think this may be the most laborious part. Inserting the > license > > headers will almost surely trigger changes in the tests (but even if it > did > > not, it will be necessary to *run* the tests and evaluate). Of course, > > someone can imagine some trick to do this without breaking all the tests, > > but still does not feel so easy. > > > > Frankly, I wonder why we are expected to do something like that, given: > > http://www.apache.org/legal/src-headers.html#faq-exceptions > > > > > Test data for which the addition of a source header would cause the > tests > > to fail. > > > 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. 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. Of course, there are tricks that can be played here (like adding the license header to each an every file in the test/*/data directory, and stripping the license headers while copying the data to the test build directory; or simply not including tests in the release), but at least some of them are likely to bite us in the future. Jan > This would be great if some people with deeper knowledge of the java > support could look into this. I gladly take over, after the unittests > work. > > If we can do it before 11, great, if not, I would consider this issue > as waivable for 11. > > 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 > > > >
