[VOTE] Release Apache UIMA Ruta 2.2.0 RC5

[Peter Klügl <pk...@uni-wuerzburg.de>]

Hi,

the fifth release candidate of Apache UIMA Ruta v2.2.0 is ready for voting.

Changes in RC5 since RC4:
- fixed relative path to parent pom
- (UIMA-3307) Ruta project references closed project
- (UIMA-3269) Imported type system specified with broken url
- (UIMA-3607) Improve auto-completion functionality for type system import
- (UIMA-3352) absolute vs. relative paths in auto generated engine.xml
- (UIMA-3147) Invisible wildcard match in Ruta should not be applied
- (UIMA-2900) Refactor Ruta IDE validators

Changes in RC4 since RC3:
- ruta-docbook maven.deploy.skip=true
- changed UimafitTest to work without external txt file
- replaced backslashes in ruta-core pom
- added syntax checks of references in EXEC action
- enabled autocompletion on uimafit analysis engines
- (UIMA-3668) Ruta Workbench: Load type system descriptor from maven
dependencies
- (UIMA-3678) Ruta: Trim Action throws Nullpointer on fully trimmed
Annotations
- (UIMA-3207) Investigate if all streams and scanners are closed in Ruta
- (UIMA-3683) Ruta: Add block that stops after first applied statement
- (UIMA-3679) Ruta documentation mentions wordlist with wrong quoting


Staging repository:
https://repository.apache.org/content/repositories/orgapacheuima-1014/

SVN tag:
https://svn.apache.org/repos/asf/uima/ruta/tags/ruta-2.2.0

Update site:
http://people.apache.org/~pkluegl/uima-releases/ruta-2.2.0-rc5/eclipse-update-site/ruta/

Archive with all sources:
http://people.apache.org/~pkluegl/uima-releases/ruta-2.2.0-rc5/ruta-2.2.0-source-release.zip

Overall 78 issues have been fixed for this release.
They can be found in the RELEASE_NOTES.html and here:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20UIMA%20AND%20fixVersion%20%3D%202.2.0ruta%20AND%20component%20%3D%20ruta%20ORDER%20BY%20priority%20DESC

Major Changes in this Release

UIMA Ruta Language and Analysis Engine:
- Major performance improvements
- Improved import type functionality and handling of ambiguous short names
- Support of block extensions for rule inference adaptions
- Options to determine where the next match should start
- Requires at least Java 6
- Many bug fixes

UIMA Ruta Workbench:
- Smaller improvements in many views
- Support of mixin Java/Ruta projects
- Many bug fixes


ONLY FOR REVIEWING:

Documentation (pdf file):
http://people.apache.org/~pkluegl/uima-releases/ruta-2.2.0-rc5/tools.ruta.book.pdf


Please vote on release:

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

Thanks.

Peter

Re: [VOTE][CANCELLED] Release Apache UIMA Ruta 2.2.0 RC5

[Peter Klügl <pk...@uni-wuerzburg.de>]

preparing new RC...

