GEMFIRE_HOME was used primarily to avoid having to require that the user set a CLASSPATH. Some of the code may have relied on walking backwards from a shell script to discover the GEMFIRE_HOME and its jar files.
It's also used in documentation to facilitate talking about the root of a GEMFIRE installation. I *think* we could do away with it entirely (and I'd prefer that). On Mon, Mar 21, 2016 at 4:13 PM, Udo Kohlmeyer <[email protected]> wrote: > Any idea why we would rely on a GEODE_HOME at all. Would we not include > the relevant libraries on the classpath? > > Maybe I'm missing a use case here.. > > > On 22/03/2016 9:59 am, Jens Deppe wrote: > >> +1 for GEODE_HOME >> >> Just a note on this. I'm not sure where all the GEMFIRE env variable is >> currently used, but I do know it gets used to find the various war files >> we >> have. We've recently added code to also discover these wars on the >> classpath. This allows, for example, an embedded locator to find and run >> Pulse without having to also set this env variable. >> >> If your code is reliant on the GEMFIRE env variable please consider adding >> logic to obviate the need for it. >> >> --Jens >> >> On Mon, Mar 21, 2016 at 3:50 PM, Udo Kohlmeyer <[email protected]> >> wrote: >> >> Hi there. >>> >>> There seems to be some reliance of the GEMFIRE system environment >>> variable. >>> Would we not want to change this to GEODE or maybe GEODE_HOME? >>> >>> --Udo >>> >>> >
