Thanks for the positive feedback. This proposal is accepted and development
will proceed.
--Jens
On Mon, Nov 25, 2019 at 9:27 AM Dale Emery wrote:
> +ힹ
> —
> Dale Emery
> dem...@pivotal.io
>
>
>
> > On Nov 22, 2019, at 8:39 AM, Jens Deppe wrote:
> >
> > Hello All,
> >
> > We'd like to propose
+ힹ
—
Dale Emery
dem...@pivotal.io
> On Nov 22, 2019, at 8:39 AM, Jens Deppe wrote:
>
> Hello All,
>
> We'd like to propose moving gfsh and all associated commands into its own
> gradle submodule (implicitly thus also producing a separate maven
> artifact). The underlying intent is to
Most. Popular. Proposal. EVER!
On Fri, Nov 22, 2019 at 3:13 PM Charlie Black wrote:
> Just to see if the refactor happens by itself...
>
> +200
>
>
> On Fri, Nov 22, 2019 at 3:10 PM Alexander Murmann
> wrote:
>
> > +1
> >
> > If we get to 200, the refactor implements itself, right?
> >
> > On
Just to see if the refactor happens by itself...
+200
On Fri, Nov 22, 2019 at 3:10 PM Alexander Murmann
wrote:
> +1
>
> If we get to 200, the refactor implements itself, right?
>
> On Fri, Nov 22, 2019 at 1:57 PM Jason Huynh wrote:
>
> > +1
> > I think we are now at +114 thanks to jinmei's
+1
If we get to 200, the refactor implements itself, right?
On Fri, Nov 22, 2019 at 1:57 PM Jason Huynh wrote:
> +1
> I think we are now at +114 thanks to jinmei's 100 ;-)
>
>
> On Fri, Nov 22, 2019 at 1:50 PM Mark Bretl wrote:
>
> > +1
> >
> > On Fri, Nov 22, 2019 at 12:55 PM Nabarun Nag
+1
I think we are now at +114 thanks to jinmei's 100 ;-)
On Fri, Nov 22, 2019 at 1:50 PM Mark Bretl wrote:
> +1
>
> On Fri, Nov 22, 2019 at 12:55 PM Nabarun Nag wrote:
>
> > +1
> >
> > On Fri, Nov 22, 2019 at 12:51 PM Charlie Black
> wrote:
> >
> > > this proposal == awesome sauce
> > >
> >
+1
On Fri, Nov 22, 2019 at 12:55 PM Nabarun Nag wrote:
> +1
>
> On Fri, Nov 22, 2019 at 12:51 PM Charlie Black wrote:
>
> > this proposal == awesome sauce
> >
> > +1
> >
> > On Fri, Nov 22, 2019 at 11:24 AM Robert Houghton
> > wrote:
> >
> > > +1
> > >
> > > Do we want to restart from my lazy
+1
On Fri, Nov 22, 2019 at 12:51 PM Charlie Black wrote:
> this proposal == awesome sauce
>
> +1
>
> On Fri, Nov 22, 2019 at 11:24 AM Robert Houghton
> wrote:
>
> > +1
> >
> > Do we want to restart from my lazy POC from a few months ago?
> >
> > On Fri, Nov 22, 2019, 08:40 Jens Deppe wrote:
>
this proposal == awesome sauce
+1
On Fri, Nov 22, 2019 at 11:24 AM Robert Houghton
wrote:
> +1
>
> Do we want to restart from my lazy POC from a few months ago?
>
> On Fri, Nov 22, 2019, 08:40 Jens Deppe wrote:
>
> > Hello All,
> >
> > We'd like to propose moving gfsh and all associated
+1
Do we want to restart from my lazy POC from a few months ago?
On Fri, Nov 22, 2019, 08:40 Jens Deppe wrote:
> Hello All,
>
> We'd like to propose moving gfsh and all associated commands into its own
> gradle submodule (implicitly thus also producing a separate maven
> artifact). The
+1
On Fri, Nov 22, 2019 at 8:41 AM Jens Deppe wrote:
> Hello All,
>
> We'd like to propose moving gfsh and all associated commands into its own
> gradle submodule (implicitly thus also producing a separate maven
> artifact). The underlying intent is to decouple geode core from any Spring
>
+1 !!
On Fri, Nov 22, 2019 at 9:42 AM Dan Smith wrote:
> +1
>
> Awesome!!!
>
> -Dan
>
> On Fri, Nov 22, 2019 at 9:33 AM Owen Nichols wrote:
>
> > +1
> >
> > It makes total sense that gfsh should depend on core, and core should be
> > completely unaware of it. The dependency untangling that
+1 great idea!
On 11/22/19 8:39 AM, Jens Deppe wrote:
Hello All,
We'd like to propose moving gfsh and all associated commands into its own
gradle submodule (implicitly thus also producing a separate maven
artifact). The underlying intent is to decouple geode core from any Spring
dependencies.
+1
Awesome!!!
-Dan
On Fri, Nov 22, 2019 at 9:33 AM Owen Nichols wrote:
> +1
>
> It makes total sense that gfsh should depend on core, and core should be
> completely unaware of it. The dependency untangling that results will also
> help pave the way for other interfaces, such as a gfsh-free
+1
It makes total sense that gfsh should depend on core, and core should be
completely unaware of it. The dependency untangling that results will also
help pave the way for other interfaces, such as a gfsh-free management REST
interface.
> On Nov 22, 2019, at 8:45 AM, Jinmei Liao wrote:
>
+1
On Fri, Nov 22, 2019 at 9:17 AM Kirk Lund wrote:
> +1 yes!
>
> On Fri, Nov 22, 2019 at 9:15 AM Donal Evans wrote:
>
> > +1
> >
> > Especially with the new management functionality on the way, this seems
> > like a good idea.
> >
> > On Fri, Nov 22, 2019 at 8:45 AM Jinmei Liao wrote:
> >
>
+1 yes!
On Fri, Nov 22, 2019 at 9:15 AM Donal Evans wrote:
> +1
>
> Especially with the new management functionality on the way, this seems
> like a good idea.
>
> On Fri, Nov 22, 2019 at 8:45 AM Jinmei Liao wrote:
>
> > +100. Would be a great move.
> >
> > On Fri, Nov 22, 2019 at 8:40 AM Jens
+1
Especially with the new management functionality on the way, this seems
like a good idea.
On Fri, Nov 22, 2019 at 8:45 AM Jinmei Liao wrote:
> +100. Would be a great move.
>
> On Fri, Nov 22, 2019 at 8:40 AM Jens Deppe wrote:
>
> > Hello All,
> >
> > We'd like to propose moving gfsh and
+100. Would be a great move.
On Fri, Nov 22, 2019 at 8:40 AM Jens Deppe wrote:
> Hello All,
>
> We'd like to propose moving gfsh and all associated commands into its own
> gradle submodule (implicitly thus also producing a separate maven
> artifact). The underlying intent is to decouple geode
Hello All,
We'd like to propose moving gfsh and all associated commands into its own
gradle submodule (implicitly thus also producing a separate maven
artifact). The underlying intent is to decouple geode core from any Spring
dependencies.
The proposal is outlined here:
20 matches
Mail list logo
