Build failed in Jenkins: UIMA-Ruta-v3 #34

[Apache Jenkins Server]

See 

--
[...truncated 2.54 MB...]
[INFO] 
[INFO] >>> cobertura-maven-plugin:2.7:cobertura (default-cli) > [cobertura]test 
@ ruta >>>
[INFO] 
[INFO] --- maven-enforcer-plugin:1.3.1:enforce (enforce-versions) @ ruta ---
[INFO] 
[INFO] --- build-helper-maven-plugin:1.8:parse-version (parse-project-version) 
@ ruta ---
[INFO] 
[INFO] --- uima-build-helper-maven-plugin:7:parse-date-time (set buildYear and 
buildMonth) @ ruta ---
[INFO] 
[INFO] --- maven-remote-resources-plugin:1.5:process (default) @ ruta ---
[INFO] artifact org.eclipse.equinox:app: checking for updates from 
eclipsePlugins
[INFO] artifact org.eclipse.equinox:app: checking for updates from central
[INFO] artifact org.eclipse.equinox:app: checking for updates from 
averbis-osgi-releases
[INFO] artifact org.eclipse.equinox:registry: checking for updates from 
eclipsePlugins
[INFO] artifact org.eclipse.equinox:registry: checking for updates from central
[INFO] artifact org.eclipse.equinox:registry: checking for updates from 
averbis-osgi-releases
[INFO] artifact org.eclipse.equinox:common: checking for updates from 
eclipsePlugins
[INFO] artifact org.eclipse.equinox:common: checking for updates from central
[INFO] artifact org.eclipse.equinox:common: checking for updates from 
averbis-osgi-releases
[INFO] artifact org.eclipse.equinox:common: checking for updates from 
eclipsePlugins
[INFO] artifact org.eclipse.equinox:common: checking for updates from central
[INFO] artifact org.eclipse.equinox:common: checking for updates from 
averbis-osgi-releases
[INFO] artifact org.eclipse.equinox:app: checking for updates from 
eclipsePlugins
[INFO] artifact org.eclipse.equinox:app: checking for updates from central
[INFO] artifact org.eclipse.equinox:app: checking for updates from 
averbis-osgi-releases
[INFO] artifact org.eclipse.equinox:registry: checking for updates from 
eclipsePlugins
[INFO] artifact org.eclipse.equinox:registry: checking for updates from central
[INFO] artifact org.eclipse.equinox:registry: checking for updates from 
averbis-osgi-releases
[INFO] artifact org.eclipse.equinox:common: checking for updates from 
eclipsePlugins
[INFO] artifact org.eclipse.equinox:common: checking for updates from central
[INFO] artifact org.eclipse.equinox:common: checking for updates from 
averbis-osgi-releases
[INFO] artifact org.eclipse.equinox:common: checking for updates from 
eclipsePlugins
[INFO] artifact org.eclipse.equinox:common: checking for updates from central
[INFO] artifact org.eclipse.equinox:common: checking for updates from 
averbis-osgi-releases
[INFO] artifact org.eclipse.equinox:app: checking for updates from 
eclipsePlugins
[INFO] artifact org.eclipse.equinox:app: checking for updates from central
[INFO] artifact org.eclipse.equinox:app: checking for updates from 
averbis-osgi-releases
[INFO] 
[INFO] --- cobertura-maven-plugin:2.7:instrument (default-cli) @ ruta ---
[INFO] Skipping cobertura mojo for project with packaging type 'pom'
[INFO] 
[INFO] <<< cobertura-maven-plugin:2.7:cobertura (default-cli) < [cobertura]test 
@ ruta <<<
[INFO] 
[INFO] --- cobertura-maven-plugin:2.7:cobertura (default-cli) @ ruta ---
[INFO] 
[INFO] >>> maven-javadoc-plugin:2.9.1:javadoc (default-cli) > generate-sources 
@ ruta >>>
[INFO] 
[INFO] --- maven-enforcer-plugin:1.3.1:enforce (enforce-versions) @ ruta ---
[INFO] 
[INFO] --- build-helper-maven-plugin:1.8:parse-version (parse-project-version) 
@ ruta ---
[INFO] 
[INFO] --- uima-build-helper-maven-plugin:7:parse-date-time (set buildYear and 
buildMonth) @ ruta ---
[WARNING] Failed to getClass for org.apache.maven.plugin.javadoc.JavadocReport
[INFO] 
[INFO] <<< maven-javadoc-plugin:2.9.1:javadoc (default-cli) < generate-sources 
@ ruta <<<
[INFO] 
[INFO] --- maven-javadoc-plugin:2.9.1:javadoc (default-cli) @ ruta ---
[INFO] 
[INFO] Reactor Summary:
[INFO] 
[INFO] Apache UIMA Ruta: ruta-parent .. SUCCESS [01:19 min]
[INFO] Apache UIMA Ruta: ruta-basic-type .. SUCCESS [01:26 min]
[INFO] Apache UIMA Ruta: ruta-typesystem .. SUCCESS [01:10 min]
[INFO] Apache UIMA Ruta: ruta-core  SUCCESS [02:33 min]
[INFO] Apache UIMA Ruta: ruta-core-ext  SUCCESS [01:02 min]
[INFO] Apache UIMA Ruta: ruta-ep-parent ... SUCCESS [05:09 min]
[INFO] Apache UIMA Ruta Eclipse: ruta-ep-engine ... SUCCESS [ 39.991 s]
[INFO] Apache UIMA Ruta Eclipse: ruta-ep-ide .. SUCCESS [05:49 min]
[INFO] Apache UIMA Ruta Eclipse: ruta-ep-ide-ui ... SUCCESS [10:02 min]
[INFO] Apache UIMA Ruta Eclipse: ruta-ep-caseditor  SUCCESS [05:37 min]
[INFO] Apache UIMA Ruta Eclipse: ruta-ep-addons ... SUCCESS [05:26 min]
[INFO] Apache UIMA Ruta Eclipse: ruta-ep-textruler  SUCCESS [06:10 min]
[INFO] Apache UIMA Ruta 