Am 01.04.2014 10:55, schrieb Peter Klügl:
> Hi,
>
> the fifth release candidate of Apache UIMA Ruta v2.2.0 is ready for voting.
>
> Changes in RC5 since RC4:
> - fixed relative path to parent pom
> - (UIMA-3307) Ruta project references closed project
> - (UIMA-3269) Imported type system specified with broken url
> - (UIMA-3607) Improve auto-completion functionality for type system import
> - (UIMA-3352) absolute vs. relative paths in auto generated engine.xml
> - (UIMA-3147) Invisible wildcard match in Ruta should not be applied
> - (UIMA-2900) Refactor Ruta IDE validators
>
> Changes in RC4 since RC3:
> - ruta-docbook maven.deploy.skip=true
> - changed UimafitTest to work without external txt file
> - replaced backslashes in ruta-core pom
> - added syntax checks of references in EXEC action
> - enabled autocompletion on uimafit analysis engines
> - (UIMA-3668) Ruta Workbench: Load type system descriptor from maven
> dependencies
> - (UIMA-3678) Ruta: Trim Action throws Nullpointer on fully trimmed
> Annotations
> - (UIMA-3207) Investigate if all streams and scanners are closed in Ruta
> - (UIMA-3683) Ruta: Add block that stops after first applied statement
> - (UIMA-3679) Ruta documentation mentions wordlist with wrong quoting
>
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapacheuima-1014/
>
> SVN tag:
> https://svn.apache.org/repos/asf/uima/ruta/tags/ruta-2.2.0
>
> Update site:
> http://people.apache.org/~pkluegl/uima-releases/ruta-2.2.0-rc5/eclipse-update-site/ruta/
>
> Archive with all sources:
> http://people.apache.org/~pkluegl/uima-releases/ruta-2.2.0-rc5/ruta-2.2.0-source-release.zip
>
> Overall 78 issues have been fixed for this release.
> They can be found in the RELEASE_NOTES.html and here:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20UIMA%20AND%20fixVersion%20%3D%202.2.0ruta%20AND%20component%20%3D%20ruta%20ORDER%20BY%20priority%20DESC
>
> Major Changes in this Release
>
> UIMA Ruta Language and Analysis Engine:
> - Major performance improvements
> - Improved import type functionality and handling of ambiguous short names
> - Support of block extensions for rule inference adaptions
> - Options to determine where the next match should start
> - Requires at least Java 6
> - Many bug fixes
>
> UIMA Ruta Workbench:
> - Smaller improvements in many views
> - Support of mixin Java/Ruta projects
> - Many bug fixes
>
>
> ONLY FOR REVIEWING:
>
> Documentation (pdf file):
> http://people.apache.org/~pkluegl/uima-releases/ruta-2.2.0-rc5/tools.ruta.book.pdf
>
>
> Please vote on release:
>
> [ ] +1 OK to release
> [ ]  0 Don't care
> [ ] -1 Not OK to release, because ...
>
> Thanks.
>
> Peter
>

Re: [VOTE] Release Apache UIMA Ruta 2.2.0 RC5

[Marshall Schor <ms...@schor.com>]

On 4/9/2014 3:33 AM, Peter Klügl wrote:
> Thanks, Marhsall. Overall, it is obious to me, but I probably got just a
> bit upset yesterday that we did not get it right in the first place.

I think the license stuff is hard, and projects gradually figure out (climb
learning curves) how to do this part better and better.

I also think that part of the value of Apache projects is a certain high level
confidence users feel in having the licensing / notices things well looked after :-)

