You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@uima.apache.org by Richard Eckart de Castilho <ec...@ukp.informatik.tu-darmstadt.de> on 2013/08/25 14:13:14 UTC

[VOTE] Release uimaFIT 2.0.0 rc3

Hi,

I've posted uimaFIT 2.0.0 rc3.  There were 101 Jiras fixed, see

https://issues.apache.org/jira/issues/?jql=project%20%3D%20UIMA%20AND%20fixVersion%20%3D%20%222.0.0uimaFIT%22

The source and binary zip/tars are staged to
http://people.apache.org/~rec/uimafit-release-candidates/2.0.0-rc3/
<http://people.apache.org/%7Erec/uimafit-release-candidates/2.0.0-rc3/>

The Maven artifacts are here:
https://repository.apache.org/content/repositories/orgapacheuima-113/org/apache/uima/

The SVN tags are here:
https://svn.apache.org/repos/asf/uima/sandbox/uimafit/tags/uimafit-2.0.0-rc3

See http://uima.apache.org/testing-builds.html for suggestions on how to test
release candidates.

Please vote on release:

[ ] +1 OK to release
[ ] 0   Don't care
[ ] -1 Not OK to release, because …

Again, this RC addresses the valuable comments by Marshall (thanks!). Additionally, the XWriter has been removed according to discussions that took place long ago in the uimaFIT developer group. Since this was a non-compatible change that got overlooked in the past RCs, I implemented it now. Also, the examples have been reviewed.

Thanks.

-- Richard

Re: [VOTE] Release uimaFIT 2.0.0 rc3

Posted by Peter Klügl <pk...@uni-wuerzburg.de>.

compared source-release with svn-tag - had some issues with whitespaces,
but found no problems
mvn install on svn tag - OK
mvn install on source-release - OK
checked various license/notice files in bin and src - OK
checked staged artifacts with ruta

+1 to release

Peter


On 25.08.2013 14:13, Richard Eckart de Castilho wrote:
> Hi,
>
> I've posted uimaFIT 2.0.0 rc3.  There were 101 Jiras fixed, see
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20UIMA%20AND%20fixVersion%20%3D%20%222.0.0uimaFIT%22
>
> The source and binary zip/tars are staged to
> http://people.apache.org/~rec/uimafit-release-candidates/2.0.0-rc3/
> <http://people.apache.org/%7Erec/uimafit-release-candidates/2.0.0-rc3/>
>
> The Maven artifacts are here:
> https://repository.apache.org/content/repositories/orgapacheuima-113/org/apache/uima/
>
> The SVN tags are here:
> https://svn.apache.org/repos/asf/uima/sandbox/uimafit/tags/uimafit-2.0.0-rc3
>
> See http://uima.apache.org/testing-builds.html for suggestions on how to test
> release candidates.
>
> Please vote on release:
>
> [ ] +1 OK to release
> [ ] 0   Don't care
> [ ] -1 Not OK to release, because …
>
> Again, this RC addresses the valuable comments by Marshall (thanks!). Additionally, the XWriter has been removed according to discussions that took place long ago in the uimaFIT developer group. Since this was a non-compatible change that got overlooked in the past RCs, I implemented it now. Also, the examples have been reviewed.
>
> Thanks.
>
> -- Richard
>

Re: [VOTE] Release uimaFIT 2.0.0 rc3

Posted by Richard Eckart de Castilho <ri...@gmail.com>.

- Examples in binary release look good
- PDF looks good
- Licenses look good
- README looks good
- Build from source package looks good

I think/hope this one's shiny now.

+1 from my side.

-- Richard

Am 25.08.2013 um 14:13 schrieb Richard Eckart de Castilho <ec...@ukp.informatik.tu-darmstadt.de>:

> Hi,
> 
> I've posted uimaFIT 2.0.0 rc3.  There were 101 Jiras fixed, see
> 
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20UIMA%20AND%20fixVersion%20%3D%20%222.0.0uimaFIT%22
> 
> The source and binary zip/tars are staged to
> http://people.apache.org/~rec/uimafit-release-candidates/2.0.0-rc3/
> <http://people.apache.org/%7Erec/uimafit-release-candidates/2.0.0-rc3/>
> 
> The Maven artifacts are here:
> https://repository.apache.org/content/repositories/orgapacheuima-113/org/apache/uima/
> 
> The SVN tags are here:
> https://svn.apache.org/repos/asf/uima/sandbox/uimafit/tags/uimafit-2.0.0-rc3
> 
> See http://uima.apache.org/testing-builds.html for suggestions on how to test
> release candidates.
> 
> Please vote on release:
> 
> [ ] +1 OK to release
> [ ] 0   Don't care
> [ ] -1 Not OK to release, because …
> 
> Again, this RC addresses the valuable comments by Marshall (thanks!). Additionally, the XWriter has been removed according to discussions that took place long ago in the uimaFIT developer group. Since this was a non-compatible change that got overlooked in the past RCs, I implemented it now. Also, the examples have been reviewed.
> 
> Thanks.
> 
> -- Richard

[VOTE][RESULT] Release uimaFIT 2.0.0 rc3

Posted by Richard Eckart de Castilho <ri...@gmail.com>.

The vote passes:

+1: Richard Eckart de Castilho, Marshall Schor, Peter Klügl

No other votes received. Thanks to for all the excellent comments and for the votes!

-- Richard

Am 25.08.2013 um 14:13 schrieb Richard Eckart de Castilho <ec...@ukp.informatik.tu-darmstadt.de>:

> Hi,
> 
> I've posted uimaFIT 2.0.0 rc3.  There were 101 Jiras fixed, see
> 
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20UIMA%20AND%20fixVersion%20%3D%20%222.0.0uimaFIT%22
> 
> The source and binary zip/tars are staged to
> http://people.apache.org/~rec/uimafit-release-candidates/2.0.0-rc3/
> <http://people.apache.org/%7Erec/uimafit-release-candidates/2.0.0-rc3/>
> 
> The Maven artifacts are here:
> https://repository.apache.org/content/repositories/orgapacheuima-113/org/apache/uima/
> 
> The SVN tags are here:
> https://svn.apache.org/repos/asf/uima/sandbox/uimafit/tags/uimafit-2.0.0-rc3
> 
> See http://uima.apache.org/testing-builds.html for suggestions on how to test
> release candidates.
> 
> Please vote on release:
> 
> [ ] +1 OK to release
> [ ] 0   Don't care
> [ ] -1 Not OK to release, because …
> 
> Again, this RC addresses the valuable comments by Marshall (thanks!). Additionally, the XWriter has been removed according to discussions that took place long ago in the uimaFIT developer group. Since this was a non-compatible change that got overlooked in the past RCs, I implemented it now. Also, the examples have been reviewed.
> 
> Thanks.
> 
> -- Richard
>