[jira] [Created] (UIMA-5700) DUCC pull-service wrapper should not always kill the process when a work-item fails

[Burn Lewis (JIRA)]

Burn Lewis created UIMA-5700:


 Summary: DUCC pull-service wrapper should not always kill the 
process when a work-item fails
 Key: UIMA-5700
 URL: https://issues.apache.org/jira/browse/UIMA-5700
 Project: UIMA
  Issue Type: Bug
  Components: DUCC
Reporter: Burn Lewis
Assignee: Jerry Cwiklik
 Fix For: 2.2.2-Ducc


Needed for an in-process pull service to prevent it from destroying everything.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Jenkins build is back to stable : UIMA-AS #552

[Apache Jenkins Server]

See 

Jenkins build is back to stable : UIMA-AS » Apache UIMA-AS: uimaj-as-activemq #552

[Apache Jenkins Server]

See 

Re: Design choices for changing type systems with loaded JCas classes [was Re: UIMAv3 & WebAnno}

[Richard Eckart de Castilho]

> Some use cases with comments:
> 
> 1) Type T loaded with features f1, f2, f3,  JCas loaded with f1, f2, f3
> Followed by: Type T loaded with features f1, f3.
> 
> This causes at the 2nd Type T commit time, the augmentation of type T with
> feature f2.
> But, the (current) impl just does an "addFeature" API call.  The result is 
> that
> without extra work, the features in the type system will be ordered as f1, f3,
> f2.  And the assigned offsets could be different. 
> 
> To fix this, the algorithm which assigns offsets will need to see if the
> corresponding JCas class (if any) has offsets already assigned, and try to use
> those.

This is why I suggested to use "JCas first": the order of the features should be
defined by the JCas (i.e. they come first) while features defined in other TSDs
get appended after that.

> 2) Type T having supertype TS; Type T has 1 feature, f1, JCas for Type T has 1
> feature f1.  TS has no features, no JCas for TS or JCas for TS has no 
> features. 
> Followed by: Type TS is loaded, having one feature (not in the JCas if there 
> is
> one for TS).
> 
> This causes the features for type T (which includes all the features of its
> supertype), to have offsets shifted down.
> For example if T has feature f1 with offset "3",  it would now have offset "4"
> (accounting for the space taken by the TS feature).

I believe this could also be resolved by using "JCas first": first all the slots
for features defined in any of the JCas classes in the inheritance hierarchy
are assigned and afterwards the features define in other TSDs are appended.

I believe that by using "JCas first", the slots for the JCas class features
are always fixed, independent of what other TSDs they are combined with.

