[jira] [Closed] (UIMA-5968) UIMA-DUCC: parameterize client's Jetty thread pool size

2019-01-24 Thread Jerry Cwiklik (JIRA)
[ https://issues.apache.org/jira/browse/UIMA-5968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jerry Cwiklik closed UIMA-5968. --- Resolution: Won't Fix Turns out that the HttpTaskTransportHandler already supports this feature.

[jira] [Created] (UIMA-5968) UIMA-DUCC: parameterize client's Jetty thread pool size

2019-01-24 Thread Jerry Cwiklik (JIRA)
Jerry Cwiklik created UIMA-5968: --- Summary: UIMA-DUCC: parameterize client's Jetty thread pool size Key: UIMA-5968 URL: https://issues.apache.org/jira/browse/UIMA-5968 Project: UIMA Issue Type:

Re: [VOTE] Release uimaFIT 3.0.0 rc 1

2019-01-24 Thread Marshall Schor
signatures - OK compare git tag with source-release: OK    updated the clone I already had, then switched to the release/3.0.0 branch build from sources: Javadoc warnings in several projects due to missing parameters (not a blocker) API compare: the old version is 2.1.0 - should it be 2.4.0?

Re: [VOTE] Release uimaFIT 3.0.0 rc 1

2019-01-24 Thread Marshall Schor
Putting myself in the position of a user of uimaFIT (and UIMA) v2: To upgrade myself to v3, for UIMA, I could migrate the JCas classes (if any), and then, without recompiling, just run using UIMA 3 (because UIMA 3 is "binary compatible" at the public API level (at least that was the goal :-) ). 

Re: [VOTE] Release uimaFIT 3.0.0 rc 1

2019-01-24 Thread Richard Eckart de Castilho
On 24. Jan 2019, at 16:43, Marshall Schor wrote: > > I noticed the API compare reports ( japicmp ) are being calculated using > version > 2.1.0 (dates from 2014) > Should this be uimaFIT 2.4.0? Well, it probably should. But it also doesn't matter because it is a major release anyway. It would

Re: [VOTE] Release uimaFIT 3.0.0 rc 1

2019-01-24 Thread Richard Eckart de Castilho
On 24. Jan 2019, at 16:52, Marshall Schor wrote: > > The uimaFIT examples tests fail to specify a slf4j logger to use, and the > default supplied is a "no-op" logger, which discards anything that is > attempted > to be logged. > > Is this intentional? The logging we used before defaulted to

Re: [VOTE] Release uimaFIT 3.0.0 rc 1

2019-01-24 Thread Marshall Schor
also missing in some other projects... On 1/24/2019 10:52 AM, Marshall Schor wrote: > The uimaFIT examples tests fail to specify a slf4j logger to use, and the > default supplied is a "no-op" logger, which discards anything that is > attempted > to be logged. > > Is this intentional? > > -M > >

Re: [VOTE] Release uimaFIT 3.0.0 rc 1

2019-01-24 Thread Marshall Schor
The uimaFIT examples tests fail to specify a slf4j logger to use, and the default supplied is a "no-op" logger, which discards anything that is attempted to be logged. Is this intentional? -M

Re: [VOTE] Release uimaFIT 3.0.0 rc 1

2019-01-24 Thread Marshall Schor
I noticed the API compare reports ( japicmp ) are being calculated using version 2.1.0 (dates from 2014) Should this be uimaFIT 2.4.0?

Re: [VOTE] Release uimaFIT 3.0.0 rc 1

2019-01-24 Thread Marshall Schor
starting review