-Marshall
>
> I will create a new RC and take also a look again at the other jars if
> there is something in their license files.
>
> Peter
>
> Am 08.04.2014 16:52, schrieb Marshall Schor:
>> On 4/8/2014 3:40 AM, Peter Klügl wrote:
>>> Am 07.04.2014 15:26, schrieb Marshall Schor:
>>>> On 4/7/2014 8:29 AM, Peter Klügl wrote:
>>>>> ...
>>>>> Advice would be greatly appreciated.
>>>> I looked at the license file in that jar and it seems to have a lot of
>>>> additional licenses.  So, one thing to do is to copy those licenses into the top
>>>> level license file for your distribution.
>>> That would be the engine plugin artifact.
>>>
>>>> Another thing to possibly do is to "filter" the Jar to remove the parts you're
>>>> not using, and drop the notices/licenses for those parts (since the jar you'll
>>>> be distributing won't have those).
>>>>
>>>> There are tools out there for figuring out what can be dropped, and doing the
>>>> filtering - I don't have a link at this moment, but I remember coming across
>>>> them when looking at Android packaging tooling.
>>> I'd rather remove the complete dependency. It is only used in the addons
>>> plugin in one view of the cde framework, but we actually have been
>>> thinking about using more functionality in the future. This would cause
>>> us to do the filtering each time.
>>>
>>> So, I will cancel the RC and create a new one with an extended LICENSE
>>> file, right?
>>>
>>> Just to mention a reason why this did not happen before:
>>> https://www.apache.org/dev/licensing-howto.html#alv2-dep
>>>
>>> <quote>
>>> Bundling an Apache-2.0-licensed Dependency
>>> Assuming once again that that the dependency subtree contains no bundled
>>> subcomponents under other licenses and thus the ALv2 applies uniformly
>>> to all files, there is no need to modify LICENSE.
>> But this doesn't seem to be the case here.  The dependency subtree (the Jar)
>> presumably has something licensed under those other licenses (not Apache-2.0)
>> included in their Jar?
>>> If the dependency supplies a NOTICE file, its contents must be analyzed
>>> and the relevant portions bubbled up into the top-level NOTICE file.
>>> </quote>
>>>
>>> Reading this with the fact in mind that the dependency is a library
>>> developed and released by ASF, one can easily think that the license
>>> file does not need to be changed. Isn't there only one license for a
>>> released artifact at ASF?
>> Anytime we prepare convenience packaging that mixes work we do at the ASF (which
>> is licensed under the Apache v2 license) and other artifacts licensed under
>> other licenses (icons, etc.), we are releasing an artifact which has more than
>> just the Apache v2 license.  If others then incorporate our artifact, they have
>> to deal with those other licenses and notices, too.
>>
>> This is something we need to consider when building artifacts.  Sometimes, it
>> not so great a concern if we bundle lots of other things having separate
>> notice/files (although it makes it a bit more difficult for end-users to
>> understand their obligations), but other times, for instance, if we expect other
>> developers to take our work and build other products of their own, then it
>> becomes more of a concern, because those other developers will be redistributing
>> their works, and they have to then do a careful analysis of all the licenses and
>> notices (much as we're having to do now ...).
>>
>> -Marshall
>>> Peter
>>>
>>>> -Marshall
>>>>> Best,
>>>>>
>>>>> Peter
>>>>>
>>>>>> -Marshall
>>>>>>
>
>

Re: [VOTE] Release Apache UIMA Ruta 2.2.0 RC5

[Peter Klügl <pk...@uni-wuerzburg.de>]

Thanks, Marhsall. Overall, it is obious to me, but I probably got just a
bit upset yesterday that we did not get it right in the first place.

I will create a new RC and take also a look again at the other jars if
there is something in their license files.

Peter

Am 08.04.2014 16:52, schrieb Marshall Schor:
> On 4/8/2014 3:40 AM, Peter Klügl wrote:
>> Am 07.04.2014 15:26, schrieb Marshall Schor:
>>> On 4/7/2014 8:29 AM, Peter Klügl wrote:
>>>> ...
>>>> Advice would be greatly appreciated.
>>> I looked at the license file in that jar and it seems to have a lot of
>>> additional licenses.  So, one thing to do is to copy those licenses into the top
>>> level license file for your distribution.
>> That would be the engine plugin artifact.
>>
>>> Another thing to possibly do is to "filter" the Jar to remove the parts you're
>>> not using, and drop the notices/licenses for those parts (since the jar you'll
>>> be distributing won't have those).
>>>
>>> There are tools out there for figuring out what can be dropped, and doing the
>>> filtering - I don't have a link at this moment, but I remember coming across
>>> them when looking at Android packaging tooling.
>> I'd rather remove the complete dependency. It is only used in the addons
>> plugin in one view of the cde framework, but we actually have been
>> thinking about using more functionality in the future. This would cause
>> us to do the filtering each time.
>>
>> So, I will cancel the RC and create a new one with an extended LICENSE
>> file, right?
>>
>> Just to mention a reason why this did not happen before:
>> https://www.apache.org/dev/licensing-howto.html#alv2-dep
>>
>> <quote>
>> Bundling an Apache-2.0-licensed Dependency
>> Assuming once again that that the dependency subtree contains no bundled
>> subcomponents under other licenses and thus the ALv2 applies uniformly
>> to all files, there is no need to modify LICENSE.
> But this doesn't seem to be the case here.  The dependency subtree (the Jar)
> presumably has something licensed under those other licenses (not Apache-2.0)
> included in their Jar?
>> If the dependency supplies a NOTICE file, its contents must be analyzed
>> and the relevant portions bubbled up into the top-level NOTICE file.
>> </quote>
>>
>> Reading this with the fact in mind that the dependency is a library
>> developed and released by ASF, one can easily think that the license
>> file does not need to be changed. Isn't there only one license for a
>> released artifact at ASF?
> Anytime we prepare convenience packaging that mixes work we do at the ASF (which
> is licensed under the Apache v2 license) and other artifacts licensed under
> other licenses (icons, etc.), we are releasing an artifact which has more than
> just the Apache v2 license.  If others then incorporate our artifact, they have
> to deal with those other licenses and notices, too.
>
> This is something we need to consider when building artifacts.  Sometimes, it
> not so great a concern if we bundle lots of other things having separate
> notice/files (although it makes it a bit more difficult for end-users to
> understand their obligations), but other times, for instance, if we expect other
> developers to take our work and build other products of their own, then it
> becomes more of a concern, because those other developers will be redistributing
> their works, and they have to then do a careful analysis of all the licenses and
> notices (much as we're having to do now ...).
>
> -Marshall
>> Peter
>>
>>> -Marshall
>>>> Best,
>>>>
>>>> Peter
>>>>
>>>>> -Marshall
>>>>>
>>

Re: [VOTE] Release Apache UIMA Ruta 2.2.0 RC5

[Marshall Schor <ms...@schor.com>]

On 4/8/2014 3:40 AM, Peter Klügl wrote:
> Am 07.04.2014 15:26, schrieb Marshall Schor:
>> On 4/7/2014 8:29 AM, Peter Klügl wrote:
>>> ...
>>> Advice would be greatly appreciated.
>> I looked at the license file in that jar and it seems to have a lot of
>> additional licenses.  So, one thing to do is to copy those licenses into the top
>> level license file for your distribution.
> That would be the engine plugin artifact.
>
>> Another thing to possibly do is to "filter" the Jar to remove the parts you're
>> not using, and drop the notices/licenses for those parts (since the jar you'll
>> be distributing won't have those).
>>
>> There are tools out there for figuring out what can be dropped, and doing the
>> filtering - I don't have a link at this moment, but I remember coming across
>> them when looking at Android packaging tooling.
> I'd rather remove the complete dependency. It is only used in the addons
> plugin in one view of the cde framework, but we actually have been
> thinking about using more functionality in the future. This would cause
> us to do the filtering each time.
>
> So, I will cancel the RC and create a new one with an extended LICENSE
> file, right?
>
> Just to mention a reason why this did not happen before:
> https://www.apache.org/dev/licensing-howto.html#alv2-dep
>
> <quote>
> Bundling an Apache-2.0-licensed Dependency
> Assuming once again that that the dependency subtree contains no bundled
> subcomponents under other licenses and thus the ALv2 applies uniformly
> to all files, there is no need to modify LICENSE.
But this doesn't seem to be the case here.  The dependency subtree (the Jar)
presumably has something licensed under those other licenses (not Apache-2.0)
included in their Jar?
>
> If the dependency supplies a NOTICE file, its contents must be analyzed
> and the relevant portions bubbled up into the top-level NOTICE file.
> </quote>
>
> Reading this with the fact in mind that the dependency is a library
> developed and released by ASF, one can easily think that the license
> file does not need to be changed. Isn't there only one license for a
> released artifact at ASF?

Anytime we prepare convenience packaging that mixes work we do at the ASF (which
is licensed under the Apache v2 license) and other artifacts licensed under
other licenses (icons, etc.), we are releasing an artifact which has more than
just the Apache v2 license.  If others then incorporate our artifact, they have
to deal with those other licenses and notices, too.

This is something we need to consider when building artifacts.  Sometimes, it
not so great a concern if we bundle lots of other things having separate
notice/files (although it makes it a bit more difficult for end-users to
understand their obligations), but other times, for instance, if we expect other
developers to take our work and build other products of their own, then it
becomes more of a concern, because those other developers will be redistributing
their works, and they have to then do a careful analysis of all the licenses and
notices (much as we're having to do now ...).

-Marshall
>
> Peter
>
>> -Marshall
>>> Best,
>>>
>>> Peter
>>>
>>>> -Marshall
>>>>
>>>
>
>

Re: [VOTE] Release Apache UIMA Ruta 2.2.0 RC5

[Marshall Schor <ms...@schor.com>]

On 4/8/2014 3:47 AM, Peter Klügl wrote:
> Am 08.04.2014 09:40, schrieb Peter Klügl:
>> ...Reading this with the fact in mind that the dependency is a library
>> developed and released by ASF, one can easily think that the license
>> file does not need to be changed. Isn't there only one license for a
>> released artifact at ASF? Peter 

If the dependency is a library developed and released by the ASF, and it doesn't
require any license other than the Apache v2 license, then you don't need to
repeat that license.

However, in this case, the library artifact developers have decided (for reasons
I don't know) that they need to include licenses other than the Apache v2
license, for their distributed artifact (their JAR, which, we are, in turn,
redistributing), which, means, I think, that if we are (re)distributing their
artifact, we have to bubble up their licenses to our top level, or have an
alternative licensing statement / strategy that describes what re-bundlers of
our work would need to know/do.  

-Marshall
> Let me reword it. I thought the license file is for licenses, not for
> copyright notices. Those should go to the notice file as we do with the
> IBM or University notices.
>
> Peter
>
>
>

Re: [VOTE] Release Apache UIMA Ruta 2.2.0 RC5

[Peter Klügl <pk...@uni-wuerzburg.de>]

Am 08.04.2014 09:40, schrieb Peter Klügl:
> ...Reading this with the fact in mind that the dependency is a library
> developed and released by ASF, one can easily think that the license
> file does not need to be changed. Isn't there only one license for a
> released artifact at ASF? Peter 

Let me reword it. I thought the license file is for licenses, not for
copyright notices. Those should go to the notice file as we do with the
IBM or University notices.

Peter

Re: [VOTE] Release Apache UIMA Ruta 2.2.0 RC5

[Peter Klügl <pk...@uni-wuerzburg.de>]

Am 07.04.2014 15:26, schrieb Marshall Schor:
> On 4/7/2014 8:29 AM, Peter Klügl wrote:
>> ...
>> Advice would be greatly appreciated.
> I looked at the license file in that jar and it seems to have a lot of
> additional licenses.  So, one thing to do is to copy those licenses into the top
> level license file for your distribution.

That would be the engine plugin artifact.

>
> Another thing to possibly do is to "filter" the Jar to remove the parts you're
> not using, and drop the notices/licenses for those parts (since the jar you'll
> be distributing won't have those).
>
> There are tools out there for figuring out what can be dropped, and doing the
> filtering - I don't have a link at this moment, but I remember coming across
> them when looking at Android packaging tooling.

I'd rather remove the complete dependency. It is only used in the addons
plugin in one view of the cde framework, but we actually have been
thinking about using more functionality in the future. This would cause
us to do the filtering each time.

So, I will cancel the RC and create a new one with an extended LICENSE
file, right?

Just to mention a reason why this did not happen before:
https://www.apache.org/dev/licensing-howto.html#alv2-dep

<quote>
Bundling an Apache-2.0-licensed Dependency
Assuming once again that that the dependency subtree contains no bundled
subcomponents under other licenses and thus the ALv2 applies uniformly
to all files, there is no need to modify LICENSE.

If the dependency supplies a NOTICE file, its contents must be analyzed
and the relevant portions bubbled up into the top-level NOTICE file.
</quote>

Reading this with the fact in mind that the dependency is a library
developed and released by ASF, one can easily think that the license
file does not need to be changed. Isn't there only one license for a
released artifact at ASF?

Peter

> -Marshall
>> Best,
>>
>> Peter
>>
>>> -Marshall
>>>
>>
>>

Re: [VOTE] Release Apache UIMA Ruta 2.2.0 RC5

[Marshall Schor <ms...@schor.com>]

On 4/7/2014 8:29 AM, Peter Klügl wrote:
> Am 05.04.2014 23:02, schrieb Marshall Schor:
>> question on the license / notice files:
>>
>> The Jar for ruta-ep-engine has a notice which says, in part:
>>
>> The MersenneTwister class in package org.apache.commons.math3.random
>> includes software translated from the 2002-01-26 version of
>> the Mersenne-Twister generator written in C by Makoto Matsumoto and Takuji
>> Nishimura. Original source copyright:
>> Copyright (C) 1997 - 2002, Makoto Matsumoto and Takuji Nishimura,
>> All rights reserved
>> ===============================================================================
>> The LocalizedFormatsTest class in the unit tests is an adapted version of
>> the OrekitMessagesTest class from the orekit library distributed under the
>> terms of the Apache 2 licence. Original source copyright:
>> Copyright 2010 CS Communication & Systèmes
>> ===============================================================================
>> The complete text of licenses and disclaimers associated with the the original
>> sources enumerated above at the time of code translation are in the LICENSE.txt
>> file.
>>
>> The LICENSE file (not LICENSE.txt) file makes no mention of either of these
>> things - does it need to, or do the existing items in the license cover these?
>
> Well, I don't know.
>
> The text in the notice file was copied from the jar contained in this
> artifact. In this case it's commons-math3-3.0.jar, which contains the
> LICENSE.txt file that was referred to by the original mention. I can add the
> list of items in LICENSE.txt to our LICENSE file in a new RC or in the next
> release, but I am actually not sure if I have/need/should. I can try to reread
> the corresponding apache pages about the topic or ask on the respective
> mailing list tomorrow.
>
> Advice would be greatly appreciated.

I looked at the license file in that jar and it seems to have a lot of
additional licenses.  So, one thing to do is to copy those licenses into the top
level license file for your distribution.

Another thing to possibly do is to "filter" the Jar to remove the parts you're
not using, and drop the notices/licenses for those parts (since the jar you'll
be distributing won't have those).

There are tools out there for figuring out what can be dropped, and doing the
filtering - I don't have a link at this moment, but I remember coming across
them when looking at Android packaging tooling.

-Marshall
>
> Best,
>
> Peter
>
>> -Marshall
>>
>
>
>

Re: [VOTE] Release Apache UIMA Ruta 2.2.0 RC5

[Peter Klügl <pk...@uni-wuerzburg.de>]

Am 05.04.2014 23:02, schrieb Marshall Schor:
> question on the license / notice files:
>
> The Jar for ruta-ep-engine has a notice which says, in part:
>
> The MersenneTwister class in package org.apache.commons.math3.random
> includes software translated from the 2002-01-26 version of
> the Mersenne-Twister generator written in C by Makoto Matsumoto and Takuji
> Nishimura. Original source copyright:
> Copyright (C) 1997 - 2002, Makoto Matsumoto and Takuji Nishimura,
> All rights reserved
> ===============================================================================
> The LocalizedFormatsTest class in the unit tests is an adapted version of
> the OrekitMessagesTest class from the orekit library distributed under the
> terms of the Apache 2 licence. Original source copyright:
> Copyright 2010 CS Communication & Systèmes
> ===============================================================================
> The complete text of licenses and disclaimers associated with the the original
> sources enumerated above at the time of code translation are in the LICENSE.txt
> file.
>
> The LICENSE file (not LICENSE.txt) file makes no mention of either of these
> things - does it need to, or do the existing items in the license cover these?

Well, I don't know.

The text in the notice file was copied from the jar contained in this 
artifact. In this case it's commons-math3-3.0.jar, which contains the 
LICENSE.txt file that was referred to by the original mention. I can add 
the list of items in LICENSE.txt to our LICENSE file in a new RC or in 
the next release, but I am actually not sure if I have/need/should. I 
can try to reread the corresponding apache pages about the topic or ask 
on the respective mailing list tomorrow.

Advice would be greatly appreciated.

Best,

Peter

> -Marshall
>

Re: [VOTE] Release Apache UIMA Ruta 2.2.0 RC5

[Marshall Schor <ms...@schor.com>]

question on the license / notice files:

The Jar for ruta-ep-engine has a notice which says, in part:

The MersenneTwister class in package org.apache.commons.math3.random
includes software translated from the 2002-01-26 version of
the Mersenne-Twister generator written in C by Makoto Matsumoto and Takuji
Nishimura. Original source copyright:
Copyright (C) 1997 - 2002, Makoto Matsumoto and Takuji Nishimura,
All rights reserved
===============================================================================
The LocalizedFormatsTest class in the unit tests is an adapted version of
the OrekitMessagesTest class from the orekit library distributed under the
terms of the Apache 2 licence. Original source copyright:
Copyright 2010 CS Communication & Systèmes
===============================================================================
The complete text of licenses and disclaimers associated with the the original
sources enumerated above at the time of code translation are in the LICENSE.txt
file.

The LICENSE file (not LICENSE.txt) file makes no mention of either of these
things - does it need to, or do the existing items in the license cover these?

-Marshall

Re: [VOTE] Release Apache UIMA Ruta 2.2.0 RC5

[Peter Klügl <pk...@uni-wuerzburg.de>]

compared svn-tag with source-release - OK
deleted uima folder in .m2
mvn clean install svn-tag - OK
deleted uima folder in .m2
mvn clean install source-release - OK

checked some license/notice of artifacts(-sources) - OK
problems identified in previous reviews still occur:
license/notice javadocs of some artifacts contains mention of icon
attribution, should be fixed sometimes

installed workbench in kepler sr1 with uima features present - OK
created project and tested a simple script - OK

[X] +1 OK to release

Peter

Am 01.04.2014 10:55, schrieb Peter Klügl:
> Hi,
>
> the fifth release candidate of Apache UIMA Ruta v2.2.0 is ready for voting.
>
> Changes in RC5 since RC4:
> - fixed relative path to parent pom
> - (UIMA-3307) Ruta project references closed project
> - (UIMA-3269) Imported type system specified with broken url
> - (UIMA-3607) Improve auto-completion functionality for type system import
> - (UIMA-3352) absolute vs. relative paths in auto generated engine.xml
> - (UIMA-3147) Invisible wildcard match in Ruta should not be applied
> - (UIMA-2900) Refactor Ruta IDE validators
>
> Changes in RC4 since RC3:
> - ruta-docbook maven.deploy.skip=true
> - changed UimafitTest to work without external txt file
> - replaced backslashes in ruta-core pom
> - added syntax checks of references in EXEC action
> - enabled autocompletion on uimafit analysis engines
> - (UIMA-3668) Ruta Workbench: Load type system descriptor from maven
> dependencies
> - (UIMA-3678) Ruta: Trim Action throws Nullpointer on fully trimmed
> Annotations
> - (UIMA-3207) Investigate if all streams and scanners are closed in Ruta
> - (UIMA-3683) Ruta: Add block that stops after first applied statement
> - (UIMA-3679) Ruta documentation mentions wordlist with wrong quoting
>
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapacheuima-1014/
>
> SVN tag:
> https://svn.apache.org/repos/asf/uima/ruta/tags/ruta-2.2.0
>
> Update site:
> http://people.apache.org/~pkluegl/uima-releases/ruta-2.2.0-rc5/eclipse-update-site/ruta/
>
> Archive with all sources:
> http://people.apache.org/~pkluegl/uima-releases/ruta-2.2.0-rc5/ruta-2.2.0-source-release.zip
>
> Overall 78 issues have been fixed for this release.
> They can be found in the RELEASE_NOTES.html and here:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20UIMA%20AND%20fixVersion%20%3D%202.2.0ruta%20AND%20component%20%3D%20ruta%20ORDER%20BY%20priority%20DESC
>
> Major Changes in this Release
>
> UIMA Ruta Language and Analysis Engine:
> - Major performance improvements
> - Improved import type functionality and handling of ambiguous short names
> - Support of block extensions for rule inference adaptions
> - Options to determine where the next match should start
> - Requires at least Java 6
> - Many bug fixes
>
> UIMA Ruta Workbench:
> - Smaller improvements in many views
> - Support of mixin Java/Ruta projects
> - Many bug fixes
>
>
> ONLY FOR REVIEWING:
>
> Documentation (pdf file):
> http://people.apache.org/~pkluegl/uima-releases/ruta-2.2.0-rc5/tools.ruta.book.pdf
>
>
> Please vote on release:
>
> [ ] +1 OK to release
> [ ]  0 Don't care
> [ ] -1 Not OK to release, because ...
>
> Thanks.
>
> Peter
>