Does "JCas first" now sound more sensible?

... or maybe I am misunderstanding something basic (which is entirely possible).

Cheers,

-- Richard

Re: Design choices for changing type systems with loaded JCas classes [was Re: UIMAv3 & WebAnno}

[Marshall Schor]

Another "failure" use case:

- Load type T, with feature f1. 
- Load JCas for type T with feature f2. 
--  (merged type T has f1, f2, used to assign offsets)

Next, load type T with features f1, and f3.
- At commit, this would be "merged" with the JCas, to give f1, f3, and f2.
- But f2 already has an offset assigned, which would break the existing assign
algorithm (which assigns sequentially in the order of the feature structures).  

To attempt to overcome this in some cases, an algorithm would be needed which
attempted to assign offsets, constrained by any existing offsets present in any
/all of the JCas Classes for this type and its supertypes.

-Marshall

On 1/10/2018 10:42 AM, Marshall Schor wrote:
> The initial implementation requires features in the type system have an 
> ordering
> that is consistent with what got assigned when the JCas was loaded.
>
> Some use cases with comments:
>
> 1) Type T loaded with features f1, f2, f3,  JCas loaded with f1, f2, f3
> Followed by: Type T loaded with features f1, f3.
>
> This causes at the 2nd Type T commit time, the augmentation of type T with
> feature f2.
> But, the (current) impl just does an "addFeature" API call.  The result is 
> that
> without extra work, the features in the type system will be ordered as f1, f3,
> f2.  And the assigned offsets could be different. 
>
> To fix this, the algorithm which assigns offsets will need to see if the
> corresponding JCas class (if any) has offsets already assigned, and try to use
> those.
>
> 2) Type T having supertype TS; Type T has 1 feature, f1, JCas for Type T has 1
> feature f1.  TS has no features, no JCas for TS or JCas for TS has no 
> features. 
> Followed by: Type TS is loaded, having one feature (not in the JCas if there 
> is
> one for TS).
>
> This causes the features for type T (which includes all the features of its
> supertype), to have offsets shifted down.
> For example if T has feature f1 with offset "3",  it would now have offset "4"
> (accounting for the space taken by the TS feature).
>
> 
>
> Because of these issues, I'm wondering if it's really worth the time and
> complexity to implement this "partial" solution, given that there are 
> "complete"
> solutions of the following form:
>
> 1) Require users doing this kind of operation to first load a "merged" type
> system, creating a maximal-featured version (at least for all types / 
> supertypes
> having user-defined JCas classes) over all type systems that will be 
> processed,
> and use that to load (for the first time) the JCas classes.  When subset type
> systems are loaded subsequently by the application, they might cause failures
> (see supertype example use-case above).  To get around that, the application
> would need to change to always use the maximal type system for all loaded 
> CASs. 
> Some deserializations allow deserializing a CAS with a subset-type-system 
> into a
> CAS with a maximal type system.
>
> 2) Require users who want to have different type systems to load them using
> different class loaders (for the JCas classes).   This should work for all 
> cases.
> ==
>
> 2 questions for the user community:
>
> A) Does the user community think this enhancement is of sufficient value, with
> all of its limitations, to be worth doing?  I could go either way on this ,
> personally.
>
> B) Is the extra work to figure out a mapping for case 1 at the top (arranging
> the ordering of features to attempt to preserve the fixed values for the 
> loaded
> JCas offsets) worth doing?  (If not done, it would still be "checked", and 
> users
> would know a situation arose needed them to fix).
> My feeling is that this is not worth the effort for the few cases it might 
> enable.
>
> -Marshall
>
> On 1/9/2018 4:53 PM, Marshall Schor wrote:
>> I did an initial implementation, ignoring Pear files.
>>
>> I think the "feature expansion" when loading PEAR-classpath specified JCas
>> classes can't reasonably be done (because by the time you lazily get around 
>> to
>> loading these, the type system is committed).
>>
>> So, I plan to have the pear loading path operate like before, with no feature
>> expansion.
>>
>> I kind of doubt this will be a real issue in actual practice (he said 
>> hopefully
>> :-) ).
>>
>> Still need to fix up some test cases, but it's looking promising...
>>
>> -Marshall
>>
>>
>> On 1/8/2018 2:47 PM, Marshall Schor wrote:
>>> In working out the details, the following difficulty emerges:
>>>
>>> In the general case, a pipeline is associated with a class loader (used to 
>>> load
>>> JCas classes).
>>> When the pipeline contains "PEARs", each pear can specify it's own class 
>>> loader,
>>> and therefore, it's own set of JCas classes.
>>>
>>> So, at type system commit time, with this proposal, it would be necessary to
>>> find all of the class loaders that Pears might be using.  This 
>>> unfortunately is
>>> not possible in general, because the 

