@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.
--Udo
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 <ukohlme...@pivotal.io> 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 <ukohlme...@pivotal.io> wrote:
@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
