Re: New geode-gfsh module
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, 2019 at 8:32 AM Alexander Murmann wrote: > > 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 question here of how much of the current GFSH > functionality needs to be there to fully replace the current GFSH. Looking > at the functionality available right now, it seems like we have a very long > way ahead of us. > > On Fri, Dec 6, 2019 at 12:32 PM Owen Nichols wrote: > > > 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 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, Jacob Barrett wrote: > > >> > > >>> 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? > > >> > > >> > > > > > -- Charlie Black | cbl...@pivotal.io
Re: New geode-gfsh module
> 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 question here of how much of the current GFSH functionality needs to be there to fully replace the current GFSH. Looking at the functionality available right now, it seems like we have a very long way ahead of us. On Fri, Dec 6, 2019 at 12:32 PM Owen Nichols wrote: > 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 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, Jacob Barrett wrote: > >> > >>> 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? > >> > >> > >
Re: New geode-gfsh module
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 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, Jacob Barrett wrote: >> >>> 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? >> >>
Re: New geode-gfsh module
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, Jacob Barrett wrote: 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?
Re: New geode-gfsh module
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: >> >> The geode-dependencies.jar now includes the *geode-gfsh.jar* (as well as >> Spring still). > > Should it??
Re: New geode-gfsh module
> 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?
Re: New geode-gfsh module
> 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??
Re: New geode-gfsh module
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: > >- geode-core does not have any direct dependencies on Spring libraries >anymore >- Anyone building with Geode will need to include the '*geode-gfsh'* >dependency in order to use gfsh commands. This is relevant to anyone using >Spring Boot (or Spring Data Geode) to launch locators or servers. >- The Geode distribution (*.zip/.tgz) still includes all necessary >libs required to use gfsh (i.e. Spring libraries) >- There is no change for users using the 'gfsh' utility directly to >launch locators and servers since the *gfsh-dependencies.jar* still >contains all necessary references to Spring, etc. > > Please let us know if you discover any issues related to this work. > > Thanks > -- Jens & Patrick >
Re: New geode-gfsh module
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 > available on the class path. Of course, they can fix that by explicitly > injecting the applications dependencies into the class path as needed. > > Anthony > > > > 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 > > anymore > > - Anyone building with Geode will need to include the '*geode-gfsh'* > > dependency in order to use gfsh commands. This is relevant to anyone > using > > Spring Boot (or Spring Data Geode) to launch locators or servers. > > - The Geode distribution (*.zip/.tgz) still includes all necessary libs > > required to use gfsh (i.e. Spring libraries) > > - There is no change for users using the 'gfsh' utility directly to > > launch locators and servers since the *gfsh-dependencies.jar* still > > contains all necessary references to Spring, etc. > > > > Please let us know if you discover any issues related to this work. > > > > Thanks > > -- Jens & Patrick > >
Re: New geode-gfsh module
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 > 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 > anymore > - Anyone building with Geode will need to include the '*geode-gfsh'* > dependency in order to use gfsh commands. This is relevant to anyone using > Spring Boot (or Spring Data Geode) to launch locators or servers. > - The Geode distribution (*.zip/.tgz) still includes all necessary libs > required to use gfsh (i.e. Spring libraries) > - There is no change for users using the 'gfsh' utility directly to > launch locators and servers since the *gfsh-dependencies.jar* still > contains all necessary references to Spring, etc. > > Please let us know if you discover any issues related to this work. > > Thanks > -- Jens & Patrick
Re: New geode-gfsh module
👏 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 > anymore > - Anyone building with Geode will need to include the '*geode-gfsh'* > dependency in order to use gfsh commands. This is relevant to anyone using > Spring Boot (or Spring Data Geode) to launch locators or servers. > - The Geode distribution (*.zip/.tgz) still includes all necessary libs > required to use gfsh (i.e. Spring libraries) > - There is no change for users using the 'gfsh' utility directly to > launch locators and servers since the *gfsh-dependencies.jar* still > contains all necessary references to Spring, etc. > > Please let us know if you discover any issues related to this work. > > Thanks > -- Jens & Patrick
Re: New geode-gfsh module
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 effects: > >- geode-core does not have any direct dependencies on Spring libraries >anymore >- Anyone building with Geode will need to include the '*geode-gfsh'* >dependency in order to use gfsh commands. This is relevant to anyone using >Spring Boot (or Spring Data Geode) to launch locators or servers. >- The Geode distribution (*.zip/.tgz) still includes all necessary >libs required to use gfsh (i.e. Spring libraries) >- There is no change for users using the 'gfsh' utility directly to >launch locators and servers since the *gfsh-dependencies.jar* still >contains all necessary references to Spring, etc. > > Please let us know if you discover any issues related to this work. > > Thanks > -- Jens & Patrick >
New geode-gfsh module
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 anymore - Anyone building with Geode will need to include the '*geode-gfsh'* dependency in order to use gfsh commands. This is relevant to anyone using Spring Boot (or Spring Data Geode) to launch locators or servers. - The Geode distribution (*.zip/.tgz) still includes all necessary libs required to use gfsh (i.e. Spring libraries) - There is no change for users using the 'gfsh' utility directly to launch locators and servers since the *gfsh-dependencies.jar* still contains all necessary references to Spring, etc. Please let us know if you discover any issues related to this work. Thanks -- Jens & Patrick
