Have we looked at what it would take to build a facade in GemFire to maintain the Gemstone packaging but actually referencing the new Geode structures? We could depreciate the totality of the facade as a way to signal to existing enterprise customers that they need to start migrating. Granted it is alot of shell code but addresses Mike's point about enterprise customer revolt and give a graceful way to get customers off of the gemstone packages in the future.
John On Wed, Jul 1, 2015 at 7:17 PM, Sudhir Menon <[email protected]> wrote: > 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 >
