You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Gal Palmery <Ga...@amdocs.com> on 2016/11/06 09:42:58 UTC
classpath in geode release
Hi,
I noticed that there are 2 jackson-annotations jars, and 2 slf4j-api jars with different versions in the classpath (in the MANIFESTs of geode-dependencies.jar and in gfsh-dependencies.jar).
What is the reason for that? Is this a bug?
Thanks,
Gal
This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement,
you may review at http://www.amdocs.com/email_disclaimer.asp
RE: classpath in geode release
Posted by Gal Palmery <Ga...@amdocs.com>.
Gr8, now all is clear :)
Thanks!
Gal
-----Original Message-----
From: Anthony Baker [mailto:abaker@pivotal.io]
Sent: Tuesday, November 08, 2016 16:17
To: dev@geode.incubator.apache.org
Subject: Re: classpath in geode release
> On Nov 8, 2016, at 1:09 AM, Gal Palmery <Ga...@amdocs.com> wrote:
>
> Actually I do see them in the lib dir, after running the build, inside the zip in the distributions:
>
> geode-assembly\build\distributions\apache-geode-1.0.0-incubating.zip\a
> pache-geode-1.0.0-incubating\lib also, when comparing to the Gemfire
> distribution (that we use in our product in released versions) - the gfsh_dependencies.jar is present in the lib dir as well.
You’re correct. What I meant was that the extra jars referenced in the manifest classpath (jackson-annotations-2.8.2.jar for example) are not present in the lib/ directory and thus won’t be present on the classpath in practice.
> If we start gemfire/geode from gfsh, are these jars used for creating the gemfire/geode runtime classpath?
Yes
Anthony
This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement,
you may review at http://www.amdocs.com/email_disclaimer.asp
Re: classpath in geode release
Posted by Anthony Baker <ab...@pivotal.io>.
> On Nov 8, 2016, at 1:09 AM, Gal Palmery <Ga...@amdocs.com> wrote:
>
> Actually I do see them in the lib dir, after running the build, inside the zip in the distributions:
> geode-assembly\build\distributions\apache-geode-1.0.0-incubating.zip\apache-geode-1.0.0-incubating\lib
> also, when comparing to the Gemfire distribution (that we use in our product in released versions) - the gfsh_dependencies.jar is present in the lib dir as well.
You’re correct. What I meant was that the extra jars referenced in the manifest classpath (jackson-annotations-2.8.2.jar for example) are not present in the lib/ directory and thus won’t be present on the classpath in practice.
> If we start gemfire/geode from gfsh, are these jars used for creating the gemfire/geode runtime classpath?
Yes
Anthony
RE: classpath in geode release
Posted by Gal Palmery <Ga...@amdocs.com>.
Actually I do see them in the lib dir, after running the build, inside the zip in the distributions:
geode-assembly\build\distributions\apache-geode-1.0.0-incubating.zip\apache-geode-1.0.0-incubating\lib
also, when comparing to the Gemfire distribution (that we use in our product in released versions) - the gfsh_dependencies.jar is present in the lib dir as well.
If we start gemfire/geode from gfsh, are these jars used for creating the gemfire/geode runtime classpath?
Gal
-----Original Message-----
From: Anthony Baker [mailto:abaker@pivotal.io]
Sent: Monday, November 07, 2016 18:40
To: dev@geode.incubator.apache.org
Subject: Re: classpath in geode release
> On Nov 7, 2016, at 1:11 AM, Gal Palmery <Ga...@amdocs.com> wrote:
>
> Thanks Anthony.
> So, if I were to manually remove them from the manifest, do you expect any issues at runtime?
>
Since those jars are not present in the lib/ dir, the MANFEST classpath entry should be harmless either way.
> Also, you mentioned that these are only used when using cmd line. How is the runtime classpath built when not using cmd ?
>
The dependency jars are only used when launching the server. Applications using the gemfire java client can use maven / gradle dependencies to pull in the correct jars.
> Thanks,
> Gal
>
>
> -----Original Message-----
> From: Anthony Baker [mailto:abaker@pivotal.io]
> Sent: Monday, November 07, 2016 01:20
> To: geode
> Subject: Re: classpath in geode release
>
>
>> On Nov 6, 2016, at 7:47 AM, Gal Palmery <Ga...@amdocs.com> wrote:
>>
>> Clarification -
>> This is in the geode-dependencies.jar and gfsh-dependencies.jar that were created by the local build that I run on my PC.
>> I downloaded the 1.0.0-incubating release and built it using the following command:
>>> gradlew clean build installDist -Dskip.tests=true
>>
>
> Yep, this looks like a bug, though probably harmless. The geode-core dependencies pull in v2.8.0 transitively:
>
> +--- com.fasterxml.jackson.core:jackson-databind:2.8.2
> | +--- com.fasterxml.jackson.core:jackson-annotations:2.8.0
> | \--- com.fasterxml.jackson.core:jackson-core:2.8.2
>
> while the geode-pulse and geode-web-api modules pull in v2.8.2 with an explicit dependency. These should be filtered when we build the classpath. See GEODE-2078.
>
>> where can I find these jars (geode-dependencies.jar and gfsh-dependencies.jar) that are created each nightly build?
>> I tried in the maven central repository, but they are not there.
>
> There jars aren’t published to maven as they are manifest-only jars meant for cmd line usage. The build artifacts can be found in jenkins (see https://builds.apache.org/job/Geode-nightly) but those should only be used for development purposes and are not official releases.
>
>>
>> Thanks,
>> Gal
>>
>>
>> -----Original Message-----
>> From: Gal Palmery
>> Sent: Sunday, November 06, 2016 11:43
>> To: dev@geode.incubator.apache.org
>> Subject: classpath in geode release
>>
>> Hi,
>>
>> I noticed that there are 2 jackson-annotations jars, and 2 slf4j-api jars with different versions in the classpath (in the MANIFESTs of geode-dependencies.jar and in gfsh-dependencies.jar).
>> What is the reason for that? Is this a bug?
>>
>> Thanks,
>> Gal
>>
>> This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at http://www.amdocs.com/email_disclaimer.asp
>
Re: classpath in geode release
Posted by Anthony Baker <ab...@pivotal.io>.
> On Nov 7, 2016, at 1:11 AM, Gal Palmery <Ga...@amdocs.com> wrote:
>
> Thanks Anthony.
> So, if I were to manually remove them from the manifest, do you expect any issues at runtime?
>
Since those jars are not present in the lib/ dir, the MANFEST classpath entry should be harmless either way.
> Also, you mentioned that these are only used when using cmd line. How is the runtime classpath built when not using cmd ?
>
The dependency jars are only used when launching the server. Applications using the gemfire java client can use maven / gradle dependencies to pull in the correct jars.
> Thanks,
> Gal
>
>
> -----Original Message-----
> From: Anthony Baker [mailto:abaker@pivotal.io]
> Sent: Monday, November 07, 2016 01:20
> To: geode
> Subject: Re: classpath in geode release
>
>
>> On Nov 6, 2016, at 7:47 AM, Gal Palmery <Ga...@amdocs.com> wrote:
>>
>> Clarification -
>> This is in the geode-dependencies.jar and gfsh-dependencies.jar that were created by the local build that I run on my PC.
>> I downloaded the 1.0.0-incubating release and built it using the following command:
>>> gradlew clean build installDist -Dskip.tests=true
>>
>
> Yep, this looks like a bug, though probably harmless. The geode-core dependencies pull in v2.8.0 transitively:
>
> +--- com.fasterxml.jackson.core:jackson-databind:2.8.2
> | +--- com.fasterxml.jackson.core:jackson-annotations:2.8.0
> | \--- com.fasterxml.jackson.core:jackson-core:2.8.2
>
> while the geode-pulse and geode-web-api modules pull in v2.8.2 with an explicit dependency. These should be filtered when we build the classpath. See GEODE-2078.
>
>> where can I find these jars (geode-dependencies.jar and gfsh-dependencies.jar) that are created each nightly build?
>> I tried in the maven central repository, but they are not there.
>
> There jars aren’t published to maven as they are manifest-only jars meant for cmd line usage. The build artifacts can be found in jenkins (see https://builds.apache.org/job/Geode-nightly) but those should only be used for development purposes and are not official releases.
>
>>
>> Thanks,
>> Gal
>>
>>
>> -----Original Message-----
>> From: Gal Palmery
>> Sent: Sunday, November 06, 2016 11:43
>> To: dev@geode.incubator.apache.org
>> Subject: classpath in geode release
>>
>> Hi,
>>
>> I noticed that there are 2 jackson-annotations jars, and 2 slf4j-api jars with different versions in the classpath (in the MANIFESTs of geode-dependencies.jar and in gfsh-dependencies.jar).
>> What is the reason for that? Is this a bug?
>>
>> Thanks,
>> Gal
>>
>> This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at http://www.amdocs.com/email_disclaimer.asp
>
RE: classpath in geode release
Posted by Gal Palmery <Ga...@amdocs.com>.
Thanks Anthony.
So, if I were to manually remove them from the manifest, do you expect any issues at runtime?
Also, you mentioned that these are only used when using cmd line. How is the runtime classpath built when not using cmd ?
Thanks,
Gal
-----Original Message-----
From: Anthony Baker [mailto:abaker@pivotal.io]
Sent: Monday, November 07, 2016 01:20
To: geode
Subject: Re: classpath in geode release
> On Nov 6, 2016, at 7:47 AM, Gal Palmery <Ga...@amdocs.com> wrote:
>
> Clarification -
> This is in the geode-dependencies.jar and gfsh-dependencies.jar that were created by the local build that I run on my PC.
> I downloaded the 1.0.0-incubating release and built it using the following command:
>> gradlew clean build installDist -Dskip.tests=true
>
Yep, this looks like a bug, though probably harmless. The geode-core dependencies pull in v2.8.0 transitively:
+--- com.fasterxml.jackson.core:jackson-databind:2.8.2
| +--- com.fasterxml.jackson.core:jackson-annotations:2.8.0
| \--- com.fasterxml.jackson.core:jackson-core:2.8.2
while the geode-pulse and geode-web-api modules pull in v2.8.2 with an explicit dependency. These should be filtered when we build the classpath. See GEODE-2078.
> where can I find these jars (geode-dependencies.jar and gfsh-dependencies.jar) that are created each nightly build?
> I tried in the maven central repository, but they are not there.
There jars aren’t published to maven as they are manifest-only jars meant for cmd line usage. The build artifacts can be found in jenkins (see https://builds.apache.org/job/Geode-nightly) but those should only be used for development purposes and are not official releases.
>
> Thanks,
> Gal
>
>
> -----Original Message-----
> From: Gal Palmery
> Sent: Sunday, November 06, 2016 11:43
> To: dev@geode.incubator.apache.org
> Subject: classpath in geode release
>
> Hi,
>
> I noticed that there are 2 jackson-annotations jars, and 2 slf4j-api jars with different versions in the classpath (in the MANIFESTs of geode-dependencies.jar and in gfsh-dependencies.jar).
> What is the reason for that? Is this a bug?
>
> Thanks,
> Gal
>
> This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at http://www.amdocs.com/email_disclaimer.asp
RE: classpath in geode release
Posted by Dor Ben Dov <do...@amdocs.com>.
Good catch Gal.
Regards,
Dor
-----Original Message-----
From: Anthony Baker [mailto:abaker@pivotal.io]
Sent: יום ב 07 נובמבר 2016 01:20
To: geode <de...@geode.incubator.apache.org>
Subject: Re: classpath in geode release
> On Nov 6, 2016, at 7:47 AM, Gal Palmery <Ga...@amdocs.com> wrote:
>
> Clarification -
> This is in the geode-dependencies.jar and gfsh-dependencies.jar that were created by the local build that I run on my PC.
> I downloaded the 1.0.0-incubating release and built it using the following command:
>> gradlew clean build installDist -Dskip.tests=true
>
Yep, this looks like a bug, though probably harmless. The geode-core dependencies pull in v2.8.0 transitively:
+--- com.fasterxml.jackson.core:jackson-databind:2.8.2
| +--- com.fasterxml.jackson.core:jackson-annotations:2.8.0
| \--- com.fasterxml.jackson.core:jackson-core:2.8.2
while the geode-pulse and geode-web-api modules pull in v2.8.2 with an explicit dependency. These should be filtered when we build the classpath. See GEODE-2078.
> where can I find these jars (geode-dependencies.jar and gfsh-dependencies.jar) that are created each nightly build?
> I tried in the maven central repository, but they are not there.
There jars aren’t published to maven as they are manifest-only jars meant for cmd line usage. The build artifacts can be found in jenkins (see https://builds.apache.org/job/Geode-nightly) but those should only be used for development purposes and are not official releases.
>
> Thanks,
> Gal
>
>
> -----Original Message-----
> From: Gal Palmery
> Sent: Sunday, November 06, 2016 11:43
> To: dev@geode.incubator.apache.org
> Subject: classpath in geode release
>
> Hi,
>
> I noticed that there are 2 jackson-annotations jars, and 2 slf4j-api jars with different versions in the classpath (in the MANIFESTs of geode-dependencies.jar and in gfsh-dependencies.jar).
> What is the reason for that? Is this a bug?
>
> Thanks,
> Gal
>
> This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at http://www.amdocs.com/email_disclaimer.asp
Re: classpath in geode release
Posted by Anthony Baker <ab...@pivotal.io>.
> On Nov 6, 2016, at 7:47 AM, Gal Palmery <Ga...@amdocs.com> wrote:
>
> Clarification -
> This is in the geode-dependencies.jar and gfsh-dependencies.jar that were created by the local build that I run on my PC.
> I downloaded the 1.0.0-incubating release and built it using the following command:
>> gradlew clean build installDist -Dskip.tests=true
>
Yep, this looks like a bug, though probably harmless. The geode-core dependencies pull in v2.8.0 transitively:
+--- com.fasterxml.jackson.core:jackson-databind:2.8.2
| +--- com.fasterxml.jackson.core:jackson-annotations:2.8.0
| \--- com.fasterxml.jackson.core:jackson-core:2.8.2
while the geode-pulse and geode-web-api modules pull in v2.8.2 with an explicit dependency. These should be filtered when we build the classpath. See GEODE-2078.
> where can I find these jars (geode-dependencies.jar and gfsh-dependencies.jar) that are created each nightly build?
> I tried in the maven central repository, but they are not there.
There jars aren’t published to maven as they are manifest-only jars meant for cmd line usage. The build artifacts can be found in jenkins (see https://builds.apache.org/job/Geode-nightly) but those should only be used for development purposes and are not official releases.
>
> Thanks,
> Gal
>
>
> -----Original Message-----
> From: Gal Palmery
> Sent: Sunday, November 06, 2016 11:43
> To: dev@geode.incubator.apache.org
> Subject: classpath in geode release
>
> Hi,
>
> I noticed that there are 2 jackson-annotations jars, and 2 slf4j-api jars with different versions in the classpath (in the MANIFESTs of geode-dependencies.jar and in gfsh-dependencies.jar).
> What is the reason for that? Is this a bug?
>
> Thanks,
> Gal
>
> This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at http://www.amdocs.com/email_disclaimer.asp
RE: classpath in geode release
Posted by Gal Palmery <Ga...@amdocs.com>.
Clarification -
This is in the geode-dependencies.jar and gfsh-dependencies.jar that were created by the local build that I run on my PC.
I downloaded the 1.0.0-incubating release and built it using the following command:
> gradlew clean build installDist -Dskip.tests=true
where can I find these jars (geode-dependencies.jar and gfsh-dependencies.jar) that are created each nightly build?
I tried in the maven central repository, but they are not there.
Thanks,
Gal
-----Original Message-----
From: Gal Palmery
Sent: Sunday, November 06, 2016 11:43
To: dev@geode.incubator.apache.org
Subject: classpath in geode release
Hi,
I noticed that there are 2 jackson-annotations jars, and 2 slf4j-api jars with different versions in the classpath (in the MANIFESTs of geode-dependencies.jar and in gfsh-dependencies.jar).
What is the reason for that? Is this a bug?
Thanks,
Gal
This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at http://www.amdocs.com/email_disclaimer.asp