[jira] [Updated] (GEODE-1168) geode-dependencies manifest is missing jars that are present in the lib directory

["Swapnil Bawaskar (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/GEODE-1168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

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: 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)