[
https://issues.apache.org/jira/browse/GEODE-1168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16699780#comment-16699780
]
ASF subversion and git services commented on GEODE-1168:
--------------------------------------------------------
Commit 2cd3dc8579c98b3d7d812a6e77da599379ccd005 in geode's branch
refs/heads/better-classpath from [~amb]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=2cd3dc8 ]
GEODE-1168 Improves build to automatically add jars to runtime classpath
Flips the generation of the geode-dependencies classpath from an
include list to an exclude list. Every dependent jar that is not
specifically excluded will be added to the classpath automatically.
Eventually we should include lib/* and remove auxillary jars to
alternate locations.
> 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
> Priority: Major
>
> 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
(v7.6.3#76005)
