[
https://issues.apache.org/jira/browse/LUCENE-6732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15045700#comment-15045700
]
Mikhail Khludnev commented on LUCENE-6732:
------------------------------------------
Got an observation. Something weird happen with one of my working copy files,
the validation script failed with quite laconic:
{code}
java.io.IOException: Input/output error
{code}
There is no a problem path, in exception. It's not a problem of the script, but
just a lack of usability. Do you think it's worth to improve exception
reporting in groovy script? I'm not familiar, but I can try.
for the reference the stack trace:
{code}
Caused by: java.io.IOException: Input/output error
at java.io.FileInputStream.readBytes(Native Method)
at java.io.FileInputStream.read(FileInputStream.java:255)
at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
at java.io.InputStreamReader.read(InputStreamReader.java:184)
at java.io.BufferedReader.read1(BufferedReader.java:210)
at java.io.BufferedReader.read(BufferedReader.java:286)
at java.io.Reader.read(Reader.java:140)
at
org.codehaus.groovy.runtime.IOGroovyMethods.getText(IOGroovyMethods.java:884)
at
org.codehaus.groovy.runtime.ResourceGroovyMethods.getText(ResourceGroovyMethods.java:588)
at org.codehaus.groovy.runtime.dgm$964.invoke(Unknown Source)
at
org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite$PojoMetaMethodSiteNoUnwrapNoCoerce.invoke(PojoMetaMethodSite.java:274)
at
org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:56)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
at
embedded_script_in__Users_mkhl_Documents_lucene_solr_https_5x_build_dot_xml$_run_closure3.doCall(embedded_script_in__Users_mkhl_Documents_lucene_solr_https_5x_build_dot_xml:60)
{code}
> Improve validate-source-patterns in build.xml (e.g., detect invalid license
> headers!!)
> --------------------------------------------------------------------------------------
>
> Key: LUCENE-6732
> URL: https://issues.apache.org/jira/browse/LUCENE-6732
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Uwe Schindler
> Assignee: Uwe Schindler
> Fix For: Trunk, 5.4
>
> Attachments: LUCENE-6732-v2.patch, LUCENE-6732.patch,
> LUCENE-6732.patch
>
>
> Today I enabled warnings analysis on Policeman Jenkins. This scans the build
> log for warnings by javac and reports them in statistics, together with
> source file dumps.
> When doing that I found out that someone added again a lot of "invalid"
> license headers using {{/\*\*}} instead a simple comment. This causes
> javadocs warnings under some circumstances, because {{/\*\*}} is start of
> javadocs and not a license comment.
> I then tried to fix the validate-source-patterns to detect this, but due to a
> bug in ANT, the {{<containsregexp/>}} filter is applied per line (although it
> has multiline matching capabilities!!!).
> So I rewrote our checker to run with groovy. This also has some good parts:
> - it tells you wwhat was broken, otherwise you just know there is an error,
> but not whats wrong (tab, nocommit,...)
> - its much faster (multiple {{<containsregexp/>}} read file over and over,
> this one reads file one time into a string and then applies all regular
> expressions).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
