You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Fred Melo <fm...@pivotal.io> on 2016/03/14 23:11:58 UTC
Packaging and dependencies
Folks,
Data Microservices use cases are getting more and more popular and
libraries like SpringBoot + Geode can be a pretty powerful combo.
However, there are serious challenges on how we package and distribute
Geode through its maven
repository (org.apache.geode:gemfire-core:1.0.0-incubating-SNAPSHOT) today,
all within a single uber jar and over 100Mb in size:
1) It forces a simple microservice app running in small containers to
include that giant dependency, even if only looking for only the client
module for example.
It seems very odd in my point of view to pack the entire product binaries
and add a 100Mb jar only for accessing Geode as a *client app*, making that
app nearly impossible to run from lightweight container-deployable
microservices perspective.
2) The single jar embeds a lot of other cross-project dependencies that
might not be desirable (for example: Jetty). We all know Java classpath
management can be very challenging, and including unnecessary libraries
when we only want to use a tiny part of that system is definitely an
anti-pattern. Usage just as a client or a minimum subset of functionality
forces the classpath to have libraries we absolutely don't want.
A good example of the above is trying to build a SpringBoot app as a Geode
*client*. SpringBoot dependencies will conflict with logging frameworks,
Jetty and other jars embedded into Geode and make it nearly impossible to
build a SpringBoot microservice powered by Geode.
A simple docker container image would also be on the hundreds of megabytes,
which seems extremely high for cloud platform deployment.
IMO if we want to increase the project adoption we need to break the Geode
build ASAP in *at least* Geode-server and Geode-client asap. We should
also consider better on how to package other project dependencies like
log4j/sf4j.
Further divisions into modules like Geode-WAN would also be important.
thoughts?
Fred
--
Fred Melo
fmelo@pivotal.io
+1-650-3021360
Re: Packaging and dependencies
Posted by Fred Melo <fm...@pivotal.io>.
Manuel, thanks for weighting in.
Okay, this definitely needs to make its way into our roadmap to be
prioritized soon.
any other thoughts?
On Mon, Mar 14, 2016 at 3:51 PM Anilkumar Gingade <ag...@pivotal.io>
wrote:
> Hi Fred,
>
> You are right, with micro-services and mobile applications getting
> prominent there is a need to separate our client code...This had came up
> multiple times in our product road-map (previously)...but never got
> prioritized as no customer pushed for this...
>
> -Anil.
>
>
>
> On Mon, Mar 14, 2016 at 3:11 PM, Fred Melo <fm...@pivotal.io> wrote:
>
> > Folks,
> >
> > Data Microservices use cases are getting more and more popular and
> > libraries like SpringBoot + Geode can be a pretty powerful combo.
> >
> > However, there are serious challenges on how we package and
> distribute
> > Geode through its maven
> > repository (org.apache.geode:gemfire-core:1.0.0-incubating-SNAPSHOT)
> today,
> > all within a single uber jar and over 100Mb in size:
> >
> > 1) It forces a simple microservice app running in small containers to
> > include that giant dependency, even if only looking for only the client
> > module for example.
> > It seems very odd in my point of view to pack the entire product binaries
> > and add a 100Mb jar only for accessing Geode as a *client app*, making
> that
> > app nearly impossible to run from lightweight container-deployable
> > microservices perspective.
> >
> > 2) The single jar embeds a lot of other cross-project dependencies
> that
> > might not be desirable (for example: Jetty). We all know Java classpath
> > management can be very challenging, and including unnecessary libraries
> > when we only want to use a tiny part of that system is definitely an
> > anti-pattern. Usage just as a client or a minimum subset of functionality
> > forces the classpath to have libraries we absolutely don't want.
> >
> >
> > A good example of the above is trying to build a SpringBoot app as a
> Geode
> > *client*. SpringBoot dependencies will conflict with logging frameworks,
> > Jetty and other jars embedded into Geode and make it nearly impossible to
> > build a SpringBoot microservice powered by Geode.
> >
> > A simple docker container image would also be on the hundreds of
> megabytes,
> > which seems extremely high for cloud platform deployment.
> >
> > IMO if we want to increase the project adoption we need to break the
> Geode
> > build ASAP in *at least* Geode-server and Geode-client asap. We should
> > also consider better on how to package other project dependencies like
> > log4j/sf4j.
> > Further divisions into modules like Geode-WAN would also be important.
> >
> > thoughts?
> >
> > Fred
> >
> >
> >
> > --
> > Fred Melo
> > fmelo@pivotal.io
> > +1-650-3021360
> >
>
--
Fred Melo
fmelo@pivotal.io
+1-650-3021360
Re: Packaging and dependencies
Posted by William Markito <wm...@pivotal.io>.
+1
Funny enough I remember creating a story about that in an older tracker talking about the same issues and leveraging the concept we had at that time for gfxd.
The problem Fred describes about deploying big jars we have experienced through docker and lattice (microcf) and can be seen in other use cases as well.
My simple groovy script + springboot + geode example generates a jar of 190mb which is really fat for a client but maybe good enough for a server. Definitely huge for mobile/IoT.
Sent from my iPhone
> On Mar 14, 2016, at 4:28 PM, Fred Melo <fm...@pivotal.io> wrote:
>
> Exactly. Thanks everyone for chiming in.
>
>
>> On Mon, Mar 14, 2016 at 4:12 PM Udo Kohlmeyer <uk...@pivotal.io> wrote:
>>
>> +1
>>
>> This should also simplify the client and server code base...
>>
>> The step after that should be different libraries for different
>> functionality in the product. If you need WAN, then you add WAN lib and
>> if you need CQ's you can add that lib. We then end up with very modular
>> application and only load what is required.
>>
>> --Udo
>>
>>> On 15/03/2016 10:03 am, Dan Smith wrote:
>>> +1 to splitting things up with a view making a smaller client and core
>> jar.
>>>
>>> BTW, I'm currently working on GEODE-27. One of the things I'm doing is
>>> marking a bunch of the dependencies such as jetty as optional in our pom.
>>> But that's not the real fix. The fix is to move the code that depends on
>>> those libraries out of geode-core. There are some subtasks under
>> GEODE-818
>>> describing some of the work that needs to happen there.
>>>
>>> -Dan
>>>
>>> On Mon, Mar 14, 2016 at 3:54 PM, Anilkumar Gingade <ag...@pivotal.io>
>>> wrote:
>>>
>>>> Adding to that, for mobile apps our recommendation was to use REST APIs.
>>>>
>>>> -Anil.
>>>>
>>>>
>>>> On Mon, Mar 14, 2016 at 3:51 PM, Anilkumar Gingade <agingade@pivotal.io
>>>
>>>> wrote:
>>>>
>>>>> Hi Fred,
>>>>>
>>>>> You are right, with micro-services and mobile applications getting
>>>>> prominent there is a need to separate our client code...This had came
>> up
>>>>> multiple times in our product road-map (previously)...but never got
>>>>> prioritized as no customer pushed for this...
>>>>>
>>>>> -Anil.
>>>>>
>>>>>
>>>>>
>>>>>> On Mon, Mar 14, 2016 at 3:11 PM, Fred Melo <fm...@pivotal.io> wrote:
>>>>>>
>>>>>> Folks,
>>>>>>
>>>>>> Data Microservices use cases are getting more and more popular
>> and
>>>>>> libraries like SpringBoot + Geode can be a pretty powerful combo.
>>>>>>
>>>>>> However, there are serious challenges on how we package and
>>>> distribute
>>>>>> Geode through its maven
>>>>>> repository (org.apache.geode:gemfire-core:1.0.0-incubating-SNAPSHOT)
>>>>>> today,
>>>>>> all within a single uber jar and over 100Mb in size:
>>>>>>
>>>>>> 1) It forces a simple microservice app running in small
>> containers
>>>> to
>>>>>> include that giant dependency, even if only looking for only the
>> client
>>>>>> module for example.
>>>>>> It seems very odd in my point of view to pack the entire product
>>>> binaries
>>>>>> and add a 100Mb jar only for accessing Geode as a *client app*, making
>>>>>> that
>>>>>> app nearly impossible to run from lightweight container-deployable
>>>>>> microservices perspective.
>>>>>>
>>>>>> 2) The single jar embeds a lot of other cross-project
>> dependencies
>>>>>> that
>>>>>> might not be desirable (for example: Jetty). We all know Java
>> classpath
>>>>>> management can be very challenging, and including unnecessary
>> libraries
>>>>>> when we only want to use a tiny part of that system is definitely an
>>>>>> anti-pattern. Usage just as a client or a minimum subset of
>>>> functionality
>>>>>> forces the classpath to have libraries we absolutely don't want.
>>>>>>
>>>>>>
>>>>>> A good example of the above is trying to build a SpringBoot app as a
>>>> Geode
>>>>>> *client*. SpringBoot dependencies will conflict with logging
>>>> frameworks,
>>>>>> Jetty and other jars embedded into Geode and make it nearly impossible
>>>> to
>>>>>> build a SpringBoot microservice powered by Geode.
>>>>>>
>>>>>> A simple docker container image would also be on the hundreds of
>>>>>> megabytes,
>>>>>> which seems extremely high for cloud platform deployment.
>>>>>>
>>>>>> IMO if we want to increase the project adoption we need to break the
>>>> Geode
>>>>>> build ASAP in *at least* Geode-server and Geode-client asap. We
>> should
>>>>>> also consider better on how to package other project dependencies like
>>>>>> log4j/sf4j.
>>>>>> Further divisions into modules like Geode-WAN would also be important.
>>>>>>
>>>>>> thoughts?
>>>>>>
>>>>>> Fred
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Fred Melo
>>>>>> fmelo@pivotal.io
>>>>>> +1-650-3021360
>>
>> --
> Fred Melo
> fmelo@pivotal.io
> +1-650-3021360
Re: Packaging and dependencies
Posted by Fred Melo <fm...@pivotal.io>.
Exactly. Thanks everyone for chiming in.
On Mon, Mar 14, 2016 at 4:12 PM Udo Kohlmeyer <uk...@pivotal.io> wrote:
> +1
>
> This should also simplify the client and server code base...
>
> The step after that should be different libraries for different
> functionality in the product. If you need WAN, then you add WAN lib and
> if you need CQ's you can add that lib. We then end up with very modular
> application and only load what is required.
>
> --Udo
>
> On 15/03/2016 10:03 am, Dan Smith wrote:
> > +1 to splitting things up with a view making a smaller client and core
> jar.
> >
> > BTW, I'm currently working on GEODE-27. One of the things I'm doing is
> > marking a bunch of the dependencies such as jetty as optional in our pom.
> > But that's not the real fix. The fix is to move the code that depends on
> > those libraries out of geode-core. There are some subtasks under
> GEODE-818
> > describing some of the work that needs to happen there.
> >
> > -Dan
> >
> > On Mon, Mar 14, 2016 at 3:54 PM, Anilkumar Gingade <ag...@pivotal.io>
> > wrote:
> >
> >> Adding to that, for mobile apps our recommendation was to use REST APIs.
> >>
> >> -Anil.
> >>
> >>
> >> On Mon, Mar 14, 2016 at 3:51 PM, Anilkumar Gingade <agingade@pivotal.io
> >
> >> wrote:
> >>
> >>> Hi Fred,
> >>>
> >>> You are right, with micro-services and mobile applications getting
> >>> prominent there is a need to separate our client code...This had came
> up
> >>> multiple times in our product road-map (previously)...but never got
> >>> prioritized as no customer pushed for this...
> >>>
> >>> -Anil.
> >>>
> >>>
> >>>
> >>> On Mon, Mar 14, 2016 at 3:11 PM, Fred Melo <fm...@pivotal.io> wrote:
> >>>
> >>>> Folks,
> >>>>
> >>>> Data Microservices use cases are getting more and more popular
> and
> >>>> libraries like SpringBoot + Geode can be a pretty powerful combo.
> >>>>
> >>>> However, there are serious challenges on how we package and
> >> distribute
> >>>> Geode through its maven
> >>>> repository (org.apache.geode:gemfire-core:1.0.0-incubating-SNAPSHOT)
> >>>> today,
> >>>> all within a single uber jar and over 100Mb in size:
> >>>>
> >>>> 1) It forces a simple microservice app running in small
> containers
> >> to
> >>>> include that giant dependency, even if only looking for only the
> client
> >>>> module for example.
> >>>> It seems very odd in my point of view to pack the entire product
> >> binaries
> >>>> and add a 100Mb jar only for accessing Geode as a *client app*, making
> >>>> that
> >>>> app nearly impossible to run from lightweight container-deployable
> >>>> microservices perspective.
> >>>>
> >>>> 2) The single jar embeds a lot of other cross-project
> dependencies
> >>>> that
> >>>> might not be desirable (for example: Jetty). We all know Java
> classpath
> >>>> management can be very challenging, and including unnecessary
> libraries
> >>>> when we only want to use a tiny part of that system is definitely an
> >>>> anti-pattern. Usage just as a client or a minimum subset of
> >> functionality
> >>>> forces the classpath to have libraries we absolutely don't want.
> >>>>
> >>>>
> >>>> A good example of the above is trying to build a SpringBoot app as a
> >> Geode
> >>>> *client*. SpringBoot dependencies will conflict with logging
> >> frameworks,
> >>>> Jetty and other jars embedded into Geode and make it nearly impossible
> >> to
> >>>> build a SpringBoot microservice powered by Geode.
> >>>>
> >>>> A simple docker container image would also be on the hundreds of
> >>>> megabytes,
> >>>> which seems extremely high for cloud platform deployment.
> >>>>
> >>>> IMO if we want to increase the project adoption we need to break the
> >> Geode
> >>>> build ASAP in *at least* Geode-server and Geode-client asap. We
> should
> >>>> also consider better on how to package other project dependencies like
> >>>> log4j/sf4j.
> >>>> Further divisions into modules like Geode-WAN would also be important.
> >>>>
> >>>> thoughts?
> >>>>
> >>>> Fred
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Fred Melo
> >>>> fmelo@pivotal.io
> >>>> +1-650-3021360
> >>>>
> >>>
>
> --
Fred Melo
fmelo@pivotal.io
+1-650-3021360
Re: Packaging and dependencies
Posted by Udo Kohlmeyer <uk...@pivotal.io>.
+1
This should also simplify the client and server code base...
The step after that should be different libraries for different
functionality in the product. If you need WAN, then you add WAN lib and
if you need CQ's you can add that lib. We then end up with very modular
application and only load what is required.
--Udo
On 15/03/2016 10:03 am, Dan Smith wrote:
> +1 to splitting things up with a view making a smaller client and core jar.
>
> BTW, I'm currently working on GEODE-27. One of the things I'm doing is
> marking a bunch of the dependencies such as jetty as optional in our pom.
> But that's not the real fix. The fix is to move the code that depends on
> those libraries out of geode-core. There are some subtasks under GEODE-818
> describing some of the work that needs to happen there.
>
> -Dan
>
> On Mon, Mar 14, 2016 at 3:54 PM, Anilkumar Gingade <ag...@pivotal.io>
> wrote:
>
>> Adding to that, for mobile apps our recommendation was to use REST APIs.
>>
>> -Anil.
>>
>>
>> On Mon, Mar 14, 2016 at 3:51 PM, Anilkumar Gingade <ag...@pivotal.io>
>> wrote:
>>
>>> Hi Fred,
>>>
>>> You are right, with micro-services and mobile applications getting
>>> prominent there is a need to separate our client code...This had came up
>>> multiple times in our product road-map (previously)...but never got
>>> prioritized as no customer pushed for this...
>>>
>>> -Anil.
>>>
>>>
>>>
>>> On Mon, Mar 14, 2016 at 3:11 PM, Fred Melo <fm...@pivotal.io> wrote:
>>>
>>>> Folks,
>>>>
>>>> Data Microservices use cases are getting more and more popular and
>>>> libraries like SpringBoot + Geode can be a pretty powerful combo.
>>>>
>>>> However, there are serious challenges on how we package and
>> distribute
>>>> Geode through its maven
>>>> repository (org.apache.geode:gemfire-core:1.0.0-incubating-SNAPSHOT)
>>>> today,
>>>> all within a single uber jar and over 100Mb in size:
>>>>
>>>> 1) It forces a simple microservice app running in small containers
>> to
>>>> include that giant dependency, even if only looking for only the client
>>>> module for example.
>>>> It seems very odd in my point of view to pack the entire product
>> binaries
>>>> and add a 100Mb jar only for accessing Geode as a *client app*, making
>>>> that
>>>> app nearly impossible to run from lightweight container-deployable
>>>> microservices perspective.
>>>>
>>>> 2) The single jar embeds a lot of other cross-project dependencies
>>>> that
>>>> might not be desirable (for example: Jetty). We all know Java classpath
>>>> management can be very challenging, and including unnecessary libraries
>>>> when we only want to use a tiny part of that system is definitely an
>>>> anti-pattern. Usage just as a client or a minimum subset of
>> functionality
>>>> forces the classpath to have libraries we absolutely don't want.
>>>>
>>>>
>>>> A good example of the above is trying to build a SpringBoot app as a
>> Geode
>>>> *client*. SpringBoot dependencies will conflict with logging
>> frameworks,
>>>> Jetty and other jars embedded into Geode and make it nearly impossible
>> to
>>>> build a SpringBoot microservice powered by Geode.
>>>>
>>>> A simple docker container image would also be on the hundreds of
>>>> megabytes,
>>>> which seems extremely high for cloud platform deployment.
>>>>
>>>> IMO if we want to increase the project adoption we need to break the
>> Geode
>>>> build ASAP in *at least* Geode-server and Geode-client asap. We should
>>>> also consider better on how to package other project dependencies like
>>>> log4j/sf4j.
>>>> Further divisions into modules like Geode-WAN would also be important.
>>>>
>>>> thoughts?
>>>>
>>>> Fred
>>>>
>>>>
>>>>
>>>> --
>>>> Fred Melo
>>>> fmelo@pivotal.io
>>>> +1-650-3021360
>>>>
>>>
Re: Packaging and dependencies
Posted by Anthony Baker <ab...@pivotal.io>.
Yep, some work on modularization is already underway:
-rw-r--r-- 1 abaker staff 1735 Mar 7 08:44 geode-common-1.0.0-incubating.M2-SNAPSHOT.jar
-rw-r--r-- 1 abaker staff 12810411 Mar 7 08:44 geode-core-1.0.0-incubating.M2-SNAPSHOT.jar
-rw-r--r-- 1 abaker staff 89629 Mar 7 08:44 geode-cq-1.0.0-incubating.M2-SNAPSHOT.jar
-rw-r--r-- 1 abaker staff 11522 Mar 7 08:44 geode-jca-1.0.0-incubating.M2-SNAPSHOT.rar
-rw-r--r-- 1 abaker staff 55084 Mar 7 08:44 geode-joptsimple-1.0.0-incubating.M2-SNAPSHOT.jar
-rw-r--r-- 1 abaker staff 42699 Mar 7 08:44 geode-json-1.0.0-incubating.M2-SNAPSHOT.jar
-rw-r--r-- 1 abaker staff 80351 Mar 7 08:44 geode-lucene-1.0.0-incubating.M2-SNAPSHOT.jar
-rw-r--r-- 1 abaker staff 78996 Mar 7 08:44 geode-wan-1.0.0-incubating.M2-SNAPSHOT.jar
-rw-r--r-- 1 abaker staff 116198 Mar 7 08:44 geode-web-1.0.0-incubating.M2-SNAPSHOT.jar
-rw-r--r-- 1 abaker staff 74867 Mar 7 08:44 geode-web-api-1.0.0-incubating.M2-SNAPSHOT.jar
Anthony
> On Mar 14, 2016, at 4:03 PM, Dan Smith <ds...@pivotal.io> wrote:
>
> +1 to splitting things up with a view making a smaller client and core jar.
>
> BTW, I'm currently working on GEODE-27. One of the things I'm doing is
> marking a bunch of the dependencies such as jetty as optional in our pom.
> But that's not the real fix. The fix is to move the code that depends on
> those libraries out of geode-core. There are some subtasks under GEODE-818
> describing some of the work that needs to happen there.
>
> -Dan
>
> On Mon, Mar 14, 2016 at 3:54 PM, Anilkumar Gingade <ag...@pivotal.io>
> wrote:
>
>> Adding to that, for mobile apps our recommendation was to use REST APIs.
>>
>> -Anil.
>>
>>
>> On Mon, Mar 14, 2016 at 3:51 PM, Anilkumar Gingade <ag...@pivotal.io>
>> wrote:
>>
>>> Hi Fred,
>>>
>>> You are right, with micro-services and mobile applications getting
>>> prominent there is a need to separate our client code...This had came up
>>> multiple times in our product road-map (previously)...but never got
>>> prioritized as no customer pushed for this...
>>>
>>> -Anil.
>>>
>>>
>>>
>>> On Mon, Mar 14, 2016 at 3:11 PM, Fred Melo <fm...@pivotal.io> wrote:
>>>
>>>> Folks,
>>>>
>>>> Data Microservices use cases are getting more and more popular and
>>>> libraries like SpringBoot + Geode can be a pretty powerful combo.
>>>>
>>>> However, there are serious challenges on how we package and
>> distribute
>>>> Geode through its maven
>>>> repository (org.apache.geode:gemfire-core:1.0.0-incubating-SNAPSHOT)
>>>> today,
>>>> all within a single uber jar and over 100Mb in size:
>>>>
>>>> 1) It forces a simple microservice app running in small containers
>> to
>>>> include that giant dependency, even if only looking for only the client
>>>> module for example.
>>>> It seems very odd in my point of view to pack the entire product
>> binaries
>>>> and add a 100Mb jar only for accessing Geode as a *client app*, making
>>>> that
>>>> app nearly impossible to run from lightweight container-deployable
>>>> microservices perspective.
>>>>
>>>> 2) The single jar embeds a lot of other cross-project dependencies
>>>> that
>>>> might not be desirable (for example: Jetty). We all know Java classpath
>>>> management can be very challenging, and including unnecessary libraries
>>>> when we only want to use a tiny part of that system is definitely an
>>>> anti-pattern. Usage just as a client or a minimum subset of
>> functionality
>>>> forces the classpath to have libraries we absolutely don't want.
>>>>
>>>>
>>>> A good example of the above is trying to build a SpringBoot app as a
>> Geode
>>>> *client*. SpringBoot dependencies will conflict with logging
>> frameworks,
>>>> Jetty and other jars embedded into Geode and make it nearly impossible
>> to
>>>> build a SpringBoot microservice powered by Geode.
>>>>
>>>> A simple docker container image would also be on the hundreds of
>>>> megabytes,
>>>> which seems extremely high for cloud platform deployment.
>>>>
>>>> IMO if we want to increase the project adoption we need to break the
>> Geode
>>>> build ASAP in *at least* Geode-server and Geode-client asap. We should
>>>> also consider better on how to package other project dependencies like
>>>> log4j/sf4j.
>>>> Further divisions into modules like Geode-WAN would also be important.
>>>>
>>>> thoughts?
>>>>
>>>> Fred
>>>>
>>>>
>>>>
>>>> --
>>>> Fred Melo
>>>> fmelo@pivotal.io
>>>> +1-650-3021360
>>>>
>>>
>>>
>>
Re: Packaging and dependencies
Posted by Dan Smith <ds...@pivotal.io>.
+1 to splitting things up with a view making a smaller client and core jar.
BTW, I'm currently working on GEODE-27. One of the things I'm doing is
marking a bunch of the dependencies such as jetty as optional in our pom.
But that's not the real fix. The fix is to move the code that depends on
those libraries out of geode-core. There are some subtasks under GEODE-818
describing some of the work that needs to happen there.
-Dan
On Mon, Mar 14, 2016 at 3:54 PM, Anilkumar Gingade <ag...@pivotal.io>
wrote:
> Adding to that, for mobile apps our recommendation was to use REST APIs.
>
> -Anil.
>
>
> On Mon, Mar 14, 2016 at 3:51 PM, Anilkumar Gingade <ag...@pivotal.io>
> wrote:
>
> > Hi Fred,
> >
> > You are right, with micro-services and mobile applications getting
> > prominent there is a need to separate our client code...This had came up
> > multiple times in our product road-map (previously)...but never got
> > prioritized as no customer pushed for this...
> >
> > -Anil.
> >
> >
> >
> > On Mon, Mar 14, 2016 at 3:11 PM, Fred Melo <fm...@pivotal.io> wrote:
> >
> >> Folks,
> >>
> >> Data Microservices use cases are getting more and more popular and
> >> libraries like SpringBoot + Geode can be a pretty powerful combo.
> >>
> >> However, there are serious challenges on how we package and
> distribute
> >> Geode through its maven
> >> repository (org.apache.geode:gemfire-core:1.0.0-incubating-SNAPSHOT)
> >> today,
> >> all within a single uber jar and over 100Mb in size:
> >>
> >> 1) It forces a simple microservice app running in small containers
> to
> >> include that giant dependency, even if only looking for only the client
> >> module for example.
> >> It seems very odd in my point of view to pack the entire product
> binaries
> >> and add a 100Mb jar only for accessing Geode as a *client app*, making
> >> that
> >> app nearly impossible to run from lightweight container-deployable
> >> microservices perspective.
> >>
> >> 2) The single jar embeds a lot of other cross-project dependencies
> >> that
> >> might not be desirable (for example: Jetty). We all know Java classpath
> >> management can be very challenging, and including unnecessary libraries
> >> when we only want to use a tiny part of that system is definitely an
> >> anti-pattern. Usage just as a client or a minimum subset of
> functionality
> >> forces the classpath to have libraries we absolutely don't want.
> >>
> >>
> >> A good example of the above is trying to build a SpringBoot app as a
> Geode
> >> *client*. SpringBoot dependencies will conflict with logging
> frameworks,
> >> Jetty and other jars embedded into Geode and make it nearly impossible
> to
> >> build a SpringBoot microservice powered by Geode.
> >>
> >> A simple docker container image would also be on the hundreds of
> >> megabytes,
> >> which seems extremely high for cloud platform deployment.
> >>
> >> IMO if we want to increase the project adoption we need to break the
> Geode
> >> build ASAP in *at least* Geode-server and Geode-client asap. We should
> >> also consider better on how to package other project dependencies like
> >> log4j/sf4j.
> >> Further divisions into modules like Geode-WAN would also be important.
> >>
> >> thoughts?
> >>
> >> Fred
> >>
> >>
> >>
> >> --
> >> Fred Melo
> >> fmelo@pivotal.io
> >> +1-650-3021360
> >>
> >
> >
>
Re: Packaging and dependencies
Posted by Anilkumar Gingade <ag...@pivotal.io>.
Adding to that, for mobile apps our recommendation was to use REST APIs.
-Anil.
On Mon, Mar 14, 2016 at 3:51 PM, Anilkumar Gingade <ag...@pivotal.io>
wrote:
> Hi Fred,
>
> You are right, with micro-services and mobile applications getting
> prominent there is a need to separate our client code...This had came up
> multiple times in our product road-map (previously)...but never got
> prioritized as no customer pushed for this...
>
> -Anil.
>
>
>
> On Mon, Mar 14, 2016 at 3:11 PM, Fred Melo <fm...@pivotal.io> wrote:
>
>> Folks,
>>
>> Data Microservices use cases are getting more and more popular and
>> libraries like SpringBoot + Geode can be a pretty powerful combo.
>>
>> However, there are serious challenges on how we package and distribute
>> Geode through its maven
>> repository (org.apache.geode:gemfire-core:1.0.0-incubating-SNAPSHOT)
>> today,
>> all within a single uber jar and over 100Mb in size:
>>
>> 1) It forces a simple microservice app running in small containers to
>> include that giant dependency, even if only looking for only the client
>> module for example.
>> It seems very odd in my point of view to pack the entire product binaries
>> and add a 100Mb jar only for accessing Geode as a *client app*, making
>> that
>> app nearly impossible to run from lightweight container-deployable
>> microservices perspective.
>>
>> 2) The single jar embeds a lot of other cross-project dependencies
>> that
>> might not be desirable (for example: Jetty). We all know Java classpath
>> management can be very challenging, and including unnecessary libraries
>> when we only want to use a tiny part of that system is definitely an
>> anti-pattern. Usage just as a client or a minimum subset of functionality
>> forces the classpath to have libraries we absolutely don't want.
>>
>>
>> A good example of the above is trying to build a SpringBoot app as a Geode
>> *client*. SpringBoot dependencies will conflict with logging frameworks,
>> Jetty and other jars embedded into Geode and make it nearly impossible to
>> build a SpringBoot microservice powered by Geode.
>>
>> A simple docker container image would also be on the hundreds of
>> megabytes,
>> which seems extremely high for cloud platform deployment.
>>
>> IMO if we want to increase the project adoption we need to break the Geode
>> build ASAP in *at least* Geode-server and Geode-client asap. We should
>> also consider better on how to package other project dependencies like
>> log4j/sf4j.
>> Further divisions into modules like Geode-WAN would also be important.
>>
>> thoughts?
>>
>> Fred
>>
>>
>>
>> --
>> Fred Melo
>> fmelo@pivotal.io
>> +1-650-3021360
>>
>
>
Re: Packaging and dependencies
Posted by Anilkumar Gingade <ag...@pivotal.io>.
Hi Fred,
You are right, with micro-services and mobile applications getting
prominent there is a need to separate our client code...This had came up
multiple times in our product road-map (previously)...but never got
prioritized as no customer pushed for this...
-Anil.
On Mon, Mar 14, 2016 at 3:11 PM, Fred Melo <fm...@pivotal.io> wrote:
> Folks,
>
> Data Microservices use cases are getting more and more popular and
> libraries like SpringBoot + Geode can be a pretty powerful combo.
>
> However, there are serious challenges on how we package and distribute
> Geode through its maven
> repository (org.apache.geode:gemfire-core:1.0.0-incubating-SNAPSHOT) today,
> all within a single uber jar and over 100Mb in size:
>
> 1) It forces a simple microservice app running in small containers to
> include that giant dependency, even if only looking for only the client
> module for example.
> It seems very odd in my point of view to pack the entire product binaries
> and add a 100Mb jar only for accessing Geode as a *client app*, making that
> app nearly impossible to run from lightweight container-deployable
> microservices perspective.
>
> 2) The single jar embeds a lot of other cross-project dependencies that
> might not be desirable (for example: Jetty). We all know Java classpath
> management can be very challenging, and including unnecessary libraries
> when we only want to use a tiny part of that system is definitely an
> anti-pattern. Usage just as a client or a minimum subset of functionality
> forces the classpath to have libraries we absolutely don't want.
>
>
> A good example of the above is trying to build a SpringBoot app as a Geode
> *client*. SpringBoot dependencies will conflict with logging frameworks,
> Jetty and other jars embedded into Geode and make it nearly impossible to
> build a SpringBoot microservice powered by Geode.
>
> A simple docker container image would also be on the hundreds of megabytes,
> which seems extremely high for cloud platform deployment.
>
> IMO if we want to increase the project adoption we need to break the Geode
> build ASAP in *at least* Geode-server and Geode-client asap. We should
> also consider better on how to package other project dependencies like
> log4j/sf4j.
> Further divisions into modules like Geode-WAN would also be important.
>
> thoughts?
>
> Fred
>
>
>
> --
> Fred Melo
> fmelo@pivotal.io
> +1-650-3021360
>
RE: Packaging and dependencies
Posted by ma...@daimler.com.
Hi Fred,
I totally agree to that request. We should avoid to break this into a hell of package dependencies like server, core, client, ... But a more friendly packaging would be great. I would also vote for two packages first and the go from there.
Best Regards
Manuel Birke
Mercedes-Benz Research & Development North America, Inc.
Address: 309 N Pastoria Ave | Sunnyvale, CA 94085
Mobile: +1 408-203-6026
Phone: +1 408-991-6502
________________________________
From: Fred Melo<ma...@pivotal.io>
Sent: 3/14/2016 15:12
To: dev@geode.incubator.apache.org<ma...@geode.incubator.apache.org>
Subject: Packaging and dependencies
Folks,
Data Microservices use cases are getting more and more popular and
libraries like SpringBoot + Geode can be a pretty powerful combo.
However, there are serious challenges on how we package and distribute
Geode through its maven
repository (org.apache.geode:gemfire-core:1.0.0-incubating-SNAPSHOT) today,
all within a single uber jar and over 100Mb in size:
1) It forces a simple microservice app running in small containers to
include that giant dependency, even if only looking for only the client
module for example.
It seems very odd in my point of view to pack the entire product binaries
and add a 100Mb jar only for accessing Geode as a *client app*, making that
app nearly impossible to run from lightweight container-deployable
microservices perspective.
2) The single jar embeds a lot of other cross-project dependencies that
might not be desirable (for example: Jetty). We all know Java classpath
management can be very challenging, and including unnecessary libraries
when we only want to use a tiny part of that system is definitely an
anti-pattern. Usage just as a client or a minimum subset of functionality
forces the classpath to have libraries we absolutely don't want.
A good example of the above is trying to build a SpringBoot app as a Geode
*client*. SpringBoot dependencies will conflict with logging frameworks,
Jetty and other jars embedded into Geode and make it nearly impossible to
build a SpringBoot microservice powered by Geode.
A simple docker container image would also be on the hundreds of megabytes,
which seems extremely high for cloud platform deployment.
IMO if we want to increase the project adoption we need to break the Geode
build ASAP in *at least* Geode-server and Geode-client asap. We should
also consider better on how to package other project dependencies like
log4j/sf4j.
Further divisions into modules like Geode-WAN would also be important.
thoughts?
Fred
--
Fred Melo
fmelo@pivotal.io
+1-650-3021360
If you are not the addressee, please inform us immediately that you have received this e-mail by mistake, and delete it. We thank you for your support.