geode-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anthony Baker (JIRA)" <>
Subject [jira] [Commented] (GEODE-1168) geode-dependencies manifest is missing jars that are present in the lib directory
Date Sun, 18 Sep 2016 22:42:20 GMT


Anthony Baker commented on GEODE-1168:

`findbugs-annotations-1.3.9-1.jar` is needed at compile time but not at runtime.

> 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
>             Fix For: 1.0.0-incubating
> 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