You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by Marshall Schor <ms...@schor.com> on 2017/03/28 16:08:21 UTC
[VOTE] uimaj sdk 2.10.0 rc1
Hi,
uimaj-2.10.0 rc1 is posted and ready for voting.
The issues fixed are here:
https://issues.apache.org/jira/browse/UIMA/fixforversion/12338199/
The source and binary zip/tars are here:
https://dist.apache.org/repos/dist/dev/uima/uimaj/2.10.0-rc1/artifacts
The eclipse update site is here (no need to download it, you can install
directly from here)
https://dist.apache.org/repos/dist/dev/uima/uimaj/2.10.0-rc1/eclipse-update-site-uimaj
Maven artifacts are here:
https://repository.apache.org/content/repositories/orgapacheuima-1135/
SVN Tag: https://svn.apache.org/repos/asf/uima/uimaj/tags/uimaj-2.10.0/
Please vote on release:
[ ] +1 OK to release
[ ] 0 Don't care
[ ] -1 Not OK to release, because ...
Thanks.
-Marshall
Re: [VOTE][RESULT] uimaj sdk 2.10.0 rc1
Posted by Marshall Schor <ms...@schor.com>.
hmmm, seems to be (for me). Did you try clearing your browser cache?
On 4/19/2017 9:08 AM, Peter Kl�gl wrote:
> Hi,
>
>
> I noticed that the news for this release is not linked on the front page.
>
>
> Best,
>
>
> Peter
>
>
> Am 04.04.2017 um 20:46 schrieb Marshall Schor:
>> The "cannot open api-change-reports" issue is one more place I missed to set the
>> folder permissions. The file is there on linux, and you can manually set the
>> permissions on the folder, and then see things.
>>
>> I'll put in a Jira for this.
>>
>> The release passes with 3 + 1 votes: Marshall Schor, Burn Lewis, and Jaroslaw
>> Cwiklik
>>
>> -Marshall
>>
>>
>> On 4/4/2017 2:35 PM, Burn Lewis wrote:
>>> - Checked signatures - OK
>>> - Spot checked ReleaseNotes, License, Readme, Notice - OK
>>> >>>>> But cannot open the api-change reports for uimaj-core
>>> uimaj-cpe uimaj-json (unreadable directories)
>>> - Ran documentAnalyzer - OK
>>> - Installed jars in DUCC (with UIMA-AS 2.9.0) and ran a couple of UIMA &
>>> UIMA-AS jobs - OK
>>> - Built from source & checked signatures - OK
>>> - Installed those jars in DUCC and tested - OK
>>> - Tested loading external settings from the class path - OK
>>> >>>>> But in the next release should change the syntax to explicitly
>>> distinguish file from class path entries
>>> - Tested using a setting variable as part of a descriptor import - OK
>>> >>>>> But fails with UIMA-AS in the dd2spring preprocessing step.
>>>
>>> [X] +1 OK to release
>>>
>
Re: [VOTE][RESULT] uimaj sdk 2.10.0 rc1
Posted by Peter Klügl <pe...@averbis.com>.
Hi,
I noticed that the news for this release is not linked on the front page.
Best,
Peter
Am 04.04.2017 um 20:46 schrieb Marshall Schor:
> The "cannot open api-change-reports" issue is one more place I missed to set the
> folder permissions. The file is there on linux, and you can manually set the
> permissions on the folder, and then see things.
>
> I'll put in a Jira for this.
>
> The release passes with 3 + 1 votes: Marshall Schor, Burn Lewis, and Jaroslaw
> Cwiklik
>
> -Marshall
>
>
> On 4/4/2017 2:35 PM, Burn Lewis wrote:
>> - Checked signatures - OK
>> - Spot checked ReleaseNotes, License, Readme, Notice - OK
>> >>>>> But cannot open the api-change reports for uimaj-core
>> uimaj-cpe uimaj-json (unreadable directories)
>> - Ran documentAnalyzer - OK
>> - Installed jars in DUCC (with UIMA-AS 2.9.0) and ran a couple of UIMA &
>> UIMA-AS jobs - OK
>> - Built from source & checked signatures - OK
>> - Installed those jars in DUCC and tested - OK
>> - Tested loading external settings from the class path - OK
>> >>>>> But in the next release should change the syntax to explicitly
>> distinguish file from class path entries
>> - Tested using a setting variable as part of a descriptor import - OK
>> >>>>> But fails with UIMA-AS in the dd2spring preprocessing step.
>>
>> [X] +1 OK to release
>>
Re: [VOTE][RESULT] uimaj sdk 2.10.0 rc1
Posted by Marshall Schor <ms...@schor.com>.
The "cannot open api-change-reports" issue is one more place I missed to set the
folder permissions. The file is there on linux, and you can manually set the
permissions on the folder, and then see things.
I'll put in a Jira for this.
The release passes with 3 + 1 votes: Marshall Schor, Burn Lewis, and Jaroslaw
Cwiklik
-Marshall
On 4/4/2017 2:35 PM, Burn Lewis wrote:
> - Checked signatures - OK
> - Spot checked ReleaseNotes, License, Readme, Notice - OK
> >>>>> But cannot open the api-change reports for uimaj-core
> uimaj-cpe uimaj-json (unreadable directories)
> - Ran documentAnalyzer - OK
> - Installed jars in DUCC (with UIMA-AS 2.9.0) and ran a couple of UIMA &
> UIMA-AS jobs - OK
> - Built from source & checked signatures - OK
> - Installed those jars in DUCC and tested - OK
> - Tested loading external settings from the class path - OK
> >>>>> But in the next release should change the syntax to explicitly
> distinguish file from class path entries
> - Tested using a setting variable as part of a descriptor import - OK
> >>>>> But fails with UIMA-AS in the dd2spring preprocessing step.
>
> [X] +1 OK to release
>
Re: [VOTE] uimaj sdk 2.10.0 rc1
Posted by Burn Lewis <bu...@gmail.com>.
- Checked signatures - OK
- Spot checked ReleaseNotes, License, Readme, Notice - OK
>>>>> But cannot open the api-change reports for uimaj-core
uimaj-cpe uimaj-json (unreadable directories)
- Ran documentAnalyzer - OK
- Installed jars in DUCC (with UIMA-AS 2.9.0) and ran a couple of UIMA &
UIMA-AS jobs - OK
- Built from source & checked signatures - OK
- Installed those jars in DUCC and tested - OK
- Tested loading external settings from the class path - OK
>>>>> But in the next release should change the syntax to explicitly
distinguish file from class path entries
- Tested using a setting variable as part of a descriptor import - OK
>>>>> But fails with UIMA-AS in the dd2spring preprocessing step.
[X] +1 OK to release
Re: [VOTE] uimaj sdk 2.10.0 rc1
Posted by Marshall Schor <ms...@schor.com>.
In this case, I would be fine not holding up 2.10.0 release, along the lines
Richard suggested, stating that the loading of external overrides from the
classpath (new this release) will be changing in the next release.
Burn, if you agree, please consider voting on the release :-)
-Marshall
On 4/4/2017 10:04 AM, Burn Lewis wrote:
> Class-/data-path loading of external settings files is not in 2.9.0 ... it
> is new in 2.10.0.
>
> Burn
>
> On Tue, Apr 4, 2017 at 9:54 AM, Marshall Schor <ms...@schor.com> wrote:
>
>> just to be clear, this last discussion thread topic about changing the
>> interpretation of -DUimaEternalOverrides would result in a breaking change
>> from
>> 2.9.0 - that is - this is already in the 2.9.0 implementation, is this
>> correct?
>>
>> -Marshall
>>
>>
>> On 4/4/2017 8:35 AM, Burn Lewis wrote:
>>> Certainly. I don't want to rush this change through without discussion.
>>> One drawback to this proposed syntax is that it could break an existing
>>> application .... if a settings file was specified as *"foo.settings"*
>> then
>>> instead of being loaded from the current directory the class path would
>> be
>>> searched for *"foo.settings.settings"*. It would have to be changed to
>>> *"./foo.settings"* to get the original behavior.
>>>
>>> Burn
>>>
>>> On Tue, Apr 4, 2017 at 7:55 AM, Richard Eckart de Castilho <
>> rec@apache.org>
>>> wrote:
>>>
>>>> Would you be ok with releasing RC1 with the note that this external
>>>> overrides
>>>> behavior will be changed in the next release *without* introducing a
>> flag
>>>> that
>>>> restore the RC1 behavior (i.e. a potentially breaking change)?
>>>>
>>>> -- Richard
>>>>
>>>>> On 04.04.2017, at 00:32, Burn Lewis <bu...@gmail.com> wrote:
>>>>>
>>>>> The other issue is what I now believe is a poor design choice I made in
>>>>> Jira 5208 which lets an external overrides settings file be loaded from
>>>> the
>>>>> class path or data path. Currently if the file name is relative but
>> not
>>>>> found in the filesystem the class path and data path are searched. A
>>>>> cleaner design would be to follow the same convention used for
>> importing
>>>>> descriptors by name, i.e. use the java class notation to indicate that
>>>> the
>>>>> class path & data path must be searched (after replacing "." by "/" and
>>>>> adding ".settings".) The presence of a "/" in a file name would imply
>> a
>>>>> filesystem lookup.
>>>>>
>>>>> Thus a specification of *-DUimaEternalOverries=abc/
>>>> test.settings,d.e.f.test
>>>>> *would load the first file from the filesystem and load the second as
>>>>> *d/e/f/test.settings* from the class path or data path. The current
>>>>> implementation makes it possible to silently change a program's
>>>> parameters
>>>>> by merely adding a file to the filesystem that replaces one that is
>>>> usually
>>>>> loaded from the class path ... perhaps not a desirable feature.
>>>>>
>>>>> Since this is not a severe problem I don't feel I can justify voting
>> rc1
>>>>> down so I'll hold off until I have a potential fix, and will wait for
>>>> other
>>>>> comments.
>>
Re: [VOTE] uimaj sdk 2.10.0 rc1
Posted by Burn Lewis <bu...@gmail.com>.
Class-/data-path loading of external settings files is not in 2.9.0 ... it
is new in 2.10.0.
Burn
On Tue, Apr 4, 2017 at 9:54 AM, Marshall Schor <ms...@schor.com> wrote:
> just to be clear, this last discussion thread topic about changing the
> interpretation of -DUimaEternalOverrides would result in a breaking change
> from
> 2.9.0 - that is - this is already in the 2.9.0 implementation, is this
> correct?
>
> -Marshall
>
>
> On 4/4/2017 8:35 AM, Burn Lewis wrote:
> > Certainly. I don't want to rush this change through without discussion.
> > One drawback to this proposed syntax is that it could break an existing
> > application .... if a settings file was specified as *"foo.settings"*
> then
> > instead of being loaded from the current directory the class path would
> be
> > searched for *"foo.settings.settings"*. It would have to be changed to
> > *"./foo.settings"* to get the original behavior.
> >
> > Burn
> >
> > On Tue, Apr 4, 2017 at 7:55 AM, Richard Eckart de Castilho <
> rec@apache.org>
> > wrote:
> >
> >> Would you be ok with releasing RC1 with the note that this external
> >> overrides
> >> behavior will be changed in the next release *without* introducing a
> flag
> >> that
> >> restore the RC1 behavior (i.e. a potentially breaking change)?
> >>
> >> -- Richard
> >>
> >>> On 04.04.2017, at 00:32, Burn Lewis <bu...@gmail.com> wrote:
> >>>
> >>> The other issue is what I now believe is a poor design choice I made in
> >>> Jira 5208 which lets an external overrides settings file be loaded from
> >> the
> >>> class path or data path. Currently if the file name is relative but
> not
> >>> found in the filesystem the class path and data path are searched. A
> >>> cleaner design would be to follow the same convention used for
> importing
> >>> descriptors by name, i.e. use the java class notation to indicate that
> >> the
> >>> class path & data path must be searched (after replacing "." by "/" and
> >>> adding ".settings".) The presence of a "/" in a file name would imply
> a
> >>> filesystem lookup.
> >>>
> >>> Thus a specification of *-DUimaEternalOverries=abc/
> >> test.settings,d.e.f.test
> >>> *would load the first file from the filesystem and load the second as
> >>> *d/e/f/test.settings* from the class path or data path. The current
> >>> implementation makes it possible to silently change a program's
> >> parameters
> >>> by merely adding a file to the filesystem that replaces one that is
> >> usually
> >>> loaded from the class path ... perhaps not a desirable feature.
> >>>
> >>> Since this is not a severe problem I don't feel I can justify voting
> rc1
> >>> down so I'll hold off until I have a potential fix, and will wait for
> >> other
> >>> comments.
> >>
>
>
Re: [VOTE] uimaj sdk 2.10.0 rc1
Posted by Marshall Schor <ms...@schor.com>.
just to be clear, this last discussion thread topic about changing the
interpretation of -DUimaEternalOverrides would result in a breaking change from
2.9.0 - that is - this is already in the 2.9.0 implementation, is this correct?
-Marshall
On 4/4/2017 8:35 AM, Burn Lewis wrote:
> Certainly. I don't want to rush this change through without discussion.
> One drawback to this proposed syntax is that it could break an existing
> application .... if a settings file was specified as *"foo.settings"* then
> instead of being loaded from the current directory the class path would be
> searched for *"foo.settings.settings"*. It would have to be changed to
> *"./foo.settings"* to get the original behavior.
>
> Burn
>
> On Tue, Apr 4, 2017 at 7:55 AM, Richard Eckart de Castilho <re...@apache.org>
> wrote:
>
>> Would you be ok with releasing RC1 with the note that this external
>> overrides
>> behavior will be changed in the next release *without* introducing a flag
>> that
>> restore the RC1 behavior (i.e. a potentially breaking change)?
>>
>> -- Richard
>>
>>> On 04.04.2017, at 00:32, Burn Lewis <bu...@gmail.com> wrote:
>>>
>>> The other issue is what I now believe is a poor design choice I made in
>>> Jira 5208 which lets an external overrides settings file be loaded from
>> the
>>> class path or data path. Currently if the file name is relative but not
>>> found in the filesystem the class path and data path are searched. A
>>> cleaner design would be to follow the same convention used for importing
>>> descriptors by name, i.e. use the java class notation to indicate that
>> the
>>> class path & data path must be searched (after replacing "." by "/" and
>>> adding ".settings".) The presence of a "/" in a file name would imply a
>>> filesystem lookup.
>>>
>>> Thus a specification of *-DUimaEternalOverries=abc/
>> test.settings,d.e.f.test
>>> *would load the first file from the filesystem and load the second as
>>> *d/e/f/test.settings* from the class path or data path. The current
>>> implementation makes it possible to silently change a program's
>> parameters
>>> by merely adding a file to the filesystem that replaces one that is
>> usually
>>> loaded from the class path ... perhaps not a desirable feature.
>>>
>>> Since this is not a severe problem I don't feel I can justify voting rc1
>>> down so I'll hold off until I have a potential fix, and will wait for
>> other
>>> comments.
>>
Re: [VOTE] uimaj sdk 2.10.0 rc1
Posted by Burn Lewis <bu...@gmail.com>.
Certainly. I don't want to rush this change through without discussion.
One drawback to this proposed syntax is that it could break an existing
application .... if a settings file was specified as *"foo.settings"* then
instead of being loaded from the current directory the class path would be
searched for *"foo.settings.settings"*. It would have to be changed to
*"./foo.settings"* to get the original behavior.
Burn
On Tue, Apr 4, 2017 at 7:55 AM, Richard Eckart de Castilho <re...@apache.org>
wrote:
> Would you be ok with releasing RC1 with the note that this external
> overrides
> behavior will be changed in the next release *without* introducing a flag
> that
> restore the RC1 behavior (i.e. a potentially breaking change)?
>
> -- Richard
>
> > On 04.04.2017, at 00:32, Burn Lewis <bu...@gmail.com> wrote:
> >
> > The other issue is what I now believe is a poor design choice I made in
> > Jira 5208 which lets an external overrides settings file be loaded from
> the
> > class path or data path. Currently if the file name is relative but not
> > found in the filesystem the class path and data path are searched. A
> > cleaner design would be to follow the same convention used for importing
> > descriptors by name, i.e. use the java class notation to indicate that
> the
> > class path & data path must be searched (after replacing "." by "/" and
> > adding ".settings".) The presence of a "/" in a file name would imply a
> > filesystem lookup.
> >
> > Thus a specification of *-DUimaEternalOverries=abc/
> test.settings,d.e.f.test
> > *would load the first file from the filesystem and load the second as
> > *d/e/f/test.settings* from the class path or data path. The current
> > implementation makes it possible to silently change a program's
> parameters
> > by merely adding a file to the filesystem that replaces one that is
> usually
> > loaded from the class path ... perhaps not a desirable feature.
> >
> > Since this is not a severe problem I don't feel I can justify voting rc1
> > down so I'll hold off until I have a potential fix, and will wait for
> other
> > comments.
>
>
Re: [VOTE] uimaj sdk 2.10.0 rc1
Posted by Richard Eckart de Castilho <re...@apache.org>.
Would you be ok with releasing RC1 with the note that this external overrides
behavior will be changed in the next release *without* introducing a flag that
restore the RC1 behavior (i.e. a potentially breaking change)?
-- Richard
> On 04.04.2017, at 00:32, Burn Lewis <bu...@gmail.com> wrote:
>
> The other issue is what I now believe is a poor design choice I made in
> Jira 5208 which lets an external overrides settings file be loaded from the
> class path or data path. Currently if the file name is relative but not
> found in the filesystem the class path and data path are searched. A
> cleaner design would be to follow the same convention used for importing
> descriptors by name, i.e. use the java class notation to indicate that the
> class path & data path must be searched (after replacing "." by "/" and
> adding ".settings".) The presence of a "/" in a file name would imply a
> filesystem lookup.
>
> Thus a specification of *-DUimaEternalOverries=abc/test.settings,d.e.f.test
> *would load the first file from the filesystem and load the second as
> *d/e/f/test.settings* from the class path or data path. The current
> implementation makes it possible to silently change a program's parameters
> by merely adding a file to the filesystem that replaces one that is usually
> loaded from the class path ... perhaps not a desirable feature.
>
> Since this is not a severe problem I don't feel I can justify voting rc1
> down so I'll hold off until I have a potential fix, and will wait for other
> comments.
Re: [VOTE] uimaj sdk 2.10.0 rc1
Posted by Burn Lewis <bu...@gmail.com>.
My tests using an external variable as part of the value of an import's
name or location attribute have been successful. The problem is with a
UIMA-AS deployment of such an aggregate ... this fails when dd2spring
processes the aggregate, as at this stage the external override settings
have not been loaded. So this is not a 2.10.0 problem .... UIMA-AS will
have to be updated to make use of this feature.
The other issue is what I now believe is a poor design choice I made in
Jira 5208 which lets an external overrides settings file be loaded from the
class path or data path. Currently if the file name is relative but not
found in the filesystem the class path and data path are searched. A
cleaner design would be to follow the same convention used for importing
descriptors by name, i.e. use the java class notation to indicate that the
class path & data path must be searched (after replacing "." by "/" and
adding ".settings".) The presence of a "/" in a file name would imply a
filesystem lookup.
Thus a specification of *-DUimaEternalOverries=abc/test.settings,d.e.f.test
*would load the first file from the filesystem and load the second as
*d/e/f/test.settings* from the class path or data path. The current
implementation makes it possible to silently change a program's parameters
by merely adding a file to the filesystem that replaces one that is usually
loaded from the class path ... perhaps not a desirable feature.
Since this is not a severe problem I don't feel I can justify voting rc1
down so I'll hold off until I have a potential fix, and will wait for other
comments.
Burn
On Mon, Apr 3, 2017 at 11:50 AM, Marshall Schor <ms...@schor.com> wrote:
> Burn has found a potential issue with the new feature he added allowing
> import
> statements to have variable parts substituted from external resource
> settings.
> This may lead to cancelling this vote in favor of a fix in for RC2.
>
> The issue seems to be two fold - one is the exact syntax of the import, in
> various contexts, and the other is it seems sometimes the external
> resources may
> not have been loaded at the time the import is being resolved.
>
> This latter could perhaps be "fixed" by having a boolean that remembers if
> the
> imports have been loaded, and if not, load them just-in-time.
>
> -Marshall
>
> On 3/28/2017 12:08 PM, Marshall Schor wrote:
> > Hi,
> >
> > uimaj-2.10.0 rc1 is posted and ready for voting.
> >
> > The issues fixed are here:
> > https://issues.apache.org/jira/browse/UIMA/fixforversion/12338199/
> >
> > The source and binary zip/tars are here:
> > https://dist.apache.org/repos/dist/dev/uima/uimaj/2.10.0-rc1/artifacts
> >
> > The eclipse update site is here (no need to download it, you can install
> > directly from here)
> > https://dist.apache.org/repos/dist/dev/uima/uimaj/2.10.0-
> rc1/eclipse-update-site-uimaj
> >
> > Maven artifacts are here:
> > https://repository.apache.org/content/repositories/orgapacheuima-1135/
> >
> > SVN Tag: https://svn.apache.org/repos/asf/uima/uimaj/tags/uimaj-2.10.0/
> >
> > Please vote on release:
> >
> > [ ] +1 OK to release
> > [ ] 0 Don't care
> > [ ] -1 Not OK to release, because ...
> >
> > Thanks.
> >
> > -Marshall
> >
> >
>
>
Re: [VOTE] uimaj sdk 2.10.0 rc1
Posted by Marshall Schor <ms...@schor.com>.
Burn has found a potential issue with the new feature he added allowing import
statements to have variable parts substituted from external resource settings.
This may lead to cancelling this vote in favor of a fix in for RC2.
The issue seems to be two fold - one is the exact syntax of the import, in
various contexts, and the other is it seems sometimes the external resources may
not have been loaded at the time the import is being resolved.
This latter could perhaps be "fixed" by having a boolean that remembers if the
imports have been loaded, and if not, load them just-in-time.
-Marshall
On 3/28/2017 12:08 PM, Marshall Schor wrote:
> Hi,
>
> uimaj-2.10.0 rc1 is posted and ready for voting.
>
> The issues fixed are here:
> https://issues.apache.org/jira/browse/UIMA/fixforversion/12338199/
>
> The source and binary zip/tars are here:
> https://dist.apache.org/repos/dist/dev/uima/uimaj/2.10.0-rc1/artifacts
>
> The eclipse update site is here (no need to download it, you can install
> directly from here)
> https://dist.apache.org/repos/dist/dev/uima/uimaj/2.10.0-rc1/eclipse-update-site-uimaj
>
> Maven artifacts are here:
> https://repository.apache.org/content/repositories/orgapacheuima-1135/
>
> SVN Tag: https://svn.apache.org/repos/asf/uima/uimaj/tags/uimaj-2.10.0/
>
> Please vote on release:
>
> [ ] +1 OK to release
> [ ] 0 Don't care
> [ ] -1 Not OK to release, because ...
>
> Thanks.
>
> -Marshall
>
>
Re: [VOTE] uimaj sdk 2.10.0 rc1
Posted by Jaroslaw Cwiklik <ui...@gmail.com>.
- Spot checked signatures - OK
- Built from source - OK
- Checked ReleaseNotes, License, Readme, Notice - OK
- Installed UIMA plugins into eclipse Neon - OK
- Ran documentAnalyzer - OK
- Installed new UIMA 2.10.0 SDK jars into UIMA-AS 2.9.0 and
ran runRemoteAsynchAE - OK
[X] +1 OK to release
On Wed, Mar 29, 2017 at 11:15 AM, Marshall Schor <ms...@schor.com> wrote:
> signatures OK
>
> compare source-release with tag OK
>
> build from sources OK
>
> installed from binary distribution, ran adjust example paths, ran doc
> analyzer,
> looked at results with viewer OK
>
> issues-fixed: OK
>
> api change report: OK
>
> install into Eclipse, make a type system descriptor in a new project, run
> jcasgen, OK
>
> License Notice - no change from 2.9.0.
>
> Spot check repository.apache.org: OK
>
> [X] +1 OK to release
>
> -Marshall Schor
>
> On 3/28/2017 12:08 PM, Marshall Schor wrote:
> > Hi,
> >
> > uimaj-2.10.0 rc1 is posted and ready for voting.
> >
> > The issues fixed are here:
> > https://issues.apache.org/jira/browse/UIMA/fixforversion/12338199/
> >
> > The source and binary zip/tars are here:
> > https://dist.apache.org/repos/dist/dev/uima/uimaj/2.10.0-rc1/artifacts
> >
> > The eclipse update site is here (no need to download it, you can install
> > directly from here)
> > https://dist.apache.org/repos/dist/dev/uima/uimaj/2.10.0-
> rc1/eclipse-update-site-uimaj
> >
> > Maven artifacts are here:
> > https://repository.apache.org/content/repositories/orgapacheuima-1135/
> >
> > SVN Tag: https://svn.apache.org/repos/asf/uima/uimaj/tags/uimaj-2.10.0/
> >
> > Please vote on release:
> >
> > [ ] +1 OK to release
> > [ ] 0 Don't care
> > [ ] -1 Not OK to release, because ...
> >
> > Thanks.
> >
> > -Marshall
> >
> >
>
>
Re: [VOTE] uimaj sdk 2.10.0 rc1
Posted by Marshall Schor <ms...@schor.com>.
signatures OK
compare source-release with tag OK
build from sources OK
installed from binary distribution, ran adjust example paths, ran doc analyzer,
looked at results with viewer OK
issues-fixed: OK
api change report: OK
install into Eclipse, make a type system descriptor in a new project, run
jcasgen, OK
License Notice - no change from 2.9.0.
Spot check repository.apache.org: OK
[X] +1 OK to release
-Marshall Schor
On 3/28/2017 12:08 PM, Marshall Schor wrote:
> Hi,
>
> uimaj-2.10.0 rc1 is posted and ready for voting.
>
> The issues fixed are here:
> https://issues.apache.org/jira/browse/UIMA/fixforversion/12338199/
>
> The source and binary zip/tars are here:
> https://dist.apache.org/repos/dist/dev/uima/uimaj/2.10.0-rc1/artifacts
>
> The eclipse update site is here (no need to download it, you can install
> directly from here)
> https://dist.apache.org/repos/dist/dev/uima/uimaj/2.10.0-rc1/eclipse-update-site-uimaj
>
> Maven artifacts are here:
> https://repository.apache.org/content/repositories/orgapacheuima-1135/
>
> SVN Tag: https://svn.apache.org/repos/asf/uima/uimaj/tags/uimaj-2.10.0/
>
> Please vote on release:
>
> [ ] +1 OK to release
> [ ] 0 Don't care
> [ ] -1 Not OK to release, because ...
>
> Thanks.
>
> -Marshall
>
>