Re: [VOTE] Release uimaFIT 2.0.0 rc3

Posted by Marshall Schor <ms...@schor.com>.

On 8/29/2013 6:49 AM, Richard Eckart de Castilho wrote:
> We have 3 +1 votes so far from Marshall Schor, Peter Klügl and myself and no other votes. Afaik 
> three is sufficient for the release to pass.
Yes.
>
> Unless there are other votes, this vote will be closed and released on Saturday. I'll also update
> the Apache Website with information about uimaFIT at that point.
The normal *wait* time is 72 hours (3 days), so we're past that.  But you can
wait longer :-)

Please feel free to ask lots of questions about updating the website, and also
look here:
http://uima.apache.org/release.html#Releasing

-Marshall
> Cheers,
>
> -- Richard
>
> Am 25.08.2013 um 14:13 schrieb Richard Eckart de Castilho <ec...@ukp.informatik.tu-darmstadt.de>:
>
>> Hi,
>>
>> I've posted uimaFIT 2.0.0 rc3.  There were 101 Jiras fixed, see
>>
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20UIMA%20AND%20fixVersion%20%3D%20%222.0.0uimaFIT%22
>>
>> The source and binary zip/tars are staged to
>> http://people.apache.org/~rec/uimafit-release-candidates/2.0.0-rc3/
>> <http://people.apache.org/%7Erec/uimafit-release-candidates/2.0.0-rc3/>
>>
>> The Maven artifacts are here:
>> https://repository.apache.org/content/repositories/orgapacheuima-113/org/apache/uima/
>>
>> The SVN tags are here:
>> https://svn.apache.org/repos/asf/uima/sandbox/uimafit/tags/uimafit-2.0.0-rc3
>>
>> See http://uima.apache.org/testing-builds.html for suggestions on how to test
>> release candidates.
>>
>> Please vote on release:
>>
>> [ ] +1 OK to release
>> [ ] 0   Don't care
>> [ ] -1 Not OK to release, because …
>>
>> Again, this RC addresses the valuable comments by Marshall (thanks!). Additionally, the XWriter has been removed according to discussions that took place long ago in the uimaFIT developer group. Since this was a non-compatible change that got overlooked in the past RCs, I implemented it now. Also, the examples have been reviewed.
>>
>> Thanks.
>>
>> -- Richard
>

Re: [VOTE] Release uimaFIT 2.0.0 rc3

Posted by Richard Eckart de Castilho <ri...@gmail.com>.

We have 3 +1 votes so far from Marshall Schor, Peter Klügl and myself and no other votes. Afaik 
three is sufficient for the release to pass.

Unless there are other votes, this vote will be closed and released on Saturday. I'll also update
the Apache Website with information about uimaFIT at that point.

Cheers,

-- Richard

Am 25.08.2013 um 14:13 schrieb Richard Eckart de Castilho <ec...@ukp.informatik.tu-darmstadt.de>:

> Hi,
> 
> I've posted uimaFIT 2.0.0 rc3.  There were 101 Jiras fixed, see
> 
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20UIMA%20AND%20fixVersion%20%3D%20%222.0.0uimaFIT%22
> 
> The source and binary zip/tars are staged to
> http://people.apache.org/~rec/uimafit-release-candidates/2.0.0-rc3/
> <http://people.apache.org/%7Erec/uimafit-release-candidates/2.0.0-rc3/>
> 
> The Maven artifacts are here:
> https://repository.apache.org/content/repositories/orgapacheuima-113/org/apache/uima/
> 
> The SVN tags are here:
> https://svn.apache.org/repos/asf/uima/sandbox/uimafit/tags/uimafit-2.0.0-rc3
> 
> See http://uima.apache.org/testing-builds.html for suggestions on how to test
> release candidates.
> 
> Please vote on release:
> 
> [ ] +1 OK to release
> [ ] 0   Don't care
> [ ] -1 Not OK to release, because …
> 
> Again, this RC addresses the valuable comments by Marshall (thanks!). Additionally, the XWriter has been removed according to discussions that took place long ago in the uimaFIT developer group. Since this was a non-compatible change that got overlooked in the past RCs, I implemented it now. Also, the examples have been reviewed.
> 
> Thanks.
> 
> -- Richard

Re: [VOTE] Release uimaFIT 2.0.0 rc3

Posted by Richard Eckart de Castilho <ri...@gmail.com>.

A salomonic suggestion. I also wouldn't mind fixing it and doing rc4, but
given this would be the only change, I'd skip quality checks like building 
from scratch an integrations builds with downstream frameworks, e.g. DKPro
as I have done for the previous rcs.

-- Richard

Am 28.08.2013 um 14:41 schrieb Marshall Schor <ms...@schor.com>:

> After sleeping on this overnight, it seems to me that this problem isn't
> significant enough to block the release: it only affects apache-release kinds of
> builds; normal "mvn install" doesn't run the RAT check so this doesn't affect
> others building from source (without the -Papache-release).
> 
> I'm OK with proceeding to check the rest of the release candidate, and if no
> significant issue comes up, voting to release this candidate;  this can be fixed
> for the next release.
> 
> -Marshall
> 
> On 8/27/2013 12:22 PM, Marshall Schor wrote:
>> After clearing the local .m2 cache for all things under org/apache/uima, build
>> from source failed for me with a RAT check:
>> 
>> Unapproved licenses:
>> 
>> 
>> C:/au/t/uimaFit/uimafit-2.0.0-source-release-bfs/uimafit-core/src/test/resources/data/docs/unix-newlines.txt.bin
>> 
>> C:/au/t/uimaFit/uimafit-2.0.0-source-release-bfs/uimafit-core/src/test/resources/data/docs/windows-newlines.txt.bin    
>> 
>> 
>> I wonder how the release was made such that this didn't fail during the release?
>> 
>> -Marshall
>> 
>> On 8/25/2013 8:13 AM, Richard Eckart de Castilho wrote:
>>> Hi,
>>> 
>>> I've posted uimaFIT 2.0.0 rc3.  There were 101 Jiras fixed, see
>>> 
>>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20UIMA%20AND%20fixVersion%20%3D%20%222.0.0uimaFIT%22
>>> 
>>> The source and binary zip/tars are staged to
>>> http://people.apache.org/~rec/uimafit-release-candidates/2.0.0-rc3/
>>> <http://people.apache.org/%7Erec/uimafit-release-candidates/2.0.0-rc3/>
>>> 
>>> The Maven artifacts are here:
>>> https://repository.apache.org/content/repositories/orgapacheuima-113/org/apache/uima/
>>> 
>>> The SVN tags are here:
>>> https://svn.apache.org/repos/asf/uima/sandbox/uimafit/tags/uimafit-2.0.0-rc3
>>> 
>>> See http://uima.apache.org/testing-builds.html for suggestions on how to test
>>> release candidates.
>>> 
>>> Please vote on release:
>>> 
>>> [ ] +1 OK to release
>>> [ ] 0   Don't care
>>> [ ] -1 Not OK to release, because …
>>> 
>>> Again, this RC addresses the valuable comments by Marshall (thanks!). Additionally, the XWriter has been removed according to discussions that took place long ago in the uimaFIT developer group. Since this was a non-compatible change that got overlooked in the past RCs, I implemented it now. Also, the examples have been reviewed.
>>> 
>>> Thanks.
>>> 
>>> -- Richard

