geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Udo Kohlmeyer <>
Subject Re: [DISCUSS] GEODE-7241 - make Jar not War?
Date Wed, 25 Sep 2019 19:20:30 GMT
@Jake, whilst I agree with your statement that there is a preference 
that sers use GFSH to manage their clusters. With that statement are you 
also making a blanket statement we should remove the exposed public 
API's we expose in GEODE to start a Client/Server/Locator?

IF the expected usage of the product is to download it and not use 
dependency management, should we then also remove `geode-core`, 
`geode-wan`, `geode-lucene` artifacts, as all of these would also be 
within the dependencies listed in the geode-dependecies.jar?

It DOES sound counter productive and in essence a little backwards, but 
if our "prescribed" approach to interact/bootstrap/configure/manage 
Geode is to use GFSH, then we should remove all other temptations.


On 9/25/19 12:10 PM, Jacob Barrett wrote:

> -1 for updating previous releases or merging into the current release. I see no overwhelming
need to have these published so that a downstream project can subvert the prescribed why of
starting a server with all its dependencies. A workaround to this issue is to depend on the
full distribution tgz and use gfsh or geode-dependencies.jar to start things up.
> -Jake
>> On Sep 25, 2019, at 11:46 AM, Udo Kohlmeyer <> wrote:
>> So it seems there is consensus around jar vs war. WAR's win by nose. (until we can
find a more creative way to expose said artifacts)
>> That said, do we need to start another thread about fixing 1.8.x or 1.9.x?
>> I'm already considering proposing that GEODE-7241 is included into 1.9.2, as that
patch release is already discussed to backport GEODE-7121.
>> --Udo
>> On 9/25/19 10:53 AM, Anthony Baker wrote:
>>> Thanks for the reminder.  If these files are required to start a geode member,
I agree they should be published artifacts.  Perhaps there’s a better way to pull them in…but
this seems like the best option for now.
>>> Anthony
>>>> On Sep 25, 2019, at 10:22 AM, Udo Kohlmeyer <>
>>>> @Anthony. Ticket was updated.. In a nutshell, to run integration tests, using
the REST endpoints, requires the starting of the server with and embedded web-server.
>>>> As all tests run on dependency management only and don't have access to a
downloaded product, the HTTP endpoints are not part of the dependency. These are added in
by including the WAR files from mavenCentral.
>>>> As @Dan pointed out, GEODE-5660 enabled this behavior.
>>>> I think this approach might actually even help with the testing of the REST
Controller in the Geode codebase itself.
>>>> --Udo

View raw message