[jira] [Assigned] (GEODE-1168) geode-dependencies manifest is missing jars that are present in the lib directory
[
https://issues.apache.org/jira/browse/GEODE-1168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker reassigned GEODE-1168:
Assignee: (was: Anthony Baker)
> 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
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> 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
(v8.20.10#820010)
[jira] [Assigned] (GEODE-1168) geode-dependencies manifest is missing jars that are present in the lib directory
[
https://issues.apache.org/jira/browse/GEODE-1168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker reassigned GEODE-1168:
Assignee: Anthony Baker
> 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
>Assignee: Anthony Baker
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 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)