Re: [VOTE] Release uimaFIT 2.0.0 rc3

Posted by Marshall Schor <ms...@schor.com>.

After sleeping on this overnight, it seems to me that this problem isn't
significant enough to block the release: it only affects apache-release kinds of
builds; normal "mvn install" doesn't run the RAT check so this doesn't affect
others building from source (without the -Papache-release).

I'm OK with proceeding to check the rest of the release candidate, and if no
significant issue comes up, voting to release this candidate;  this can be fixed
for the next release.

-Marshall

On 8/27/2013 12:22 PM, Marshall Schor wrote:
> After clearing the local .m2 cache for all things under org/apache/uima, build
> from source failed for me with a RAT check:
>
> Unapproved licenses:
>
>  
> C:/au/t/uimaFit/uimafit-2.0.0-source-release-bfs/uimafit-core/src/test/resources/data/docs/unix-newlines.txt.bin
>  
> C:/au/t/uimaFit/uimafit-2.0.0-source-release-bfs/uimafit-core/src/test/resources/data/docs/windows-newlines.txt.bin    
>
>
> I wonder how the release was made such that this didn't fail during the release?
>
> -Marshall
>  
> On 8/25/2013 8:13 AM, Richard Eckart de Castilho wrote:
>> Hi,
>>
>> I've posted uimaFIT 2.0.0 rc3.  There were 101 Jiras fixed, see
>>
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20UIMA%20AND%20fixVersion%20%3D%20%222.0.0uimaFIT%22
>>
>> The source and binary zip/tars are staged to
>> http://people.apache.org/~rec/uimafit-release-candidates/2.0.0-rc3/
>> <http://people.apache.org/%7Erec/uimafit-release-candidates/2.0.0-rc3/>
>>
>> The Maven artifacts are here:
>> https://repository.apache.org/content/repositories/orgapacheuima-113/org/apache/uima/
>>
>> The SVN tags are here:
>> https://svn.apache.org/repos/asf/uima/sandbox/uimafit/tags/uimafit-2.0.0-rc3
>>
>> See http://uima.apache.org/testing-builds.html for suggestions on how to test
>> release candidates.
>>
>> Please vote on release:
>>
>> [ ] +1 OK to release
>> [ ] 0   Don't care
>> [ ] -1 Not OK to release, because …
>>
>> Again, this RC addresses the valuable comments by Marshall (thanks!). Additionally, the XWriter has been removed according to discussions that took place long ago in the uimaFIT developer group. Since this was a non-compatible change that got overlooked in the past RCs, I implemented it now. Also, the examples have been reviewed.
>>
>> Thanks.
>>
>> -- Richard
>>
>>
>

Re: [VOTE] Release uimaFIT 2.0.0 rc3

Posted by Marshall Schor <ms...@schor.com>.

On 8/27/2013 4:00 PM, Richard Eckart de Castilho wrote:
> It's funny that the charset detector fails to detect the UTF-8 BOM mark
> (ef bb bf) and that RAT doesn't take the source file encoding into account
> (UTF-8). 
>
> Well, I'll do an rc4 then with this single change. Anything else before
> cancelling the vote?
I suggest we encourage the community to take a quick look (for those who have
time) to see if anything else shakes out, say, in the next day or 2. 

The other thing I've done so far is to check the .asc signatures and the md5/sha
hashes - they're OK.

