[ 
https://issues.apache.org/jira/browse/GEODE-1168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15501768#comment-15501768
 ] 

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: https://issues.apache.org/jira/browse/GEODE-1168
>             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
(v6.3.4#6332)

Reply via email to