Details
-
Bug
-
Status: Open
-
Major
-
Resolution: Unresolved
-
None
-
None
Description
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)
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
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.
Attachments
Issue Links
- is related to
-
GEODE-288 Remove deprecated Admin API
-
- Open
-
-
GEODE-1025 Remove compile dependency on spring data gemfire/geode
-
- Closed
-
- links to