-Marshall
>
> -- Richard
>
> Am 27.08.2013 um 21:27 schrieb Marshall Schor <ms...@schor.com>:
>
>> Just for fun, I ran the little snippet of guesser code that reads some bytes and
>> tries to decode it.
>>
>> Sure enough, with a file.encoding set to Cp1252, the file unix-newlines.txt.bin
>> decodes without errors (and therefore is not marked as a binary file).
>>
>> But with the file.encoding set to US-ASCII, then the file produces a
>> "CoderResult" of isMalFormed.
>>
>> So RAT marks it binary.
>>
>> I looked at this file in a Hex editor; it starts with the hex chars "ef bb bf". 
>> The US-ASCII code page is described here (
>> http://docs.oracle.com/javase/7/docs/api/java/nio/charset/Charset.html
>> ) as being Seven-bit ASCII.  So I guess these 3 bytes at the beginning cause the
>> decoder to say malformed.
>>
>> The windows cp1252 (see http://en.wikipedia.org/wiki/Windows-1252 ) has these
>> chars defined.
>>
>> So, to get a reproducable build, not dependent on build machine code pages, it
>> seems you can't rely on the binary "guesser" in RAT, and it's best to explicitly
>> use EXCLUDE configurations to tell RAT what to exclude.
>>
>> -Marshall
>>
>> On 8/27/2013 2:54 PM, Richard Eckart de Castilho wrote:
>>> Here it's 
>>>
>>> $ java PrintFileEncoding
>>> The file.encoding value is: US-ASCII
>>>
>>> -- Richard
>>>
>>> Am 27.08.2013 um 20:32 schrieb Marshall Schor <ms...@schor.com>:
>>>
>>>> The RAT code for 0.8 includes the binary guesser.  This code has 2 parts: one
>>>> guessing by the file-type in the file name, and the other by looking at the 1st
>>>> 200 bytes of the content.
>>>>
>>>> The file-type test doesn't include BIN/bin in the set. 
>>>>
>>>> The file-content test works using 2 tests.  The first is by creating a
>>>> CharsetDecoder from
>>>>  Charset.forName(System.getProperty("file.encoding")
>>>>
>>>> System.getProperty("file.encoding") comes from the Operating System; on my build
>>>> machine (windows 7), it has the value: Cp1252
>>>>
>>>> Here's the trivial java prog. I used to print it.
>>>>
>>>> public class PrintFileEncoding {
>>>> public static void main(String[] args) {
>>>>   System.out.format("The file.encoding value is: %s\n",
>>>> System.getProperty("file.encoding"));
>>>> }
>>>> }
>>>>
>>>> Then the guesser tries to decode the byte array using this charset decoder.  If
>>>> that fails, it says "binary".
>>>> If it succeeds, it runs the 2nd test:
>>>>
>>>> it takes the chars (from the successful decoding), and counts the # of chars
>>>> outside of the "normal" char range of 0x08 to 0xff.  It then sees if the # of
>>>> normal chars is < 66% approx.  If so, it calls it a binary file.
>>>>
>>>> What's the file.encoding on your build machine?
>>>>
>>>> -Marshall
>

Re: [VOTE] Release uimaFIT 2.0.0 rc3

Posted by Marshall Schor <ms...@schor.com>.

I've submitted https://issues.apache.org/jira/browse/RAT-147 documenting this issue.

-Marshall
On 8/27/2013 4:00 PM, Richard Eckart de Castilho wrote:
> It's funny that the charset detector fails to detect the UTF-8 BOM mark
> (ef bb bf) and that RAT doesn't take the source file encoding into account
> (UTF-8). 
>
> Well, I'll do an rc4 then with this single change. Anything else before
> cancelling the vote?
>
> -- Richard
>
> Am 27.08.2013 um 21:27 schrieb Marshall Schor <ms...@schor.com>:
>
>> Just for fun, I ran the little snippet of guesser code that reads some bytes and
>> tries to decode it.
>>
>> Sure enough, with a file.encoding set to Cp1252, the file unix-newlines.txt.bin
>> decodes without errors (and therefore is not marked as a binary file).
>>
>> But with the file.encoding set to US-ASCII, then the file produces a
>> "CoderResult" of isMalFormed.
>>
>> So RAT marks it binary.
>>
>> I looked at this file in a Hex editor; it starts with the hex chars "ef bb bf". 
>> The US-ASCII code page is described here (
>> http://docs.oracle.com/javase/7/docs/api/java/nio/charset/Charset.html
>> ) as being Seven-bit ASCII.  So I guess these 3 bytes at the beginning cause the
>> decoder to say malformed.
>>
>> The windows cp1252 (see http://en.wikipedia.org/wiki/Windows-1252 ) has these
>> chars defined.
>>
>> So, to get a reproducable build, not dependent on build machine code pages, it
>> seems you can't rely on the binary "guesser" in RAT, and it's best to explicitly
>> use EXCLUDE configurations to tell RAT what to exclude.
>>
>> -Marshall
>>
>> On 8/27/2013 2:54 PM, Richard Eckart de Castilho wrote:
>>> Here it's 
>>>
>>> $ java PrintFileEncoding
>>> The file.encoding value is: US-ASCII
>>>
>>> -- Richard
>>>
>>> Am 27.08.2013 um 20:32 schrieb Marshall Schor <ms...@schor.com>:
>>>
>>>> The RAT code for 0.8 includes the binary guesser.  This code has 2 parts: one
>>>> guessing by the file-type in the file name, and the other by looking at the 1st
>>>> 200 bytes of the content.
>>>>
>>>> The file-type test doesn't include BIN/bin in the set. 
>>>>
>>>> The file-content test works using 2 tests.  The first is by creating a
>>>> CharsetDecoder from
>>>>  Charset.forName(System.getProperty("file.encoding")
>>>>
>>>> System.getProperty("file.encoding") comes from the Operating System; on my build
>>>> machine (windows 7), it has the value: Cp1252
>>>>
>>>> Here's the trivial java prog. I used to print it.
>>>>
>>>> public class PrintFileEncoding {
>>>> public static void main(String[] args) {
>>>>   System.out.format("The file.encoding value is: %s\n",
>>>> System.getProperty("file.encoding"));
>>>> }
>>>> }
>>>>
>>>> Then the guesser tries to decode the byte array using this charset decoder.  If
>>>> that fails, it says "binary".
>>>> If it succeeds, it runs the 2nd test:
>>>>
>>>> it takes the chars (from the successful decoding), and counts the # of chars
>>>> outside of the "normal" char range of 0x08 to 0xff.  It then sees if the # of
>>>> normal chars is < 66% approx.  If so, it calls it a binary file.
>>>>
>>>> What's the file.encoding on your build machine?
>>>>
>>>> -Marshall
>

Re: [VOTE] Release uimaFIT 2.0.0 rc3

Posted by Richard Eckart de Castilho <ri...@gmail.com>.

It's funny that the charset detector fails to detect the UTF-8 BOM mark
(ef bb bf) and that RAT doesn't take the source file encoding into account
(UTF-8). 

Well, I'll do an rc4 then with this single change. Anything else before
cancelling the vote?

-- Richard

Am 27.08.2013 um 21:27 schrieb Marshall Schor <ms...@schor.com>:

> Just for fun, I ran the little snippet of guesser code that reads some bytes and
> tries to decode it.
> 
> Sure enough, with a file.encoding set to Cp1252, the file unix-newlines.txt.bin
> decodes without errors (and therefore is not marked as a binary file).
> 
> But with the file.encoding set to US-ASCII, then the file produces a
> "CoderResult" of isMalFormed.
> 
> So RAT marks it binary.
> 
> I looked at this file in a Hex editor; it starts with the hex chars "ef bb bf". 
> The US-ASCII code page is described here (
> http://docs.oracle.com/javase/7/docs/api/java/nio/charset/Charset.html
> ) as being Seven-bit ASCII.  So I guess these 3 bytes at the beginning cause the
> decoder to say malformed.
> 
> The windows cp1252 (see http://en.wikipedia.org/wiki/Windows-1252 ) has these
> chars defined.
> 
> So, to get a reproducable build, not dependent on build machine code pages, it
> seems you can't rely on the binary "guesser" in RAT, and it's best to explicitly
> use EXCLUDE configurations to tell RAT what to exclude.
> 
> -Marshall
> 
> On 8/27/2013 2:54 PM, Richard Eckart de Castilho wrote:
>> Here it's 
>> 
>> $ java PrintFileEncoding
>> The file.encoding value is: US-ASCII
>> 
>> -- Richard
>> 
>> Am 27.08.2013 um 20:32 schrieb Marshall Schor <ms...@schor.com>:
>> 
>>> The RAT code for 0.8 includes the binary guesser.  This code has 2 parts: one
>>> guessing by the file-type in the file name, and the other by looking at the 1st
>>> 200 bytes of the content.
>>> 
>>> The file-type test doesn't include BIN/bin in the set. 
>>> 
>>> The file-content test works using 2 tests.  The first is by creating a
>>> CharsetDecoder from
>>>  Charset.forName(System.getProperty("file.encoding")
>>> 
>>> System.getProperty("file.encoding") comes from the Operating System; on my build
>>> machine (windows 7), it has the value: Cp1252
>>> 
>>> Here's the trivial java prog. I used to print it.
>>> 
>>> public class PrintFileEncoding {
>>> public static void main(String[] args) {
>>>   System.out.format("The file.encoding value is: %s\n",
>>> System.getProperty("file.encoding"));
>>> }
>>> }
>>> 
>>> Then the guesser tries to decode the byte array using this charset decoder.  If
>>> that fails, it says "binary".
>>> If it succeeds, it runs the 2nd test:
>>> 
>>> it takes the chars (from the successful decoding), and counts the # of chars
>>> outside of the "normal" char range of 0x08 to 0xff.  It then sees if the # of
>>> normal chars is < 66% approx.  If so, it calls it a binary file.
>>> 
>>> What's the file.encoding on your build machine?
>>> 
>>> -Marshall

Re: [VOTE] Release uimaFIT 2.0.0 rc3

Posted by Marshall Schor <ms...@schor.com>.

Just for fun, I ran the little snippet of guesser code that reads some bytes and
tries to decode it.

Sure enough, with a file.encoding set to Cp1252, the file unix-newlines.txt.bin
decodes without errors (and therefore is not marked as a binary file).

But with the file.encoding set to US-ASCII, then the file produces a
"CoderResult" of isMalFormed.

So RAT marks it binary.

I looked at this file in a Hex editor; it starts with the hex chars "ef bb bf". 
The US-ASCII code page is described here (
http://docs.oracle.com/javase/7/docs/api/java/nio/charset/Charset.html
) as being Seven-bit ASCII.  So I guess these 3 bytes at the beginning cause the
decoder to say malformed.

The windows cp1252 (see http://en.wikipedia.org/wiki/Windows-1252 ) has these
chars defined.

So, to get a reproducable build, not dependent on build machine code pages, it
seems you can't rely on the binary "guesser" in RAT, and it's best to explicitly
use EXCLUDE configurations to tell RAT what to exclude.

-Marshall

On 8/27/2013 2:54 PM, Richard Eckart de Castilho wrote:
> Here it's 
>
> $ java PrintFileEncoding
> The file.encoding value is: US-ASCII
>
> -- Richard
>
> Am 27.08.2013 um 20:32 schrieb Marshall Schor <ms...@schor.com>:
>
>> The RAT code for 0.8 includes the binary guesser.  This code has 2 parts: one
>> guessing by the file-type in the file name, and the other by looking at the 1st
>> 200 bytes of the content.
>>
>> The file-type test doesn't include BIN/bin in the set. 
>>
>> The file-content test works using 2 tests.  The first is by creating a
>> CharsetDecoder from
>>   Charset.forName(System.getProperty("file.encoding")
>>
>> System.getProperty("file.encoding") comes from the Operating System; on my build
>> machine (windows 7), it has the value: Cp1252
>>
>> Here's the trivial java prog. I used to print it.
>>
>> public class PrintFileEncoding {
>>  public static void main(String[] args) {
>>    System.out.format("The file.encoding value is: %s\n",
>> System.getProperty("file.encoding"));
>>  }
>> }
>>
>> Then the guesser tries to decode the byte array using this charset decoder.  If
>> that fails, it says "binary".
>> If it succeeds, it runs the 2nd test:
>>
>> it takes the chars (from the successful decoding), and counts the # of chars
>> outside of the "normal" char range of 0x08 to 0xff.  It then sees if the # of
>> normal chars is < 66% approx.  If so, it calls it a binary file.
>>
>> What's the file.encoding on your build machine?
>>
>> -Marshall
>

Re: [VOTE] Release uimaFIT 2.0.0 rc3

Posted by Richard Eckart de Castilho <ri...@gmail.com>.

Here it's 

$ java PrintFileEncoding
The file.encoding value is: US-ASCII

-- Richard

Am 27.08.2013 um 20:32 schrieb Marshall Schor <ms...@schor.com>:

> The RAT code for 0.8 includes the binary guesser.  This code has 2 parts: one
> guessing by the file-type in the file name, and the other by looking at the 1st
> 200 bytes of the content.
> 
> The file-type test doesn't include BIN/bin in the set. 
> 
> The file-content test works using 2 tests.  The first is by creating a
> CharsetDecoder from
>   Charset.forName(System.getProperty("file.encoding")
> 
> System.getProperty("file.encoding") comes from the Operating System; on my build
> machine (windows 7), it has the value: Cp1252
> 
> Here's the trivial java prog. I used to print it.
> 
> public class PrintFileEncoding {
>  public static void main(String[] args) {
>    System.out.format("The file.encoding value is: %s\n",
> System.getProperty("file.encoding"));
>  }
> }
> 
> Then the guesser tries to decode the byte array using this charset decoder.  If
> that fails, it says "binary".
> If it succeeds, it runs the 2nd test:
> 
> it takes the chars (from the successful decoding), and counts the # of chars
> outside of the "normal" char range of 0x08 to 0xff.  It then sees if the # of
> normal chars is < 66% approx.  If so, it calls it a binary file.
> 
> What's the file.encoding on your build machine?
> 
> -Marshall

Re: [VOTE] Release uimaFIT 2.0.0 rc3

Posted by Marshall Schor <ms...@schor.com>.

The RAT code for 0.8 includes the binary guesser.  This code has 2 parts: one
guessing by the file-type in the file name, and the other by looking at the 1st
200 bytes of the content.

The file-type test doesn't include BIN/bin in the set. 

The file-content test works using 2 tests.  The first is by creating a
CharsetDecoder from
   Charset.forName(System.getProperty("file.encoding")

System.getProperty("file.encoding") comes from the Operating System; on my build
machine (windows 7), it has the value: Cp1252

Here's the trivial java prog. I used to print it.

public class PrintFileEncoding {
  public static void main(String[] args) {
    System.out.format("The file.encoding value is: %s\n",
System.getProperty("file.encoding"));
  }
}

Then the guesser tries to decode the byte array using this charset decoder.  If
that fails, it says "binary".
If it succeeds, it runs the 2nd test:

it takes the chars (from the successful decoding), and counts the # of chars
outside of the "normal" char range of 0x08 to 0xff.  It then sees if the # of
normal chars is < 66% approx.  If so, it calls it a binary file.

What's the file.encoding on your build machine?

-Marshall





On 8/27/2013 2:08 PM, Richard Eckart de Castilho wrote:
> Same version here: 0.8
>
> [INFO] --- apache-rat-plugin:0.8:check (default-cli) @ uimafit-core ---
> [INFO] Exclude: release.properties
> [INFO] Exclude: README*
> [INFO] Exclude: RELEASE_NOTES*
> [INFO] Exclude: issuesFixed/**
> [INFO] Exclude: src/test/resources/data/docs/unix-newlines.txt
> [INFO] Exclude: src/test/resources/data/docs/windows-newlines.txt
> [INFO] Exclude: src/test/resources/data/docs/bad.xcas
> [INFO] Exclude: src/test/resources/data/docs/test.xcas
> [INFO] Exclude: src/test/resources/data/docs/test.xmi
> [INFO] Exclude: src/test/resources/data/reference/JCasBuilderTest.dump
> [INFO] Exclude: src/test/resources/data/reference/test.xmi.dump
> [INFO] Exclude: src/test/resources/META-INF/org.apache.uima.fit/fsindexes.txt
> [INFO] Exclude: src/test/resources/META-INF/org.apache.uima.fit/typepriorities.txt
> [INFO] Exclude: src/test/resources/META-INF/org.apache.uima.fit/types.txt
> [INFO]
> [INFO] --- maven-install-plugin:2.3.1:install (default-install) @ uimafit-core ---
>
> -- Richard
>
> Am 27.08.2013 um 19:58 schrieb Marshall Schor <ms...@schor.com>:
>
>> On 8/27/2013 12:57 PM, Richard Eckart de Castilho wrote:
>>> The short story: RAT classifies these files as binaries on my machine.
>> What version of the RAT plugin is run in your build?
>>
>> The version that runs in my build is 0.8.
>>
>> Looking at that version of the RAT code, and searching for "binary" I find that
>> it seems to guess using 2 algorithms:  one is by the file type, but "bin" is not
>> in the list.  The other is by checking some number of bytes in the file to see
>> if they look like binary data.
>>
>> -Marshall
>>> The long story:
>>>
>>> I've just re-run a build as (the added -D's now only to speed up the build, were
>>> not used during release).
>>>
>>>  mvn clean install -Papache-release -Dgpg.skip -DskipTests
>>>
>>> on the svn checkout that I used for the release. I get this in the RAT report:
>>>
>>> *****************************************************
>>> Summary
>>> -------
>>> Generated at: 2013-08-27T18:50:44+02:00
>>> Notes: 2
>>> Binaries: 2
>>> Archives: 0
>>> Standards: 158
>>>
>>> Apache Licensed: 158
>>> Generated Documents: 0
>>>
>>> JavaDocs are generated and so license header is optional
>>> Generated files do not required license headers
>>>
>>> 0 Unknown Licenses
>>>
>>> …snip…
>>>
>>> *****************************************************
>>>  Files with Apache License headers will be marked AL
>>>  Binary files (which do not require AL headers) will be marked B
>>>  Compressed archives will be marked A
>>>  Notices, licenses etc will be marked N
>>>
>>> …snip…
>>>
>>>  B     /Users/bluefire/svn/uimafit-trunk/uimafit-core/src/test/resources/data/docs/unix-newlines.txt.bin
>>>  B     /Users/bluefire/svn/uimafit-trunk/uimafit-core/src/test/resources/data/docs/windows-newlines.txt.bin
>>>
>>> The two files have been classified as binaries and thus have been skipped during the check.
>>>
>>> I wonder why RAT fails on your machine, but not on mine.
>>>
>>> -- Richard
>>>
>>> Am 27.08.2013 um 18:22 schrieb Marshall Schor <ms...@schor.com>:
>>>
>>>> After clearing the local .m2 cache for all things under org/apache/uima, build
>>>> from source failed for me with a RAT check:
>>>>
>>>> Unapproved licenses:
>>>>
>>>>
>>>> C:/au/t/uimaFit/uimafit-2.0.0-source-release-bfs/uimafit-core/src/test/resources/data/docs/unix-newlines.txt.bin
>>>>
>>>> C:/au/t/uimaFit/uimafit-2.0.0-source-release-bfs/uimafit-core/src/test/resources/data/docs/windows-newlines.txt.bin    
>>>>
>>>>
>>>> I wonder how the release was made such that this didn't fail during the release?
>>>>
>>>> -Marshall
>>>>
>>>> On 8/25/2013 8:13 AM, Richard Eckart de Castilho wrote:
>>>>> Hi,
>>>>>
>>>>> I've posted uimaFIT 2.0.0 rc3.  There were 101 Jiras fixed, see
>>>>>
>>>>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20UIMA%20AND%20fixVersion%20%3D%20%222.0.0uimaFIT%22
>>>>>
>>>>> The source and binary zip/tars are staged to
>>>>> http://people.apache.org/~rec/uimafit-release-candidates/2.0.0-rc3/
>>>>> <http://people.apache.org/%7Erec/uimafit-release-candidates/2.0.0-rc3/>
>>>>>
>>>>> The Maven artifacts are here:
>>>>> https://repository.apache.org/content/repositories/orgapacheuima-113/org/apache/uima/
>>>>>
>>>>> The SVN tags are here:
>>>>> https://svn.apache.org/repos/asf/uima/sandbox/uimafit/tags/uimafit-2.0.0-rc3
>>>>>
>>>>> See http://uima.apache.org/testing-builds.html for suggestions on how to test
>>>>> release candidates.
>>>>>
>>>>> Please vote on release:
>>>>>
>>>>> [ ] +1 OK to release
>>>>> [ ] 0   Don't care
>>>>> [ ] -1 Not OK to release, because …
>>>>>
>>>>> Again, this RC addresses the valuable comments by Marshall (thanks!). Additionally, the XWriter has been removed according to discussions that took place long ago in the uimaFIT developer group. Since this was a non-compatible change that got overlooked in the past RCs, I implemented it now. Also, the examples have been reviewed.
>>>>>
>>>>> Thanks.
>>>>>
>>>>> -- Richard
>

Re: [VOTE] Release uimaFIT 2.0.0 rc3

Posted by Richard Eckart de Castilho <ri...@gmail.com>.

Same version here: 0.8

[INFO] --- apache-rat-plugin:0.8:check (default-cli) @ uimafit-core ---
[INFO] Exclude: release.properties
[INFO] Exclude: README*
[INFO] Exclude: RELEASE_NOTES*
[INFO] Exclude: issuesFixed/**
[INFO] Exclude: src/test/resources/data/docs/unix-newlines.txt
[INFO] Exclude: src/test/resources/data/docs/windows-newlines.txt
[INFO] Exclude: src/test/resources/data/docs/bad.xcas
[INFO] Exclude: src/test/resources/data/docs/test.xcas
[INFO] Exclude: src/test/resources/data/docs/test.xmi
[INFO] Exclude: src/test/resources/data/reference/JCasBuilderTest.dump
[INFO] Exclude: src/test/resources/data/reference/test.xmi.dump
[INFO] Exclude: src/test/resources/META-INF/org.apache.uima.fit/fsindexes.txt
[INFO] Exclude: src/test/resources/META-INF/org.apache.uima.fit/typepriorities.txt
[INFO] Exclude: src/test/resources/META-INF/org.apache.uima.fit/types.txt
[INFO]
[INFO] --- maven-install-plugin:2.3.1:install (default-install) @ uimafit-core ---

-- Richard

Am 27.08.2013 um 19:58 schrieb Marshall Schor <ms...@schor.com>:

> 
> On 8/27/2013 12:57 PM, Richard Eckart de Castilho wrote:
>> The short story: RAT classifies these files as binaries on my machine.
> What version of the RAT plugin is run in your build?
> 
> The version that runs in my build is 0.8.
> 
> Looking at that version of the RAT code, and searching for "binary" I find that
> it seems to guess using 2 algorithms:  one is by the file type, but "bin" is not
> in the list.  The other is by checking some number of bytes in the file to see
> if they look like binary data.
> 
> -Marshall
>> The long story:
>> 
>> I've just re-run a build as (the added -D's now only to speed up the build, were
>> not used during release).
>> 
>>  mvn clean install -Papache-release -Dgpg.skip -DskipTests
>> 
>> on the svn checkout that I used for the release. I get this in the RAT report:
>> 
>> *****************************************************
>> Summary
>> -------
>> Generated at: 2013-08-27T18:50:44+02:00
>> Notes: 2
>> Binaries: 2
>> Archives: 0
>> Standards: 158
>> 
>> Apache Licensed: 158
>> Generated Documents: 0
>> 
>> JavaDocs are generated and so license header is optional
>> Generated files do not required license headers
>> 
>> 0 Unknown Licenses
>> 
>> …snip…
>> 
>> *****************************************************
>>  Files with Apache License headers will be marked AL
>>  Binary files (which do not require AL headers) will be marked B
>>  Compressed archives will be marked A
>>  Notices, licenses etc will be marked N
>> 
>> …snip…
>> 
>>  B     /Users/bluefire/svn/uimafit-trunk/uimafit-core/src/test/resources/data/docs/unix-newlines.txt.bin
>>  B     /Users/bluefire/svn/uimafit-trunk/uimafit-core/src/test/resources/data/docs/windows-newlines.txt.bin
>> 
>> The two files have been classified as binaries and thus have been skipped during the check.
>> 
>> I wonder why RAT fails on your machine, but not on mine.
>> 
>> -- Richard
>> 
>> Am 27.08.2013 um 18:22 schrieb Marshall Schor <ms...@schor.com>:
>> 
>>> After clearing the local .m2 cache for all things under org/apache/uima, build
>>> from source failed for me with a RAT check:
>>> 
>>> Unapproved licenses:
>>> 
>>> 
>>> C:/au/t/uimaFit/uimafit-2.0.0-source-release-bfs/uimafit-core/src/test/resources/data/docs/unix-newlines.txt.bin
>>> 
>>> C:/au/t/uimaFit/uimafit-2.0.0-source-release-bfs/uimafit-core/src/test/resources/data/docs/windows-newlines.txt.bin    
>>> 
>>> 
>>> I wonder how the release was made such that this didn't fail during the release?
>>> 
>>> -Marshall
>>> 
>>> On 8/25/2013 8:13 AM, Richard Eckart de Castilho wrote:
>>>> Hi,
>>>> 
>>>> I've posted uimaFIT 2.0.0 rc3.  There were 101 Jiras fixed, see
>>>> 
>>>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20UIMA%20AND%20fixVersion%20%3D%20%222.0.0uimaFIT%22
>>>> 
>>>> The source and binary zip/tars are staged to
>>>> http://people.apache.org/~rec/uimafit-release-candidates/2.0.0-rc3/
>>>> <http://people.apache.org/%7Erec/uimafit-release-candidates/2.0.0-rc3/>
>>>> 
>>>> The Maven artifacts are here:
>>>> https://repository.apache.org/content/repositories/orgapacheuima-113/org/apache/uima/
>>>> 
>>>> The SVN tags are here:
>>>> https://svn.apache.org/repos/asf/uima/sandbox/uimafit/tags/uimafit-2.0.0-rc3
>>>> 
>>>> See http://uima.apache.org/testing-builds.html for suggestions on how to test
>>>> release candidates.
>>>> 
>>>> Please vote on release:
>>>> 
>>>> [ ] +1 OK to release
>>>> [ ] 0   Don't care
>>>> [ ] -1 Not OK to release, because …
>>>> 
>>>> Again, this RC addresses the valuable comments by Marshall (thanks!). Additionally, the XWriter has been removed according to discussions that took place long ago in the uimaFIT developer group. Since this was a non-compatible change that got overlooked in the past RCs, I implemented it now. Also, the examples have been reviewed.
>>>> 
>>>> Thanks.
>>>> 
>>>> -- Richard
>

Re: [VOTE] Release uimaFIT 2.0.0 rc3

Posted by Marshall Schor <ms...@schor.com>.

On 8/27/2013 12:57 PM, Richard Eckart de Castilho wrote:
> The short story: RAT classifies these files as binaries on my machine.
What version of the RAT plugin is run in your build?

The version that runs in my build is 0.8.

Looking at that version of the RAT code, and searching for "binary" I find that
it seems to guess using 2 algorithms:  one is by the file type, but "bin" is not
in the list.  The other is by checking some number of bytes in the file to see
if they look like binary data.

-Marshall
> The long story:
>
> I've just re-run a build as (the added -D's now only to speed up the build, were
> not used during release).
>
>   mvn clean install -Papache-release -Dgpg.skip -DskipTests
>
> on the svn checkout that I used for the release. I get this in the RAT report:
>
> *****************************************************
> Summary
> -------
> Generated at: 2013-08-27T18:50:44+02:00
> Notes: 2
> Binaries: 2
> Archives: 0
> Standards: 158
>
> Apache Licensed: 158
> Generated Documents: 0
>
> JavaDocs are generated and so license header is optional
> Generated files do not required license headers
>
> 0 Unknown Licenses
>
> …snip…
>
> *****************************************************
>   Files with Apache License headers will be marked AL
>   Binary files (which do not require AL headers) will be marked B
>   Compressed archives will be marked A
>   Notices, licenses etc will be marked N
>
> …snip…
>
>   B     /Users/bluefire/svn/uimafit-trunk/uimafit-core/src/test/resources/data/docs/unix-newlines.txt.bin
>   B     /Users/bluefire/svn/uimafit-trunk/uimafit-core/src/test/resources/data/docs/windows-newlines.txt.bin
>
> The two files have been classified as binaries and thus have been skipped during the check.
>
> I wonder why RAT fails on your machine, but not on mine.
>
> -- Richard
>
> Am 27.08.2013 um 18:22 schrieb Marshall Schor <ms...@schor.com>:
>
>> After clearing the local .m2 cache for all things under org/apache/uima, build
>> from source failed for me with a RAT check:
>>
>> Unapproved licenses:
>>
>>
>> C:/au/t/uimaFit/uimafit-2.0.0-source-release-bfs/uimafit-core/src/test/resources/data/docs/unix-newlines.txt.bin
>>
>> C:/au/t/uimaFit/uimafit-2.0.0-source-release-bfs/uimafit-core/src/test/resources/data/docs/windows-newlines.txt.bin    
>>
>>
>> I wonder how the release was made such that this didn't fail during the release?
>>
>> -Marshall
>>
>> On 8/25/2013 8:13 AM, Richard Eckart de Castilho wrote:
>>> Hi,
>>>
>>> I've posted uimaFIT 2.0.0 rc3.  There were 101 Jiras fixed, see
>>>
>>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20UIMA%20AND%20fixVersion%20%3D%20%222.0.0uimaFIT%22
>>>
>>> The source and binary zip/tars are staged to
>>> http://people.apache.org/~rec/uimafit-release-candidates/2.0.0-rc3/
>>> <http://people.apache.org/%7Erec/uimafit-release-candidates/2.0.0-rc3/>
>>>
>>> The Maven artifacts are here:
>>> https://repository.apache.org/content/repositories/orgapacheuima-113/org/apache/uima/
>>>
>>> The SVN tags are here:
>>> https://svn.apache.org/repos/asf/uima/sandbox/uimafit/tags/uimafit-2.0.0-rc3
>>>
>>> See http://uima.apache.org/testing-builds.html for suggestions on how to test
>>> release candidates.
>>>
>>> Please vote on release:
>>>
>>> [ ] +1 OK to release
>>> [ ] 0   Don't care
>>> [ ] -1 Not OK to release, because …
>>>
>>> Again, this RC addresses the valuable comments by Marshall (thanks!). Additionally, the XWriter has been removed according to discussions that took place long ago in the uimaFIT developer group. Since this was a non-compatible change that got overlooked in the past RCs, I implemented it now. Also, the examples have been reviewed.
>>>
>>> Thanks.
>>>
>>> -- Richard

Re: [VOTE] Release uimaFIT 2.0.0 rc3

Posted by Marshall Schor <ms...@schor.com>.

probably the right way to fix this is to just list these 2 files as exceptions....

-Marshall

On 8/27/2013 12:57 PM, Richard Eckart de Castilho wrote:
> The short story: RAT classifies these files as binaries on my machine.
>
> The long story:
>
> I've just re-run a build as (the added -D's now only to speed up the build, were
> not used during release).
>
>   mvn clean install -Papache-release -Dgpg.skip -DskipTests
>
> on the svn checkout that I used for the release. I get this in the RAT report:
>
> *****************************************************
> Summary
> -------
> Generated at: 2013-08-27T18:50:44+02:00
> Notes: 2
> Binaries: 2
> Archives: 0
> Standards: 158
>
> Apache Licensed: 158
> Generated Documents: 0
>
> JavaDocs are generated and so license header is optional
> Generated files do not required license headers
>
> 0 Unknown Licenses
>
> …snip…
>
> *****************************************************
>   Files with Apache License headers will be marked AL
>   Binary files (which do not require AL headers) will be marked B
>   Compressed archives will be marked A
>   Notices, licenses etc will be marked N
>
> …snip…
>
>   B     /Users/bluefire/svn/uimafit-trunk/uimafit-core/src/test/resources/data/docs/unix-newlines.txt.bin
>   B     /Users/bluefire/svn/uimafit-trunk/uimafit-core/src/test/resources/data/docs/windows-newlines.txt.bin
>
> The two files have been classified as binaries and thus have been skipped during the check.
>
> I wonder why RAT fails on your machine, but not on mine.
>
> -- Richard
>
> Am 27.08.2013 um 18:22 schrieb Marshall Schor <ms...@schor.com>:
>
>> After clearing the local .m2 cache for all things under org/apache/uima, build
>> from source failed for me with a RAT check:
>>
>> Unapproved licenses:
>>
>>
>> C:/au/t/uimaFit/uimafit-2.0.0-source-release-bfs/uimafit-core/src/test/resources/data/docs/unix-newlines.txt.bin
>>
>> C:/au/t/uimaFit/uimafit-2.0.0-source-release-bfs/uimafit-core/src/test/resources/data/docs/windows-newlines.txt.bin    
>>
>>
>> I wonder how the release was made such that this didn't fail during the release?
>>
>> -Marshall
>>
>> On 8/25/2013 8:13 AM, Richard Eckart de Castilho wrote:
>>> Hi,
>>>
>>> I've posted uimaFIT 2.0.0 rc3.  There were 101 Jiras fixed, see
>>>
>>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20UIMA%20AND%20fixVersion%20%3D%20%222.0.0uimaFIT%22
>>>
>>> The source and binary zip/tars are staged to
>>> http://people.apache.org/~rec/uimafit-release-candidates/2.0.0-rc3/
>>> <http://people.apache.org/%7Erec/uimafit-release-candidates/2.0.0-rc3/>
>>>
>>> The Maven artifacts are here:
>>> https://repository.apache.org/content/repositories/orgapacheuima-113/org/apache/uima/
>>>
>>> The SVN tags are here:
>>> https://svn.apache.org/repos/asf/uima/sandbox/uimafit/tags/uimafit-2.0.0-rc3
>>>
>>> See http://uima.apache.org/testing-builds.html for suggestions on how to test
>>> release candidates.
>>>
>>> Please vote on release:
>>>
>>> [ ] +1 OK to release
>>> [ ] 0   Don't care
>>> [ ] -1 Not OK to release, because …
>>>
>>> Again, this RC addresses the valuable comments by Marshall (thanks!). Additionally, the XWriter has been removed according to discussions that took place long ago in the uimaFIT developer group. Since this was a non-compatible change that got overlooked in the past RCs, I implemented it now. Also, the examples have been reviewed.
>>>
>>> Thanks.
>>>
>>> -- Richard