At the very least we should be adding a manifest-only <component>-dependencies.jar that can simply be added to the classpath.
--Jens On Fri, Feb 19, 2016 at 3:57 PM, Dan Smith <[email protected]> wrote: > 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 > >> > > > >> > > > >> > > > >> > > > > >
