Mike, If the product has to be based on Geode, then we just take Geode as built in the open, package up the GemFire add-ons and ship it. Any attempt to take in the source code, process it and change it etc. will beat the whole point and introduce too many unintended consequences. I would not prefer this option. Our customer want open source core, thats what we give them, because otherwise we have not dealt with the vendor lock in issue that open source renders irrelevant.
Suds On Wed, Jul 1, 2015 at 1:54 PM, Michael Stolz <[email protected]> wrote: > I have already suggested that we go ahead and do all the re-packaging for > Geode, but that before we build the enterprise version we use a > pre-processing script that automatically re-packages all org.Apache.Geode > to com.Gemstone.Gemfire as part of the build process so that WE eat the > difficulty of the necessary open-source re-packaging rather than hundreds > of customers with millions of lines of code that they would need to change. > > > -- > Mike Stolz > Principal Technical Account Manager > Mobile: 631-835-4771 > > On Wed, Jul 1, 2015 at 4:16 PM, Bruce Schuchardt <[email protected]> > wrote: > > > Mike, this seems like something to bring up with GemFire product > > management. > > > > As I understand it the main problem for client/server is that there are > > some objects, especially exceptions, that are transmitted via java > > serialization and the package renaming is going to break compatibility. > > For data-serialization we can swizzle package names but that's not > possible > > for plain old java serialization. > > > > For peer-to-peer it is also going to be broken because we can't use the > > old 2.2.9 version of JGroups and make it out of incubation. Newer > versions > > of JGroups are on-wire incompatible with 2.2.9. > > > > > > > > Le 7/1/2015 12:50 PM, Michael Stolz a écrit : > > > >> This notion of propagating a breaking change to all Enterprise users is > >> going to be extremely traumatic. > >> > >> Customers are already raising their voices about them having to endure a > >> breaking change to THEIR CODE for the sake of the opensource version > being > >> made available for free totally unacceptable. > >> > >> We MUST find a way to keep the Enterprise version backward compatible or > >> we > >> risk a wholesale migration of enterprise customers to other solutions. > >> > >> -- > >> Mike Stolz > >> Principal Technical Account Manager > >> Mobile: 631-835-4771 > >> On Jul 1, 2015 12:10 PM, "Bruce Schuchardt" <[email protected]> > >> wrote: > >> > >> Geode-72 <https://issues.apache.org/jira/browse/GEODE-72> calls for > >>> removing rolling upgrade code for old GemFire releases. There's no > reason > >>> for Geode code to be cluttered up with rolling upgrade code for old > >>> GemFire > >>> releases since you won't be able to do a rolling upgrade from those > >>> releases to Geode due to package renaming. > >>> > >>> > > > -- Suds Menon Head of Products (Real Time & Big Data) 503-724-1481 (c) For prompt responses to questions on GemFire/SQLFire, please write to rtds-dev-ea at gopivotal dot com
