Reading over the docs for gfsh - I don't support removing any functionality
from a top level command perspective.It should be noted that I didn't
go deeper then the top level commands, there might be some sub option on
some command that could be dropped or tweaked.
Charlie
On Mon, Dec 9, 201
> I imagine once the Management v2 API's are GA (and feature complete), I
don't see a reason why /gfsh/ should not be a stand alone module. It
would definitely have to be updated to use the new v2 API's, which
should not have any direct dependency on geode-core any more.
There also is a big questi
Any standalone management API or client thereof would not be able to start
locator or start server. For that gfsh still needs a large chunk of Geode.
> On Dec 6, 2019, at 12:25 PM, Udo Kohlmeyer wrote:
>
> I imagine once the Management v2 API's are GA (and feature complete), I don't
> see
I imagine once the Management v2 API's are GA (and feature complete), I
don't see a reason why /gfsh/ should not be a stand alone module. It
would definitely have to be updated to use the new v2 API's, which
should not have any direct dependency on geode-core any more.
On 12/6/19 10:01 AM, Jac
Our goal wasn’t to make gfsh standalone, but a couple people have asked about
it already. It’s not currently planned as far as I know, though maybe it will
be in the future.
> On Dec 6, 2019, at 10:00 AM, Jacob Barrett wrote:
>
>
>
>> On Dec 6, 2019, at 9:43 AM, Jens Deppe wrote:
>>
>> Th
> On Dec 6, 2019, at 9:44 AM, Jens Deppe wrote:
>
> Just to be clear, this effort does *not* result in a standalone gfsh
> executable/jar.
Is this a future plan?
> On Dec 6, 2019, at 9:43 AM, Jens Deppe wrote:
>
> The geode-dependencies.jar now includes the *geode-gfsh.jar* (as well as
> Spring still).
Should it??
Just to be clear, this effort does *not* result in a standalone gfsh
executable/jar.
Sorry.
--Jens
On Fri, Dec 6, 2019 at 6:27 AM Jens Deppe wrote:
> We have completed the work to move the gfsh code into a separate gradle
> submodule. This work has the following implications and effects:
>
>
The geode-dependencies.jar now includes the *geode-gfsh.jar* (as well as
Spring still).
--Jens
On Fri, Dec 6, 2019 at 8:49 AM Anthony Baker wrote:
> Did the class path in geode-dependencies.jar change? If so, that might
> also affect applications that relied on the those (spring) jars being
>
Did the class path in geode-dependencies.jar change? If so, that might also
affect applications that relied on the those (spring) jars being available on
the class path. Of course, they can fix that by explicitly injecting the
applications dependencies into the class path as needed.
Anthony
👏 This 👏 is 👏 amazing 👏
> On Dec 6, 2019, at 6:27 AM, Jens Deppe wrote:
>
> We have completed the work to move the gfsh code into a separate gradle
> submodule. This work has the following implications and effects:
>
> - geode-core does not have any direct dependencies on Spring libraries
>
Apologies to anyone who has any gfsh related PRs in flight as it will
require rebasing onto develop.
--Jens
On Fri, Dec 6, 2019 at 6:27 AM Jens Deppe wrote:
> We have completed the work to move the gfsh code into a separate gradle
> submodule. This work has the following implications and effect
12 matches
Mail list logo
