[jira] Created: (UIMA-1610) add a changeVersion build tool to handle changes needed in sandbox release
add a changeVersion build tool to handle changes needed in sandbox release --- Key: UIMA-1610 URL: https://issues.apache.org/jira/browse/UIMA-1610 Project: UIMA Issue Type: Improvement Components: Build, Packaging and Test, Sandbox Reporter: Marshall Schor Assignee: Marshall Schor model after existing changeVersion ant scripts in uimaj-distr and uima-as-distr -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (UIMA-1149) [UIMA-AS] fix potential thread safety issue with flow controller code
[ https://issues.apache.org/jira/browse/UIMA-1149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jerry Cwiklik reopened UIMA-1149: - Assignee: Jerry Cwiklik Synchronize access to FlowContainer next() method. This method executes user code that may not be thread safe [UIMA-AS] fix potential thread safety issue with flow controller code - Key: UIMA-1149 URL: https://issues.apache.org/jira/browse/UIMA-1149 Project: UIMA Issue Type: Bug Components: Async Scaleout Affects Versions: 2.2.2AS Reporter: Marshall Schor Assignee: Jerry Cwiklik Priority: Minor Fix For: 2.3AS Attachments: uimaj-as-core-UIMA-1149-patch.txt The general contract regarding threading for user-written UIMA components is that components do not have to be written to be thread-safe, or, more precisely, the framework guarantees it will not call an instance of a user-written component class on multiple threads at the same time. See http://incubator.apache.org/uima/downloads/releaseDocs/2.2.2-incubating/docs/html/tutorials_and_users_guides/tutorials_and_users_guides.html#ugr.tug.aae.contract_for_annotator_methods This is intended to make writing UIMA components by our user community easier, and to eliminate many hard-to-diagnose issues that could occur otherwise. The FlowController main object class, the one that is specified in the custom flow control specification for an aggregate, in UIMA-AS, can be (we think, but to be investigated :-) ) be called on multiple threads at the same time, in the current implementation. This Jira is to fix this, by synchronizing on the flow controller object so that users don't have to write thread safe implementations of this class. Also, the docs in the above referenced manual should be updated to include the flow controller object in the set of objects where the framework guarantees that instances of this object will not be called on multiple threads at the same time. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-1149) [UIMA-AS] fix potential thread safety issue with flow controller code
[ https://issues.apache.org/jira/browse/UIMA-1149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jerry Cwiklik closed UIMA-1149. --- Resolution: Fixed [UIMA-AS] fix potential thread safety issue with flow controller code - Key: UIMA-1149 URL: https://issues.apache.org/jira/browse/UIMA-1149 Project: UIMA Issue Type: Bug Components: Async Scaleout Affects Versions: 2.2.2AS Reporter: Marshall Schor Assignee: Jerry Cwiklik Priority: Minor Fix For: 2.3AS Attachments: uimaj-as-core-UIMA-1149-patch.txt The general contract regarding threading for user-written UIMA components is that components do not have to be written to be thread-safe, or, more precisely, the framework guarantees it will not call an instance of a user-written component class on multiple threads at the same time. See http://incubator.apache.org/uima/downloads/releaseDocs/2.2.2-incubating/docs/html/tutorials_and_users_guides/tutorials_and_users_guides.html#ugr.tug.aae.contract_for_annotator_methods This is intended to make writing UIMA components by our user community easier, and to eliminate many hard-to-diagnose issues that could occur otherwise. The FlowController main object class, the one that is specified in the custom flow control specification for an aggregate, in UIMA-AS, can be (we think, but to be investigated :-) ) be called on multiple threads at the same time, in the current implementation. This Jira is to fix this, by synchronizing on the flow controller object so that users don't have to write thread safe implementations of this class. Also, the docs in the above referenced manual should be updated to include the flow controller object in the set of objects where the framework guarantees that instances of this object will not be called on multiple threads at the same time. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (UIMA-1065) CFE - configurable feature extrator for UIMA annotation comparison, evaluation, testing, generation of machine learning features
[ https://issues.apache.org/jira/browse/UIMA-1065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sominsky updated UIMA-1065: Attachment: CFE-patch-20091012.txt changes to generate 1.5 compliant source code for XMLBeans. replaced occurrences of StringBuffer with StringBuilder CFE - configurable feature extrator for UIMA annotation comparison, evaluation, testing, generation of machine learning features Key: UIMA-1065 URL: https://issues.apache.org/jira/browse/UIMA-1065 Project: UIMA Issue Type: New Feature Components: Tools Reporter: Igor Sominsky Assignee: Marshall Schor Priority: Minor Attachments: CFE-20080908.zip, CFE-20080908.zip.md5, CFE-patch-20090827.txt, CFE-patch-20090828.txt, CFE-patch-20090930.txt, CFE-patch-20091002.txt, CFE-patch-20091004.txt, CFE-patch-20091012.txt, CFE_sominsky-A4.pdf, CFE_UG-images.zip, CFE_UG-patch-20091008.txt, CFE_UG_v9.pdf, images.zip CFE - configurable feature extrator for UIMA annotation comparison, evaluation of performance metrics such as precision/recall/f-score, regression testing, generation of machine learning features. It provides Feature Extraction Specification language (FESL), that specifies rules for feature extraction. The criteria for the extraction could be customized by multiple conditions written in FESL in normal disjunctive form. Extracted features can be output into a file or CAS. Extractor can be implemented as CAS consumer of TAE -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (UIMA-1609) binary assembly wrongly including FOP files
[ https://issues.apache.org/jira/browse/UIMA-1609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor reopened UIMA-1609: -- fix for other assemblies (uima-as) binary assembly wrongly including FOP files --- Key: UIMA-1609 URL: https://issues.apache.org/jira/browse/UIMA-1609 Project: UIMA Issue Type: Bug Components: Build, Packaging and Test Reporter: Marshall Schor Assignee: Marshall Schor Priority: Minor Fix For: 2.3 The uima-docbook-tools project downloads some FOP components when used to build documentation. These are not to be distributed with UIMA - they are downloaded as needed. the fop-config.xml file is needed, though. Fix assembly specs -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-1609) binary assembly wrongly including FOP files
[ https://issues.apache.org/jira/browse/UIMA-1609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor closed UIMA-1609. Resolution: Fixed Fix Version/s: 2.3AS 2.3S binary assembly wrongly including FOP files --- Key: UIMA-1609 URL: https://issues.apache.org/jira/browse/UIMA-1609 Project: UIMA Issue Type: Bug Components: Build, Packaging and Test Reporter: Marshall Schor Assignee: Marshall Schor Priority: Minor Fix For: 2.3S, 2.3, 2.3AS The uima-docbook-tools project downloads some FOP components when used to build documentation. These are not to be distributed with UIMA - they are downloaded as needed. the fop-config.xml file is needed, though. Fix assembly specs -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-1609) binary assembly wrongly including FOP files
[ https://issues.apache.org/jira/browse/UIMA-1609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor closed UIMA-1609. Resolution: Fixed binary assembly wrongly including FOP files --- Key: UIMA-1609 URL: https://issues.apache.org/jira/browse/UIMA-1609 Project: UIMA Issue Type: Bug Components: Build, Packaging and Test Reporter: Marshall Schor Assignee: Marshall Schor Priority: Minor Fix For: 2.3S, 2.3, 2.3AS The uima-docbook-tools project downloads some FOP components when used to build documentation. These are not to be distributed with UIMA - they are downloaded as needed. the fop-config.xml file is needed, though. Fix assembly specs -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (UIMA-1609) binary assembly wrongly including FOP files
[ https://issues.apache.org/jira/browse/UIMA-1609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor reopened UIMA-1609: -- binary assembly wrongly including FOP files --- Key: UIMA-1609 URL: https://issues.apache.org/jira/browse/UIMA-1609 Project: UIMA Issue Type: Bug Components: Build, Packaging and Test Reporter: Marshall Schor Assignee: Marshall Schor Priority: Minor Fix For: 2.3S, 2.3, 2.3AS The uima-docbook-tools project downloads some FOP components when used to build documentation. These are not to be distributed with UIMA - they are downloaded as needed. the fop-config.xml file is needed, though. Fix assembly specs -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (UIMA-1611) UimacppServiceControlled need to implement isStopped()
UimacppServiceControlled need to implement isStopped() -- Key: UIMA-1611 URL: https://issues.apache.org/jira/browse/UIMA-1611 Project: UIMA Issue Type: Bug Reporter: Bhavani Iyer Required in order for UIMA_Service to undeploy and shutdown when handling a stop or quiesce and stop command. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-1612) Removed Unused classes from UIMA AS org.apache.uima.aae.error.handler package
[ https://issues.apache.org/jira/browse/UIMA-1612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jerry Cwiklik closed UIMA-1612. --- Resolution: Fixed Removed dead classes from org.apache.uima.aae.error.handler package. Removed Unused classes from UIMA AS org.apache.uima.aae.error.handler package - Key: UIMA-1612 URL: https://issues.apache.org/jira/browse/UIMA-1612 Project: UIMA Issue Type: Improvement Components: Async Scaleout Reporter: Jerry Cwiklik Assignee: Jerry Cwiklik Priority: Minor Fix For: 2.3AS org.apache.uima.aae.error.handler package contains a number of ErrorHandler classes that are not used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (UIMA-1613) run Rat consistently for all maven assemblies
run Rat consistently for all maven assemblies - Key: UIMA-1613 URL: https://issues.apache.org/jira/browse/UIMA-1613 Project: UIMA Issue Type: Improvement Components: Async Scaleout, Build, Packaging and Test, Core Java Framework, Sandbox Reporter: Marshall Schor Assignee: Marshall Schor Priority: Minor Fix For: 2.3S, 2.3, 2.3AS Make all assemblies and RAT testing of those assemblies work the same way (convention over configuration). Have common parent POM concerned with doing assemblies, and have the 3 distribution poms (that build the base, uima-as, and sandbox distributions) use this as a common parent. Builds are done in the package lifecycle. After build is done, in the verify lifecycle (just before install), run the RAT tool. Incorporate into the distribution POMs the set of RAT exclusions. Include a step of unpacking the assemblies (because the RAT tool doesn't work on zips). Running mvn install will now do the assemblies and do the RAT testing. This effectively automates future RAT testing. Running mvn install on the new superPom for distributions will build all 3 distributions (base, sandbox, and uima-as, not uima-cpp). Insure the assemblies are not uploaded to the maven repo's - (they're big, not jars, and should instead be downloaded from our website). After this change, to build distributions, do mvn install, not mvn assembly:assembly, on the distribution POMs. Cripple mvn assembly:assembly so some kind of error message comes out reminding to use mvn install instead. Update website with new instructions on building distributions. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Change to build process for assemblies
For 3 of the 4 released entities (base, uima-as, sandbox, but not CPP), the maven tooling has been changed. To build distributions, first build the underlying parts as before. Then cd to the distr directory and instead of doing mvn assembly:assembly, do mvn install. If you forget, and do mvn assembly:assembly - you'll get a file not found error, but the name of the file will be a message reminding you to use mvn install instead :-) . This change incorporates a common process for building all assemblies, and the running of the RAT tool on them. You can build the assemblies without running the RAT tool by invoking: mvn package instead of mvn install The distribution projects now collect the set of expected exceptions to the RAT tool run, so in the future, running the RAT tool should be much more straight forward. RAT will fail the build with a strange error message ( Too many unapproved licenses: nnn) if it finds a file with missing license headers. The nnn represents the number of problem files that need fixing or excluding. The RAT report lists all these in target/rat.txt of the distr project. -Marshall
[jira] Closed: (UIMA-1613) run Rat consistently for all maven assemblies
[ https://issues.apache.org/jira/browse/UIMA-1613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor closed UIMA-1613. Resolution: Fixed run Rat consistently for all maven assemblies - Key: UIMA-1613 URL: https://issues.apache.org/jira/browse/UIMA-1613 Project: UIMA Issue Type: Improvement Components: Async Scaleout, Build, Packaging and Test, Core Java Framework, Sandbox Reporter: Marshall Schor Assignee: Marshall Schor Priority: Minor Fix For: 2.3S, 2.3, 2.3AS Make all assemblies and RAT testing of those assemblies work the same way (convention over configuration). Have common parent POM concerned with doing assemblies, and have the 3 distribution poms (that build the base, uima-as, and sandbox distributions) use this as a common parent. Builds are done in the package lifecycle. After build is done, in the verify lifecycle (just before install), run the RAT tool. Incorporate into the distribution POMs the set of RAT exclusions. Include a step of unpacking the assemblies (because the RAT tool doesn't work on zips). Running mvn install will now do the assemblies and do the RAT testing. This effectively automates future RAT testing. Running mvn install on the new superPom for distributions will build all 3 distributions (base, sandbox, and uima-as, not uima-cpp). Insure the assemblies are not uploaded to the maven repo's - (they're big, not jars, and should instead be downloaded from our website). After this change, to build distributions, do mvn install, not mvn assembly:assembly, on the distribution POMs. Cripple mvn assembly:assembly so some kind of error message comes out reminding to use mvn install instead. Update website with new instructions on building distributions. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
