Dan Smith created GEODE-1168:
--------------------------------
Summary: geode-dependencies manifest is missing jars that are
present in the lib directory
Key: GEODE-1168
URL: https://issues.apache.org/jira/browse/GEODE-1168
Project: Geode
Issue Type: Bug
Components: build
Reporter: Dan Smith
While looking into GEODE-1025, I discovered that we have a number of jars in
the geode-assembly/build/install/apache-geode/lib directory that do not appear
in geode-dependencies.jar or gfsh-dependencies.jar.
I believe that means that these are not actually on the classpath for any geode
process, which means they either shouldn't be shipped with geode at all, or
they are supposed to be on the classpath but I getting skipped for some reason.
These are the jars present in the lib directory, but not on the classpath,
excluding the spring jars (I'm cleaning those up as part of GEODE-1025)
{noformat}
activation-1.1.jar
commons-modeler-2.0.jar
findbugs-annotations-1.3.9-1.jar
geode-jca-1.0.0-incubating.M2-SNAPSHOT.rar
geode-web-1.0.0-incubating.M2-SNAPSHOT.jar
geode-web-api-1.0.0-incubating.M2-SNAPSHOT.jar
guava-15.0.jar
javax.mail-api-1.4.5.jar
mx4j-3.0.1.jar
mx4j-remote-3.0.1.jar
mx4j-tools-3.0.1.jar
ra.jar
{noformat}
Most of these jars appear to be coming from compile dependencies of geode-core.
The jars in the lib directory are controlled by the distributions section of
geode-assembly/build.gradle. The jars in the geode-dependencies.jar manifest
are coming from the cp() method in geode-assembly/build.gradle.
It seems like these two lists ought to be unified - we should only ship jars
that appear in one of the two manifests, and what goes into the manifest should
probably be controlled by the configurations of the other projects - In other
words, if it's part of the runtime configuration of geode-core it should be
part of the geode-dependencies.jar; it shouldn't be filtered by this cp()
method.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
