UIMA-AS client dependencies
Hi everyone, I have a small UIMA AS clients which is build with maven, it depends on uimaj-core, uimaj-as-core and uimj-as-activemq. The list of dependencies is very long and I wonder it that is really necessary, since I have to run this little tool on a server the classpath in my start script gets a mile long. Would it be possible to reduce the amount of dependencies ? e.g. uimaj-examples could be a good candidate to remove Jörn
Re: UIMA-AS client dependencies
Jörn Kottmann wrote: Hi everyone, I have a small UIMA AS clients which is build with maven, it depends on uimaj-core, uimaj-as-core and uimj-as-activemq. The list of dependencies is very long and I wonder it that is really necessary, since I have to run this little tool on a server the classpath in my start script gets a mile long. You might be able to use the new bootstrap loader (see the uimaj-bootstrap project) to reduce the class path. Would it be possible to reduce the amount of dependencies ? Probably. We've tried, but have gotten into trouble, for instance, when we launched a uima-as client with only some of the active-mq jars, only to find that under some error conditions (e.g., the broker failing), the behavior became unstable. So it would have to be carefully investigated. e.g. uimaj-examples could be a good candidate to remove I tried removing it (in Eclipse, from the build path) and that seemed to not cause any problems, so it's probably a good candidate to remove. -Marshall Jörn
Re: UIMA-AS client dependencies
Marshall Schor wrote:
Jörn Kottmann wrote:
Hi everyone,
I have a small UIMA AS clients which is build with maven,
it depends on uimaj-core, uimaj-as-core and uimj-as-activemq.
The list of dependencies is very long and I wonder it
that is really necessary, since I have to run
this little tool on a server the classpath
in my start script gets a mile long.
You might be able to use the new bootstrap loader (see the
uimaj-bootstrap project) to reduce the class path.
Would it be possible to reduce the amount
of dependencies ?
Probably. We've tried, but have gotten into trouble, for instance, when
we launched a uima-as client with only some of the active-mq jars, only
to find that under some error conditions (e.g., the broker failing), the
behavior became unstable. So it would have to be carefully investigated.
e.g. uimaj-examples could be a good candidate to remove
I tried removing it (in Eclipse, from the build path) and that seemed to
not cause any problems, so it's probably a good candidate to remove.
There are optional dependencies which are made non-optional
through maven, because they are just normal dependencies.
Here is a list taken from uimaj-as-activemq, maybe we can handle
that a bit different, and I really doubt that we need them all.
dependency
groupIdcommons-beanutils/groupId
artifactIdcommons-beanutils/artifactId
version1.6.1/version
/dependency
dependency
groupIdcommons-collections/groupId
artifactIdcommons-collections/artifactId
version2.1/version
/dependency
dependency
groupIdcommons-dbcp/groupId
artifactIdcommons-dbcp/artifactId
version1.2/version
/dependency
dependency
groupIdcommons-pool/groupId
artifactIdcommons-pool/artifactId
version1.2/version
/dependency
dependency
groupIdorg.apache.geronimo.specs/groupId
artifactIdgeronimo-j2ee-connector_1.5_spec/artifactId
version1.0/version
/dependency
dependency
groupIdorg.apache.geronimo.specs/groupId
artifactIdgeronimo-j2ee-jacc_1.0_spec/artifactId
version1.0/version
/dependency
dependency
groupIdactivemq/groupId
artifactIdjmdns/artifactId
version1.0-RC2/version
/dependency
dependency
groupIdlog4j/groupId
artifactIdlog4j/artifactId
version1.2.12/version
/dependency
dependency
groupIdmx4j/groupId
artifactIdmx4j-remote/artifactId
version2.1.1/version
/dependency
dependency
groupIdmx4j/groupId
artifactIdmx4j-tools/artifactId
version2.1.1/version
/dependency
dependency
groupIdorg.apache.uima/groupId
artifactIduimaj-as-core/artifactId
version${uimaj-as-release-version}/version
scopecompile/scope
/dependency
dependency
groupIdorg.apache.uima/groupId
artifactIduimaj-as-jms/artifactId
version${uimaj-as-release-version}/version
scopecompile/scope
/dependency
dependency
groupIdcommons-httpclient/groupId
artifactIdcommons-httpclient/artifactId
version2.0.1/version
/dependency
dependency
groupIdorg.mortbay.jetty/groupId
artifactIdjetty/artifactId
version6.0.1/version
/dependency
dependency
groupIdorg.mortbay.jetty/groupId
artifactIdjetty-util/artifactId
version6.0.1/version
/dependency
dependency
groupIdorg.mortbay.jetty/groupId
artifactIdservlet-api-2.5/artifactId
version6.0.1/version
/dependency
dependency
groupIdxmlpull/groupId
artifactIdxmlpull/artifactId
version1.1.3.4d_b4_min/version
/dependency
dependency
groupIdcom.thoughtworks.xstream/groupId
artifactIdxstream/artifactId
version1.2.2/version
/dependency
dependency
groupIdorg.apache.derby/groupId
artifactIdderby/artifactId
version10.1.1.0/version
/dependency
dependency
groupIdorg.apache.xbean/groupId
artifactIdxbean-spring/artifactId
version2.8/version
/dependency
Jörn
[jira] Created: (UIMA-1620) Add options to enable testing of annotator in a multithreaded setup.
Add options to enable testing of annotator in a multithreaded setup. - Key: UIMA-1620 URL: https://issues.apache.org/jira/browse/UIMA-1620 Project: UIMA Issue Type: Improvement Reporter: Bhavani Iyer Add options to: 1) instantiate multiple instances of the analysis engine and run these concurrently on different threads. 2) option to do multiple runs of the same inputs. 3) randomize the next input to process 4) random delays between calls to process -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: UIMA-AS client dependencies
Jörn Kottmann wrote:
Marshall Schor wrote:
Jörn Kottmann wrote:
Hi everyone,
I have a small UIMA AS clients which is build with maven,
it depends on uimaj-core, uimaj-as-core and uimj-as-activemq.
The list of dependencies is very long and I wonder it
that is really necessary, since I have to run
this little tool on a server the classpath
in my start script gets a mile long.
You might be able to use the new bootstrap loader (see the
uimaj-bootstrap project) to reduce the class path.
Would it be possible to reduce the amount
of dependencies ?
Probably. We've tried, but have gotten into trouble, for instance, when
we launched a uima-as client with only some of the active-mq jars, only
to find that under some error conditions (e.g., the broker failing), the
behavior became unstable. So it would have to be carefully
investigated.
e.g. uimaj-examples could be a good candidate to remove
I tried removing it (in Eclipse, from the build path) and that seemed to
not cause any problems, so it's probably a good candidate to remove.
There are optional dependencies which are made non-optional
through maven, because they are just normal dependencies.
Here is a list taken from uimaj-as-activemq, maybe we can handle
that a bit different, and I really doubt that we need them all.
OK. I'll take a close look...
-Marshall
dependency
groupIdcommons-beanutils/groupId
artifactIdcommons-beanutils/artifactId
version1.6.1/version
/dependency
dependency
groupIdcommons-collections/groupId
artifactIdcommons-collections/artifactId
version2.1/version
/dependency
dependency
groupIdcommons-dbcp/groupId
artifactIdcommons-dbcp/artifactId
version1.2/version
/dependency
dependency
groupIdcommons-pool/groupId
artifactIdcommons-pool/artifactId
version1.2/version
/dependency
dependency
groupIdorg.apache.geronimo.specs/groupId
artifactIdgeronimo-j2ee-connector_1.5_spec/artifactId
version1.0/version
/dependency
dependency
groupIdorg.apache.geronimo.specs/groupId
artifactIdgeronimo-j2ee-jacc_1.0_spec/artifactId
version1.0/version
/dependency
dependency
groupIdactivemq/groupId
artifactIdjmdns/artifactId
version1.0-RC2/version
/dependency
dependency
groupIdlog4j/groupId
artifactIdlog4j/artifactId
version1.2.12/version
/dependency
dependency
groupIdmx4j/groupId
artifactIdmx4j-remote/artifactId
version2.1.1/version
/dependency
dependency
groupIdmx4j/groupId
artifactIdmx4j-tools/artifactId
version2.1.1/version
/dependency
dependency
groupIdorg.apache.uima/groupId
artifactIduimaj-as-core/artifactId
version${uimaj-as-release-version}/version
scopecompile/scope
/dependency
dependency
groupIdorg.apache.uima/groupId
artifactIduimaj-as-jms/artifactId
version${uimaj-as-release-version}/version
scopecompile/scope
/dependency
dependency
groupIdcommons-httpclient/groupId
artifactIdcommons-httpclient/artifactId
version2.0.1/version
/dependency
dependency
groupIdorg.mortbay.jetty/groupId
artifactIdjetty/artifactId
version6.0.1/version
/dependency
dependency
groupIdorg.mortbay.jetty/groupId
artifactIdjetty-util/artifactId
version6.0.1/version
/dependency
dependency
groupIdorg.mortbay.jetty/groupId
artifactIdservlet-api-2.5/artifactId
version6.0.1/version
/dependency
dependency
groupIdxmlpull/groupId
artifactIdxmlpull/artifactId
version1.1.3.4d_b4_min/version
/dependency
dependency
groupIdcom.thoughtworks.xstream/groupId
artifactIdxstream/artifactId
version1.2.2/version
/dependency
dependency
groupIdorg.apache.derby/groupId
artifactIdderby/artifactId
version10.1.1.0/version
/dependency
dependency
groupIdorg.apache.xbean/groupId
artifactIdxbean-spring/artifactId
version2.8/version
/dependency
Jörn
[jira] Created: (UIMA-1621) CVD should work when classes loaded dynamically
CVD should work when classes loaded dynamically --- Key: UIMA-1621 URL: https://issues.apache.org/jira/browse/UIMA-1621 Project: UIMA Issue Type: Bug Components: Tools Affects Versions: 2.3 Reporter: Burn Lewis Priority: Minor If CVD is loaded via the bootstrap loader it gets a NPE when configuring the logger. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (UIMA-1621) CVD should work when classes loaded dynamically
[ https://issues.apache.org/jira/browse/UIMA-1621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Burn Lewis resolved UIMA-1621. -- Resolution: Fixed Assignee: Burn Lewis Fixed - tested on Windows only. CVD should work when classes loaded dynamically --- Key: UIMA-1621 URL: https://issues.apache.org/jira/browse/UIMA-1621 Project: UIMA Issue Type: Bug Components: Tools Affects Versions: 2.3 Reporter: Burn Lewis Assignee: Burn Lewis Priority: Minor If CVD is loaded via the bootstrap loader it gets a NPE when configuring the logger. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: UIMA-AS client dependencies
I took a look at the dependencies for the uimaj-as-activemq project, using the tools: mvn dependency:analyze and mvn dependency:tree and here's what I found. 1) uimaj-examples is a testing dependency - I'll change the scope. 2) There are some dependencies coded in what appears to be a strange way. Here's an example: dependency groupIdorg.apache.activemq/groupId artifactIdactivemq-optional/artifactId version4.1.1/version exclusions exclusion groupIdorg.apache.activemq/groupId artifactIdactivemq-optional/artifactId /exclusion /exclusions /dependency This says include org.apache.activemq:activemq-optional:jar:4.1.1:compile, but exclude org.apache.activemq:activemq-optional I think what this was attempting to do was to exclude activemq-optional, which was being brought in as a transitive dependency. This doesn't work, as evidenced by using mvn dependency:tree, so I'm removing it. The xstream dependency turns out to be just a testcase dependency, so I'm changing that scope to test. I ran mvn dependency:tree -Dverbose and got a complete listing of the dependencies, and after review the only one I think I can safely exclude is the activemq-web-demo. I'll make a jira for this. -Marshall Jörn Kottmann wrote: Hi everyone, I have a small UIMA AS clients which is build with maven, it depends on uimaj-core, uimaj-as-core and uimj-as-activemq. The list of dependencies is very long and I wonder it that is really necessary, since I have to run this little tool on a server the classpath in my start script gets a mile long. Would it be possible to reduce the amount of dependencies ? e.g. uimaj-examples could be a good candidate to remove Jörn
[jira] Created: (UIMA-1622) Make uima-as dependencies more precise
Make uima-as dependencies more precise -- Key: UIMA-1622 URL: https://issues.apache.org/jira/browse/UIMA-1622 Project: UIMA Issue Type: Improvement Components: Async Scaleout, Build, Packaging and Test Reporter: Marshall Schor Assignee: Marshall Schor Priority: Minor Fix For: 2.3AS see http://markmail.org/thread/ktujtkwoqpihnqu4 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (UIMA-1531) Need a script to launch a UIMA-AS service via RunWithJarPath
[ https://issues.apache.org/jira/browse/UIMA-1531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jerry Cwiklik updated UIMA-1531: Component/s: Core Java Framework Affects Version/s: 2.3 Fix for this effects both, the core and uima as Need a script to launch a UIMA-AS service via RunWithJarPath Key: UIMA-1531 URL: https://issues.apache.org/jira/browse/UIMA-1531 Project: UIMA Issue Type: New Feature Components: Async Scaleout, Core Java Framework Affects Versions: 2.3, 2.3AS Reporter: Jerry Cwiklik Assignee: Jerry Cwiklik Fix For: 2.3AS Use existing RunWithJarPath.class from the core to enable loading jars dynamically when launching UIMA AS service. Currently setUimaClasspath is called to setup static classpath before deployment of UIMA_Service. For more flexibility it would be better to load all jar files from specified locations instead of depending on them to be statically defined in setUimaClasspath. One of the reasons for supporting dynamically loaded jars is the naming scheme used by ActiveMQ. Each version comes with a differently named jars like for example apache-activemq-4.1.1.jar, activemq-all-5.2.0.jar, etc. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-1622) Make uima-as dependencies more precise
[ https://issues.apache.org/jira/browse/UIMA-1622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor closed UIMA-1622. Resolution: Fixed Make uima-as dependencies more precise -- Key: UIMA-1622 URL: https://issues.apache.org/jira/browse/UIMA-1622 Project: UIMA Issue Type: Improvement Components: Async Scaleout, Build, Packaging and Test Reporter: Marshall Schor Assignee: Marshall Schor Priority: Minor Fix For: 2.3AS see http://markmail.org/thread/ktujtkwoqpihnqu4 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (UIMA-1620) Add options runAECpp to enable testing of annotator in a multithreaded setup.
[ https://issues.apache.org/jira/browse/UIMA-1620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bhavani Iyer updated UIMA-1620: --- Component/s: C++ Framework Description: Add options to runAECpp: 1) instantiate multiple instances of the analysis engine and run these concurrently on different threads. 2) option to do multiple runs of the same inputs. 3) randomize the next input to process 4) random delays between calls to process was: Add options to: 1) instantiate multiple instances of the analysis engine and run these concurrently on different threads. 2) option to do multiple runs of the same inputs. 3) randomize the next input to process 4) random delays between calls to process Assignee: Bhavani Iyer Summary: Add options runAECpp to enable testing of annotator in a multithreaded setup. (was: Add options to enable testing of annotator in a multithreaded setup.) Add options runAECpp to enable testing of annotator in a multithreaded setup. -- Key: UIMA-1620 URL: https://issues.apache.org/jira/browse/UIMA-1620 Project: UIMA Issue Type: Improvement Components: C++ Framework Reporter: Bhavani Iyer Assignee: Bhavani Iyer Add options to runAECpp: 1) instantiate multiple instances of the analysis engine and run these concurrently on different threads. 2) option to do multiple runs of the same inputs. 3) randomize the next input to process 4) random delays between calls to process -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (UIMA-1620) Add options runAECpp to enable testing of annotator in a multithreaded setup.
[ https://issues.apache.org/jira/browse/UIMA-1620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bhavani Iyer updated UIMA-1620: --- Attachment: UIMACPP-1620.patch The following optional command line arguments enable these functions: -n numInstances number of annotator instances each running in a separate thread -r numRuns number of iterations over the same input. -rand randomize the selection on next input to process. -rdelay max random delay in millis between 0 and this max between calls to process. Add options runAECpp to enable testing of annotator in a multithreaded setup. -- Key: UIMA-1620 URL: https://issues.apache.org/jira/browse/UIMA-1620 Project: UIMA Issue Type: Improvement Components: C++ Framework Reporter: Bhavani Iyer Assignee: Bhavani Iyer Attachments: UIMACPP-1620.patch Add options to runAECpp: 1) instantiate multiple instances of the analysis engine and run these concurrently on different threads. 2) option to do multiple runs of the same inputs. 3) randomize the next input to process 4) random delays between calls to process -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
