Re: UIMA-AS client dependencies
Marshall Schor wrote: 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 Thanks Marshall good job. The ActiveMQ guys say that in a minimal configuration you only need these jars: * activemq-core.jar * commons-logging.jar * geronimo-spec-jms.jar * geronimo-spec-jta.jar * geronimo-spec-j2ee-management.jar Optional the spring.jar is needed for xml based configuration and the persistence jar for persistence. The required jars are combined in an activemq.jar file. Do you think we can just take this activemq.jar file and combine it with the uima jars for a client ? If so we might want to say that in our documentation, because it makes it easier to get started with UIMA-AS. Jörn http://activemq.apache.org/version-5-initial-configuration.html
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
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
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
