[jira] Reopened: (UIMA-1840) Result Specification behavior incorrect for aggregates
[ https://issues.apache.org/jira/browse/UIMA-1840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor reopened UIMA-1840: -- The result spec intersection code is broken for the case where one spec has xxxtype:yyyfeature and the other has xxxtype with the "allFeatures" flag set. > Result Specification behavior incorrect for aggregates > -- > > Key: UIMA-1840 > URL: https://issues.apache.org/jira/browse/UIMA-1840 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Reporter: Eddie Epstein >Assignee: Marshall Schor > Fix For: 2.3.1 > > > For a scenario using default result specifications, if an annotator with > language "x-unspecified" is included in an aggregate with a different > language, say "en", any containsType method calls from the annotator will > return false. > This behavior is incorrect given that the annotator has declared that it will > work with any language. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (UIMA-1857) reduce the complexity of the one-time-setup
reduce the complexity of the one-time-setup --- Key: UIMA-1857 URL: https://issues.apache.org/jira/browse/UIMA-1857 Project: UIMA Issue Type: Improvement Components: Build, Packaging and Test Reporter: Marshall Schor Assignee: Marshall Schor There are 2 complexities: # The patching of docbkx plugin to get it to work with 3.0 maven # The install of special versions of the m2eclipse plugin Find ways to simplify or eliminate these. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Feedback requested on build approach and tooling
I just went through the process of setting up uima build env on my new Lenovo W500. It was not as straight forward process as I would have liked but most problems were in the one time setup and related to documentation (and the fact I was initially using Helios). Luckily, Marshall was able to help with all that and made changes to the docs so that for others the setup may be less painful. Since I've got things working I dont see any problems. Actually I like the fact that I can now build projects from eclipse directly instead of going to a cmd line and running mvn to build and install. That's the biggest benefit for me. On Tue, Aug 10, 2010 at 12:00 PM, Marshall Schor wrote: > Re: lowering the barriers - one-time-setups issues... > > Based on Adams and Thilo's responses, I have pushed a bit to get the > m2eclipse / > xmlbeans stuff improved. > > To my surprise, someone posted this morning to the Jira > https://issues.sonatype.org/browse/MNGECLIPSE-1694 indicating that the bug > might > be fixed in the latest m2eclipse (not yet released). I tried that > "bleeding-edge" release in a fresh Eclipse 3.6 (Helios) and it did indeed > fix > that issue - right clicking the projects that use xmlbeans and selecting > Maven > -> update configuration updated the build paths correctly, so they all > built in > Eclipse. > > I've asked to see if there's a "guesstimate" of when this might be > released... > > --- > > Also, I found a likely alternative work-around. This is to regress the > version > used for the xmlbeans-maven-plugin from 2.3.3 to 2.2.0. This appears to > work > with 0.10.2 as well as 0.11. > > I think it doesn't affect our builds, so I plan to backlevel this plugin, > until > after m2eclipse 0.11 is released. > > --- > > I asked on the docbkx mailing list about getting a release out - and they > say > they may try to do one in a week or 2... > > If both of these get fixed, then the one-time setups become much more > "conventional". > > -Marshall > > On 8/9/2010 11:31 PM, Adam Lally wrote: > > On Mon, Aug 9, 2010 at 11:24 PM, Marshall Schor wrote: > > > >> On 8/9/2010 5:22 PM, Adam Lally wrote: > >>> On Mon, Aug 9, 2010 at 12:03 PM, Marshall Schor wrote: > >>> > Please post feedback on this build process - is this a good direction, > >> and > whether or not you are able to do builds! > > > >>> I like some things about Maven, but the experience of using it has > >>> definitely been frustrating. Any time you try to do something out of > the > >>> ordinary, it is a real struggle. I remember experiencing that > >> frustration > >>> when we first migrated out build to Maven, and now I've been seeing > >> Marshall > >>> go through it again. > >>> > >>> However, our previous build process wasn't so great either. Our ant > >> scripts > >>> had grown organically until they were a mess that wasn't maintainable. > >> And > >>> without maven to automatically download dependencies like Eclipse jars, > >> in > >>> order to build UIMA you had to manually obtain Eclipse (and a > particular > >>> version of it, too) and a couple of other dependencies, which was a > pain. > >>> > >>> I think that I can work with what we have now, even if it's not ideal. > I > >>> was able to do a build following the instructions, but it's very > >> cumbersome > >>> and I worry that it will discourage people from becoming involved in > the > >>> project. > >> Was the cumbersome part doing the one-time-setups, or was it something > >> afterwards, in doing the builds themselves? > >> > > Just the one-time setups. I know it is only "one time", so it's not too > bad > > for a committer to have to do, but for someone who just wants to casually > > poke around the UIMA code and maybe try to patch a small issue, it may > turn > > them off. > > > > -Adam > > >
Re: Feedback requested on build approach and tooling
Re: lowering the barriers - one-time-setups issues... Based on Adams and Thilo's responses, I have pushed a bit to get the m2eclipse / xmlbeans stuff improved. To my surprise, someone posted this morning to the Jira https://issues.sonatype.org/browse/MNGECLIPSE-1694 indicating that the bug might be fixed in the latest m2eclipse (not yet released). I tried that "bleeding-edge" release in a fresh Eclipse 3.6 (Helios) and it did indeed fix that issue - right clicking the projects that use xmlbeans and selecting Maven -> update configuration updated the build paths correctly, so they all built in Eclipse. I've asked to see if there's a "guesstimate" of when this might be released... --- Also, I found a likely alternative work-around. This is to regress the version used for the xmlbeans-maven-plugin from 2.3.3 to 2.2.0. This appears to work with 0.10.2 as well as 0.11. I think it doesn't affect our builds, so I plan to backlevel this plugin, until after m2eclipse 0.11 is released. --- I asked on the docbkx mailing list about getting a release out - and they say they may try to do one in a week or 2... If both of these get fixed, then the one-time setups become much more "conventional". -Marshall On 8/9/2010 11:31 PM, Adam Lally wrote: > On Mon, Aug 9, 2010 at 11:24 PM, Marshall Schor wrote: > >> On 8/9/2010 5:22 PM, Adam Lally wrote: >>> On Mon, Aug 9, 2010 at 12:03 PM, Marshall Schor wrote: >>> Please post feedback on this build process - is this a good direction, >> and whether or not you are able to do builds! >>> I like some things about Maven, but the experience of using it has >>> definitely been frustrating. Any time you try to do something out of the >>> ordinary, it is a real struggle. I remember experiencing that >> frustration >>> when we first migrated out build to Maven, and now I've been seeing >> Marshall >>> go through it again. >>> >>> However, our previous build process wasn't so great either. Our ant >> scripts >>> had grown organically until they were a mess that wasn't maintainable. >> And >>> without maven to automatically download dependencies like Eclipse jars, >> in >>> order to build UIMA you had to manually obtain Eclipse (and a particular >>> version of it, too) and a couple of other dependencies, which was a pain. >>> >>> I think that I can work with what we have now, even if it's not ideal. I >>> was able to do a build following the instructions, but it's very >> cumbersome >>> and I worry that it will discourage people from becoming involved in the >>> project. >> Was the cumbersome part doing the one-time-setups, or was it something >> afterwards, in doing the builds themselves? >> > Just the one-time setups. I know it is only "one time", so it's not too bad > for a committer to have to do, but for someone who just wants to casually > poke around the UIMA code and maybe try to patch a small issue, it may turn > them off. > > -Adam >
Re: [UIMA C++ Framework] making examples
Hi David, The LD_LIBRARY_PATH should only include directories, not specific files. Try removing DeSR.so from the path. Eddie On Tue, Aug 10, 2010 at 5:37 AM, David García wrote: > Hi, > > testing the C++ UIMA annotator I implemented in a UIMA pipeline with other > Java UIMA components, I got following error, caused by a > ResourceInitializationException: > > > Caused by: org.apache.uima.uimacpp.UimacppException: null; > org.apache.uima.uimacpp.InternalTafException: > Error number : 2001 > Recoverable : No > Error : Error loading annotator 'DeSR'. > '/usr/local/share/uima/pipelines/DeSR/installed_pears/DeSR/DeSR.so: > undefined symbol: _ZTVN4Tanl14MorphExtractorE' > While : Error loading annotator '???'. '???' > (2001) > at > org.apache.uima.uimacpp.UimacppEngine.throwJTafException(UimacppEngine.java:499) > at > org.apache.uima.uimacpp.UimacppEngine.initialize(UimacppEngine.java:262) > at > org.apache.uima.uimacpp.UimacppEngine.createJTafTAE(UimacppEngine.java:226) > at > org.apache.uima.uimacpp.UimacppAnalysisComponent.initialize(UimacppAnalysisComponent.java:152) > > > I have setted all the environment variables required by UIMA SDK: > > export UIMACPP_HOME=/home/d/uimacpp/uimacpp > export PATH=$PATH:$UIMACPP_HOME/bin > export LD_LIBRARY_PATH=$UIMACPP_HOME/lib > export > LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/share/uima/pipelines/DeSR/installed_pears/DeSR/DeSR.so > > > It seems the UIMA pipeline can't load the C++ component. Am I doing anything > wrong? > > > Regards, > David > > El 06/08/2010 13:24, Eddie Epstein escribió: >> >> Hi David, >> >> A C++ annotator is intended to be fully interoperable with those >> written in Java. That is, it can access feature structures found in >> the CAS and create new FS in the CAS. The type system of the CAS is >> the superset of types defined by all annotators, including any C++ >> components. >> >> So yes, you can use eclipse and integrate both java and c++ components. >> >> Regards, >> Eddie >> >> On Fri, Aug 6, 2010 at 3:35 AM, David García >> wrote: >>> >>> Hi Eddie, >>> >>> this C++ UIMA annotator needs previous Java UIMA annotators annotations, >>> as >>> this C++ UIMA annotator needs them to work with. >>> But this types are implemented by means of Java classes, as these >>> previous >>> UIMA annotators are implemented in Java. >>> So my question is whether once I have developed this C++ UIMA annotator, >>> generated the dynamic library, and composed the pipeline will work. >>> >>> Moreover, this C++ UIMA annotator has its own type, which should be >>> implemented, and I neither know if this implementation could be done in >>> Java >>> or should be in C++. >>> >>> My idea is to develop the annotator in C++, and afterwards, generate its >>> own >>> type automatically from its descriptor in an Eclipse UIMA Java project. >>> Is >>> this correct? >>> >>> >>> David >>> >>> El 05/08/2010 14:40, Eddie Epstein escribió: Hi David, Capabilities for any annotator should only declare the input types needed by that annotator and the output types generated by that annotator. Why would you need types from other annotators? Eddie On Thu, Aug 5, 2010 at 6:48 AM, David García wrote: > > Hi, > > I have a doubt regarding UIMA C++ annotator. > I'm developing a C++ annotator to be combined within a UIMA pipeline > with > other Java annotators. The point is this C++ annotator requires, as > input > capabilities, another Java annotator annotations. > My question is whether it is necessary to translate to C++ the input > capability types defined in Java by the ohter Java annotators, as well > as > the C++ annotator types. > > My idea is to develop the C++ annotator, generating the dynamic > library, > and > afterwards, create an Eclipse UIMA project by using the proper > descriptor > for the C++ UIMA annotator. Then, in this UIMA project, include the > Java > types required for the C++ UIMA annotator as well as its own types. > > Am I wrong, or would it be correct? > > > David > > El 22/07/2010 10:02, David García escribió: >> >> It was version problem. Now it works. >> >> Thank you Eddie. >> >> >> David >> >> El 21/07/2010 20:34, Eddie Epstein escribió: >>> >>> Probably a mismatch between 32 and 64-bit versions. >>> >>> To confirm, use the "file" command on DaveDetector.o and on >>> uimacpp/lib/libuima.so >>> >>> UIMACPP binary packages come in both flavors for Linux, so if this is >>> the problem, get the other one. >>> >>> One other solution if your OS is 64-bit and the uimacpp package is >>> 32-bit: modify uimacpp/lib/base.mak to force all compiles to be >>> 32-bit. >>> >>> Regards, >>> Eddie >>> >>> On Wed, Jul 21, 2010 at 4:00 AM, Davi
Re: [UIMA C++ Framework] making examples
Hi, testing the C++ UIMA annotator I implemented in a UIMA pipeline with other Java UIMA components, I got following error, caused by a ResourceInitializationException: Caused by: org.apache.uima.uimacpp.UimacppException: null; org.apache.uima.uimacpp.InternalTafException: Error number : 2001 Recoverable : No Error : Error loading annotator 'DeSR'. '/usr/local/share/uima/pipelines/DeSR/installed_pears/DeSR/DeSR.so: undefined symbol: _ZTVN4Tanl14MorphExtractorE' While : Error loading annotator '???'. '???' (2001) at org.apache.uima.uimacpp.UimacppEngine.throwJTafException(UimacppEngine.java:499) at org.apache.uima.uimacpp.UimacppEngine.initialize(UimacppEngine.java:262) at org.apache.uima.uimacpp.UimacppEngine.createJTafTAE(UimacppEngine.java:226) at org.apache.uima.uimacpp.UimacppAnalysisComponent.initialize(UimacppAnalysisComponent.java:152) I have setted all the environment variables required by UIMA SDK: export UIMACPP_HOME=/home/d/uimacpp/uimacpp export PATH=$PATH:$UIMACPP_HOME/bin export LD_LIBRARY_PATH=$UIMACPP_HOME/lib export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/share/uima/pipelines/DeSR/installed_pears/DeSR/DeSR.so It seems the UIMA pipeline can't load the C++ component. Am I doing anything wrong? Regards, David El 06/08/2010 13:24, Eddie Epstein escribió: Hi David, A C++ annotator is intended to be fully interoperable with those written in Java. That is, it can access feature structures found in the CAS and create new FS in the CAS. The type system of the CAS is the superset of types defined by all annotators, including any C++ components. So yes, you can use eclipse and integrate both java and c++ components. Regards, Eddie On Fri, Aug 6, 2010 at 3:35 AM, David García wrote: Hi Eddie, this C++ UIMA annotator needs previous Java UIMA annotators annotations, as this C++ UIMA annotator needs them to work with. But this types are implemented by means of Java classes, as these previous UIMA annotators are implemented in Java. So my question is whether once I have developed this C++ UIMA annotator, generated the dynamic library, and composed the pipeline will work. Moreover, this C++ UIMA annotator has its own type, which should be implemented, and I neither know if this implementation could be done in Java or should be in C++. My idea is to develop the annotator in C++, and afterwards, generate its own type automatically from its descriptor in an Eclipse UIMA Java project. Is this correct? David El 05/08/2010 14:40, Eddie Epstein escribió: Hi David, Capabilities for any annotator should only declare the input types needed by that annotator and the output types generated by that annotator. Why would you need types from other annotators? Eddie On Thu, Aug 5, 2010 at 6:48 AM, David García wrote: Hi, I have a doubt regarding UIMA C++ annotator. I'm developing a C++ annotator to be combined within a UIMA pipeline with other Java annotators. The point is this C++ annotator requires, as input capabilities, another Java annotator annotations. My question is whether it is necessary to translate to C++ the input capability types defined in Java by the ohter Java annotators, as well as the C++ annotator types. My idea is to develop the C++ annotator, generating the dynamic library, and afterwards, create an Eclipse UIMA project by using the proper descriptor for the C++ UIMA annotator. Then, in this UIMA project, include the Java types required for the C++ UIMA annotator as well as its own types. Am I wrong, or would it be correct? David El 22/07/2010 10:02, David García escribió: It was version problem. Now it works. Thank you Eddie. David El 21/07/2010 20:34, Eddie Epstein escribió: Probably a mismatch between 32 and 64-bit versions. To confirm, use the "file" command on DaveDetector.o and on uimacpp/lib/libuima.so UIMACPP binary packages come in both flavors for Linux, so if this is the problem, get the other one. One other solution if your OS is 64-bit and the uimacpp package is 32-bit: modify uimacpp/lib/base.mak to force all compiles to be 32-bit. Regards, Eddie On Wed, Jul 21, 2010 at 4:00 AM, David García wrote: Thanks for your answer Eddie. You are right, the include of must be setted before "uima/api.hpp" include. Now when I make the DaveDetector example ( make -f DaveDetector.mak ) I get following error message: /usr/bin/ld: skipping incompatible /home/david.garcian/uimacpp/uimacpp/lib/libuima.so when searching for -luima /usr/bin/ld: cannot find -luima collect2: ld returned 1 exit status make: *** [DaveDetector.so] Error 1 It says libuima.so is icompatible. Does it have anything to do with the version of Linux or gcc? David El 19/07/2010 15:13, Eddie Epstein escribió: If you add the include to DaveDetector.cpp, it must be before the include of uima/api.hpp. A better way to go would be to put the include of into lowlevel_internal_inde
