geode-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Swapnil Bawaskar (JIRA)" <>
Subject [jira] [Updated] (GEODE-1168) geode-dependencies manifest is missing jars that are present in the lib directory
Date Tue, 04 Oct 2016 19:08:20 GMT


Swapnil Bawaskar updated GEODE-1168:
    Fix Version/s:     (was: 1.0.0-incubating)

> geode-dependencies manifest is missing jars that are present in the lib directory
> ---------------------------------------------------------------------------------
>                 Key: GEODE-1168
>                 URL:
>             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

View raw message