Re: Design choices for changing type systems with loaded JCas classes [was Re: UIMAv3 & WebAnno}

[Marshall Schor]

The initial implementation requires features in the type system have an ordering
that is consistent with what got assigned when the JCas was loaded.

Some use cases with comments:

1) Type T loaded with features f1, f2, f3,  JCas loaded with f1, f2, f3
Followed by: Type T loaded with features f1, f3.

This causes at the 2nd Type T commit time, the augmentation of type T with
feature f2.
But, the (current) impl just does an "addFeature" API call.  The result is that
without extra work, the features in the type system will be ordered as f1, f3,
f2.  And the assigned offsets could be different. 

To fix this, the algorithm which assigns offsets will need to see if the
corresponding JCas class (if any) has offsets already assigned, and try to use
those.

2) Type T having supertype TS; Type T has 1 feature, f1, JCas for Type T has 1
feature f1.  TS has no features, no JCas for TS or JCas for TS has no features. 
Followed by: Type TS is loaded, having one feature (not in the JCas if there is
one for TS).

This causes the features for type T (which includes all the features of its
supertype), to have offsets shifted down.
For example if T has feature f1 with offset "3",  it would now have offset "4"
(accounting for the space taken by the TS feature).



Because of these issues, I'm wondering if it's really worth the time and
complexity to implement this "partial" solution, given that there are "complete"
solutions of the following form:

1) Require users doing this kind of operation to first load a "merged" type
system, creating a maximal-featured version (at least for all types / supertypes
having user-defined JCas classes) over all type systems that will be processed,
and use that to load (for the first time) the JCas classes.  When subset type
systems are loaded subsequently by the application, they might cause failures
(see supertype example use-case above).  To get around that, the application
would need to change to always use the maximal type system for all loaded CASs. 
Some deserializations allow deserializing a CAS with a subset-type-system into a
CAS with a maximal type system.

2) Require users who want to have different type systems to load them using
different class loaders (for the JCas classes).   This should work for all 
cases.
==

2 questions for the user community:

A) Does the user community think this enhancement is of sufficient value, with
all of its limitations, to be worth doing?  I could go either way on this ,
personally.

B) Is the extra work to figure out a mapping for case 1 at the top (arranging
the ordering of features to attempt to preserve the fixed values for the loaded
JCas offsets) worth doing?  (If not done, it would still be "checked", and users
would know a situation arose needed them to fix).
My feeling is that this is not worth the effort for the few cases it might 
enable.

-Marshall

On 1/9/2018 4:53 PM, Marshall Schor wrote:
> I did an initial implementation, ignoring Pear files.
>
> I think the "feature expansion" when loading PEAR-classpath specified JCas
> classes can't reasonably be done (because by the time you lazily get around to
> loading these, the type system is committed).
>
> So, I plan to have the pear loading path operate like before, with no feature
> expansion.
>
> I kind of doubt this will be a real issue in actual practice (he said 
> hopefully
> :-) ).
>
> Still need to fix up some test cases, but it's looking promising...
>
> -Marshall
>
>
> On 1/8/2018 2:47 PM, Marshall Schor wrote:
>> In working out the details, the following difficulty emerges:
>>
>> In the general case, a pipeline is associated with a class loader (used to 
>> load
>> JCas classes).
>> When the pipeline contains "PEARs", each pear can specify it's own class 
>> loader,
>> and therefore, it's own set of JCas classes.
>>
>> So, at type system commit time, with this proposal, it would be necessary to
>> find all of the class loaders that Pears might be using.  This unfortunately 
>> is
>> not possible in general, because the Pears are associated with a particular
>> pipeline, and you can load a type system and create a CAS without referring 
>> to a
>> particular pipeline. 
>>
>> In the current implementation, the presence of a Pear in the pipeline is
>> discovered (if and) when the pear is entered for the first time, and at that
>> time (lazily) the loading of that Pear's JCas classes happens.
>>
>> Various limitations are possible, I suppose (e.g., not allowing a Pear 
>> version
>> of JCas class to have new features, for example).
>>
>> Still thinking about this...
>>
>> -Marshall
>>
>>
>> On 1/8/2018 10:16 AM, Marshall Schor wrote:
>>> After a lot of thought, here's a proposal, along the lines Richard suggests:
>>>
>>> The basic idea is to have the JCas classes, if they exist for some type, 
>>> augment
>>> that type with features defined only in the JCas class.
>>>
>>> This augmentation would be done 

