Re: [jira] [Created] (UIMA-5694) UIMA-AS: Update README to say that mvn -U should be used for building

Normal builds with good network connectivity shouldn't need to use the -U operation. doing the -U operator makes building much slower. That's why it's usually not done; but only done when the build needs to depend on something whose "access" path to the artifact in the cloud "failed" - to

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

I perhaps overstated the problem. Here's the specifics:  if the maximal-type system for type T has features f1, f2, f3, f4, f5, and the JCas class defines all these features, then the load of that JCas class will bind those. A subsequent switch to a type system with f1, f2, will work. But a

[jira] [Created] (UIMA-5694) UIMA-AS: Update README to say that mvn -U should be used for building

Jerry Cwiklik created UIMA-5694: --- Summary: UIMA-AS: Update README to say that mvn -U should be used for building Key: UIMA-5694 URL: https://issues.apache.org/jira/browse/UIMA-5694 Project: UIMA

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

On 05.01.2018, at 21:29, Marshall Schor wrote: > > So, the only work-around I see at the moment is to use class loader isolation, > reloading the JCas classes each time. Is this something that client code would have to be aware of / to trigger? Cheers, -- Richard

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

Hi Richard, This sounds like an interesting idea - to have the JCas classes (perhaps augmented with some annotations) serve as additional type definitions. I believe that the current implementation won't work even if the maximal-feature definition was loaded first.  This is because the offsets

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

On 05.01.2018, at 17:16, Marshall Schor wrote: > > Based on Web Annot's use case, I'm thinking thorough alternatives. "WebAnno" ;) > One way to support this would be to have the user code tell the UIMA framework > that no reachable instances of JCas classes exist; the user

Re: UIMAv3 & WebAnno

Hi, > On 04.01.2018, at 22:18, Marshall Schor wrote: > > Hi Richard, > > Here's one idea: Since I thought this had been fixed a while ago, and you > seemed (previously) to get beyond this point, I'm wondering if the build you > dd > for "trunk" somehow got mixed up levels. I

[jira] [Updated] (UIMA-5656) uv3 consider enabling Java 9

[ https://issues.apache.org/jira/browse/UIMA-5656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-5656: - Fix Version/s: (was: 3.0.0SDK) > uv3 consider enabling Java 9 > >

Re: [VOTE] UIMA-AS 2.10.2 RC5

Just to make this more clear, Eddie and I together determined that the AMQ connection losses where due to long GCs in the service. This conclusion was based on evidence found in the service log and correlation with jConsole stats. Jerry On Fri, Jan 5, 2018 at 10:56 AM, Jaroslaw Cwiklik

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

Based on Web Annot's use case, I'm thinking thorough alternatives. The issue is a sequence related one, with type systems changing: 1) a type system is created, defining type T, with no features 2) a CAS is produced with that type system, causing JCas classes to be looked-up and loaded At that

Re: [VOTE] UIMA-AS 2.10.2 RC5

After reviewing the service log and looking at jConsole there are long GCs which cause connection loss and recovery. Looks like AE issue. Strange that these GCs happen if the service is idle. Someone should profile this AE to confirm where this and possibly fix the source of excessive garbage.

Re: UIMAv3 & WebAnno

I think I may have found the issue. Working on a proper fix... -Marshall On 1/3/2018 6:16 PM, Richard Eckart de Castilho wrote: > Hi again, > > I have once again switched my local environment to a UIMA v3 mode: > > - UIMA SDK v3 (3.0.1-beta-SNAPSHOT v3 branch) > - uimaFIT (3.0.0-SNAPSHOT v3

Re: [VOTE] UIMA-AS 2.10.2 RC5

- Checked signatures - OK - Tested binary with a dozen CASes - OK - Built from source & checked signatures - OK - Tested source build with a dozen CASes - OK - Spot checked README, RELEASE_NOTES, LICENSE, NOTICE, JIRAs, docs - OK - Tested TargetServiceId - OK Minor complaint - The (undocumented)