I do think we need to work on making geode more modular, and make some of these components easier to enable/disable.
-Dan On Fri, Feb 19, 2016 at 3:49 PM, Dan Smith <[email protected]> wrote: > I added GEODE-991 for the fact that LuceneFunction shows up in the list. > > I don't think hbase is currently being used. I'm mentioned that on > GEODE-818 that we need to get rid of that. > > -Dan > > > On Fri, Feb 19, 2016 at 3:08 PM, Anilkumar Gingade <[email protected]> > wrote: > >> Its about usability and simplicity; the end users look at the product >> features and expects that to be in the downloaded >> product/artifacts...Separating out may be additional work for end user... >> >> -Anil. >> >> >> On Fri, Feb 19, 2016 at 2:30 PM, Nitin Lamba <[email protected]> wrote: >> >> > Hi Dan, >> > >> > I see - thanks for the detailed explanation! >> > >> > In the spirit of modularity and cleaner dependencies, the core should >> not >> > depend on any custom integrations on application (Spark, Redis, Lucene) >> or >> > storage side (HDFS, HBase?). I also see hbase jar within >> 'apache-geode/lib' >> > directory. Do you know what that is used for? >> > >> > To answer your question, such dependencies should ideally be pulled-in >> > only at runtime or better be configurable. Seems Zeppelin has a concept >> of >> > profiles that builds 'integration-specific' artifacts. >> > >> > I'm sure this is easier said than done but that's a starting view... >> > >> > Thanks, >> > Nitin >> > >> > ________________________________________ >> > From: Dan Smith <[email protected]> >> > Sent: Friday, February 19, 2016 2:09 PM >> > To: geode >> > Subject: Re: Lucene function added by default >> > >> > Hi Nitin, >> > >> > I think this is a bug that the function shows up in that list. We >> actually >> > have a lot of other internal functions that don't show up in that list >> > because they implement the "InternalEntity" marker interface. So this >> > function should probably implement that as well. >> > >> > There's another question this brings up, which is whether the lucene >> > integration and lucene jars should be added by default to the classpath >> > when you start a gemfire server. That I'm not as sure about. Thoughts? >> > >> > -Dan >> > >> > On Fri, Feb 19, 2016 at 1:48 PM, Nitin Lamba <[email protected]> wrote: >> > >> > > Hi, >> > > >> > > >> > > While starting-up a new geode cluster, I see that a lucene function is >> > > registered even before any regions are created. Following are the >> simple >> > > steps to reproduce it: >> > > >> > > >> > > ./bin/gfsh >> > > >> > > gfsh>start locator --name=Locator >> > > >> > > gfsh>start server --name=Server1 >> > > >> > > gfsh>list functions >> > > >> > > >> > > Member | Function >> > > >> > > ------- | >> > > --------------------------------------------------------------------- >> > > >> > > Server1 | >> > > com.gemstone.gemfire.cache.lucene.internal.distributed.LuceneFunction >> > > >> > > >> > > Is this expected/ necessary? I would expect such a function to be >> defined >> > > only when Lucene integration is intended to be used. Please advise if >> a >> > > JIRA should be opened for this. >> > > >> > > >> > > Thanks, >> > > >> > > Nitin >> > > >> > > >> > > >> > >