Jenkins build is back to normal : UIMA-DUCC #1305

[Apache Jenkins Server]

See 

Jenkins build is back to normal : UIMA-DUCC » Apache UIMA DUCC: uima-ducc-web #1305

[Apache Jenkins Server]

See 

[jira] [Closed] (UIMA-5699) DUCC Web Server (WS) should use Resource Manager (RM) calculated value for machine's memory available

[Lou DeGenaro (JIRA)]

 [ 
https://issues.apache.org/jira/browse/UIMA-5699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lou DeGenaro closed UIMA-5699.
--

> DUCC Web Server (WS) should use Resource Manager (RM) calculated value for 
> machine's memory available
> -
>
> Key: UIMA-5699
> URL: https://issues.apache.org/jira/browse/UIMA-5699
> Project: UIMA
>  Issue Type: Bug
>  Components: DUCC
>Reporter: Lou DeGenaro
>Assignee: Lou DeGenaro
> Fix For: 2.2.2-Ducc
>
>
> WS should use RM calculated value for mem avail on Viz page, and mem usable 
> on Machines page.  
> The present bug causes WS to flip-flop between RM calculated value and Agent 
> reported value.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (UIMA-5699) DUCC Web Server (WS) should use Resource Manager (RM) calculated value for machine's memory available

[Lou DeGenaro (JIRA)]

 [ 
https://issues.apache.org/jira/browse/UIMA-5699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lou DeGenaro resolved UIMA-5699.

Resolution: Fixed

Change set delivered.

> DUCC Web Server (WS) should use Resource Manager (RM) calculated value for 
> machine's memory available
> -
>
> Key: UIMA-5699
> URL: https://issues.apache.org/jira/browse/UIMA-5699
> Project: UIMA
>  Issue Type: Bug
>  Components: DUCC
>Reporter: Lou DeGenaro
>Assignee: Lou DeGenaro
> Fix For: 2.2.2-Ducc
>
>
> WS should use RM calculated value for mem avail on Viz page, and mem usable 
> on Machines page.  
> The present bug causes WS to flip-flop between RM calculated value and Agent 
> reported value.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Work started] (UIMA-5699) DUCC Web Server (WS) should use Resource Manager (RM) calculated value for machine's memory available

[Lou DeGenaro (JIRA)]

 [ 
https://issues.apache.org/jira/browse/UIMA-5699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Work on UIMA-5699 started by Lou DeGenaro.
--
> DUCC Web Server (WS) should use Resource Manager (RM) calculated value for 
> machine's memory available
> -
>
> Key: UIMA-5699
> URL: https://issues.apache.org/jira/browse/UIMA-5699
> Project: UIMA
>  Issue Type: Bug
>  Components: DUCC
>Reporter: Lou DeGenaro
>Assignee: Lou DeGenaro
> Fix For: 2.2.2-Ducc
>
>
> WS should use RM calculated value for mem avail on Viz page, and mem usable 
> on Machines page.  
> The present bug causes WS to flip-flop between RM calculated value and Agent 
> reported value.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (UIMA-5699) DUCC Web Server (WS) should use Resource Manager (RM) calculated value for machine's memory available

[Lou DeGenaro (JIRA)]

Lou DeGenaro created UIMA-5699:
--

 Summary: DUCC Web Server (WS) should use Resource Manager (RM) 
calculated value for machine's memory available
 Key: UIMA-5699
 URL: https://issues.apache.org/jira/browse/UIMA-5699
 Project: UIMA
  Issue Type: Bug
  Components: DUCC
Reporter: Lou DeGenaro
Assignee: Lou DeGenaro
 Fix For: 2.2.2-Ducc


WS should use RM calculated value for mem avail on Viz page, and mem usable on 
Machines page.  

The present bug causes WS to flip-flop between RM calculated value and Agent 
reported value.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)