headers
Jörn Kottmann | 3 Apr 2012 16:59
Picon

Re: Tycho vs Felix for TextMarker build

+1, I hope it works better than our felix based approach.

Jörn

On 03/30/2012 03:30 PM, Peter Klügl wrote:
>  Hello,
>
> I asked the DLTK developers about best practices for building 
> DLTK-based projects with maven and they (strongly) recommended Tycho 
> (http://www.eclipse.org/tycho/). I think - compared to felix - it's 
> just the other way around where maven uses the dependencies specified 
> in the manifest.
>
> Are there any known reasons against using Tycho?
>
> If not, then I would give it a try because it will probably solve my 
> problems with the (eclipse-based) artifacts.
>
> Peter
>
Permalink | Reply | 1 comment |
headers
Marshall Schor | 4 Apr 2012 01:46

[VOTE] {RESULT} Release uima-build-helper-maven-plugin version 3

The vote passes:

+1:  Marshall Schor,

Jörn Kottmann, Eddie Epstein, Burn Lewis, Tommaso Tiofili

No other votes were received.

Thanks! -Marshall

On 3/29/2012 12:44 PM, Marshall Schor wrote:
> This release incorporates this Jira:
> https://issues.apache.org/jira/browse/UIMA-2369.
>
> The SVN tag is
> https://svn.apache.org/repos/asf/uima/build/tags/uima-build-helper-maven-plugin-3
>
> The artifacts are here:
>
https://repository.apache.org/content/repositories/orgapacheuima-127/org/apache/uima/uima-build-helper-maven-plugin/3/ 
>
>
> Please vote on the release:
>
> [ ] +1 OK to release
> [ ] 0   Don't care
> [ ] -1 Not ok to release, because ...
>
> Thanks. -Marshall
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Adam Lally (Created) (JIRA | 6 Apr 2012 23:56
Picon
Favicon

[jira] [Created] (UIMA-2385) Improve XmiCasDeserializer performance by using low-level CAS APIs to create arrays

Improve XmiCasDeserializer performance by using low-level CAS APIs to create arrays
-----------------------------------------------------------------------------------

                 Key: UIMA-2385
                 URL: https://issues.apache.org/jira/browse/UIMA-2385
             Project: UIMA
          Issue Type: Improvement
          Components: Core Java Framework
    Affects Versions: 2.4.0SDK
            Reporter: Adam Lally

I profiled an expensive CAS deserialization and found that 46% of the time was in CASImpl.ll_getFSForRef
(the method that creates a FeatureStructure Java object for a CAS FS).  All those calls were coming from
deserializing arrays (of which this particular CAS has many).

It is unnecessary to create FeatureStructure Java objects here.  For non-array FSs, XmiCasDeserializer
uses low-level CAS APIs in order to avoid this overhead.  But for arrays, it currently does not use the
low-level APIs.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
Permalink | Reply | 17 comments |
headers
Adam Lally (Work started) (JIRA | 9 Apr 2012 16:51
Picon
Favicon

[jira] [Work started] (UIMA-2385) Improve XmiCasDeserializer performance by using low-level CAS APIs to create arrays


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

Work on UIMA-2385 started by Adam Lally.

> Improve XmiCasDeserializer performance by using low-level CAS APIs to create arrays
> -----------------------------------------------------------------------------------
>
>                 Key: UIMA-2385
>                 URL: https://issues.apache.org/jira/browse/UIMA-2385
>             Project: UIMA
>          Issue Type: Improvement
>          Components: Core Java Framework
>    Affects Versions: 2.4.0SDK
>            Reporter: Adam Lally
>            Assignee: Adam Lally
>
> I profiled an expensive CAS deserialization and found that 46% of the time was in CASImpl.ll_getFSForRef
(the method that creates a FeatureStructure Java object for a CAS FS).  All those calls were coming from
deserializing arrays (of which this particular CAS has many).
> It is unnecessary to create FeatureStructure Java objects here.  For non-array FSs, XmiCasDeserializer
uses low-level CAS APIs in order to avoid this overhead.  But for arrays, it currently does not use the
low-level APIs.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
(Continue reading)

Permalink | Reply | 0 comments |
headers
Adam Lally (Assigned) (JIRA | 9 Apr 2012 16:51
Picon
Favicon

[jira] [Assigned] (UIMA-2385) Improve XmiCasDeserializer performance by using low-level CAS APIs to create arrays


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

Adam Lally reassigned UIMA-2385:
--------------------------------

    Assignee: Adam Lally

> Improve XmiCasDeserializer performance by using low-level CAS APIs to create arrays
> -----------------------------------------------------------------------------------
>
>                 Key: UIMA-2385
>                 URL: https://issues.apache.org/jira/browse/UIMA-2385
>             Project: UIMA
>          Issue Type: Improvement
>          Components: Core Java Framework
>    Affects Versions: 2.4.0SDK
>            Reporter: Adam Lally
>            Assignee: Adam Lally
>
> I profiled an expensive CAS deserialization and found that 46% of the time was in CASImpl.ll_getFSForRef
(the method that creates a FeatureStructure Java object for a CAS FS).  All those calls were coming from
deserializing arrays (of which this particular CAS has many).
> It is unnecessary to create FeatureStructure Java objects here.  For non-array FSs, XmiCasDeserializer
uses low-level CAS APIs in order to avoid this overhead.  But for arrays, it currently does not use the
low-level APIs.

--
This message is automatically generated by JIRA.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Burt Buchman (Created) (JIRA | 9 Apr 2012 17:35
Picon
Favicon

[jira] [Created] (UIMA-2386) Can our own inhouse headings management tool for entity extraction?

Can our own inhouse headings management tool for entity extraction?
-------------------------------------------------------------------

                 Key: UIMA-2386
                 URL: https://issues.apache.org/jira/browse/UIMA-2386
             Project: UIMA
          Issue Type: Question
            Reporter: Burt Buchman

The company I work at is looking at UIMA as a potential environment to use for automated indexing/entity
extraction. We have our own application that does headings management. I see the number of annotators
that UIMA has as well as adding analysis engines. Could we either directly or indirectly use our tool with
UIMA? Our tool would have subject headings to search on the document. Much appreciation for feedback on
this. 
Burt Buchman
Solutions Architect 
Ebsco Publishing
bbuchman@...

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
Permalink | Reply | 0 comments |
headers
Burt Buchman | 9 Apr 2012 17:13
Favicon

UIMA question

We are looking at UIMA for automated indexing and entity extraction. We
have our subject terms in our own tool. Would UIMA be able to either
automatically attach to what would be our annotator to accept our terms
or either a direct connection to it? Would appreciate your feedback.
Thanks!

Burt Buchman

Solution Architect - Editorial

EBSCO Publishing

Phone: 978-356-6500, ext 2346

bbuchman@...
Permalink | Reply | 0 comments |
headers
Adam Lally (Commented) (JIRA | 10 Apr 2012 00:01
Picon
Favicon

[jira] [Commented] (UIMA-2385) Improve XmiCasDeserializer performance by using low-level CAS APIs to create arrays


    [
https://issues.apache.org/jira/browse/UIMA-2385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13250219#comment-13250219
] 

Adam Lally commented on UIMA-2385:
----------------------------------

Well, I may have gotten some bad data from the profiler (yourkit), since deserialization time appears to be
the same after my "fix". :(

> Improve XmiCasDeserializer performance by using low-level CAS APIs to create arrays
> -----------------------------------------------------------------------------------
>
>                 Key: UIMA-2385
>                 URL: https://issues.apache.org/jira/browse/UIMA-2385
>             Project: UIMA
>          Issue Type: Improvement
>          Components: Core Java Framework
>    Affects Versions: 2.4.0SDK
>            Reporter: Adam Lally
>            Assignee: Adam Lally
>
> I profiled an expensive CAS deserialization and found that 46% of the time was in CASImpl.ll_getFSForRef
(the method that creates a FeatureStructure Java object for a CAS FS).  All those calls were coming from
deserializing arrays (of which this particular CAS has many).
> It is unnecessary to create FeatureStructure Java objects here.  For non-array FSs, XmiCasDeserializer
uses low-level CAS APIs in order to avoid this overhead.  But for arrays, it currently does not use the
low-level APIs.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jens Grivolla (Created) (JIRA | 11 Apr 2012 16:35
Picon
Favicon

[jira] [Created] (UIMA-2387) ResultingAnnotationName not optional in ConceptMapper

ResultingAnnotationName not optional in ConceptMapper
-----------------------------------------------------

                 Key: UIMA-2387
                 URL: https://issues.apache.org/jira/browse/UIMA-2387
             Project: UIMA
          Issue Type: Bug
          Components: addons, Sandbox-ConceptMapper
    Affects Versions: 2.3.1Addons
            Reporter: Jens Grivolla
            Priority: Minor

Contrary to the documentation, the ResultingAnnotationName is not optional in the ConceptMapper
descriptor. In our use case we only want to write back information to the original token, without creating
a new annotation. Instead of treating this as a documentation bug it is therefore better to fix the code.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
Permalink | Reply | 1 comment |
headers
Jens Grivolla (Updated) (JIRA | 11 Apr 2012 16:41
Picon
Favicon

[jira] [Updated] (UIMA-2387) ResultingAnnotationName not optional in ConceptMapper


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

Jens Grivolla updated UIMA-2387:
--------------------------------

    Attachment: UIMA-2387.patch

patch file created using git diff

> ResultingAnnotationName not optional in ConceptMapper
> -----------------------------------------------------
>
>                 Key: UIMA-2387
>                 URL: https://issues.apache.org/jira/browse/UIMA-2387
>             Project: UIMA
>          Issue Type: Bug
>          Components: addons, Sandbox-ConceptMapper
>    Affects Versions: 2.3.1Addons
>            Reporter: Jens Grivolla
>            Priority: Minor
>         Attachments: UIMA-2387.patch
>
>
> Contrary to the documentation, the ResultingAnnotationName is not optional in the ConceptMapper
descriptor. In our use case we only want to write back information to the original token, without creating
a new annotation. Instead of treating this as a documentation bug it is therefore better to fix the code.

--
(Continue reading)

Permalink | Reply | 0 comments |

Gmane