Re: Third Iteration of Java Modules Support

Yeah that would fix one of a dozen “leaked” internal packages. Baby steps! -Jake > On Dec 3, 2018, at 4:32 PM, Kirk Lund wrote: > > Moving internal.logging to geode-logging would involve moving some > internal.logging classes to org.apache.geode.logging. I think that would > help with the

Re: Third Iteration of Java Modules Support

Moving internal.logging to geode-logging would involve moving some internal.logging classes to org.apache.geode.logging. I think that would help with the logging portion of what you're doing. On Mon, Dec 3, 2018 at 4:30 PM Kirk Lund wrote: > I'm iteratively cleaning up geode's internal logging

Re: Third Iteration of Java Modules Support

I'm iteratively cleaning up geode's internal logging (specifically our dependency on log4j core) so that log4j core can be optional and a user could switch it out for logback or do further customization of our logging. Even without the modules work you're doing, moving our logging internals to a

Re: [VOTE] Apache Geode 1.8.0 RC1

Thanks for finding the issue, Dan! Let's cancel this vote and do another one, once these issues are resolved. On Mon, Dec 3, 2018 at 2:27 PM Dan Smith wrote: > -1 for the this RC based on these native source issues: > > * Missing license headers: native_shared_ptr.hpp and others listed by >

Re: [VOTE] Apache Geode 1.8.0 RC1

I can look into the files missing license headers when I get home (probably in an hour or so). The cmake-build-debug directory is a thing left behind by JetBrains products, so probably just developer cruft. There’s apparently a doc change I have to cherry-pick over to the release branch as well,

Re: [VOTE] Apache Geode 1.8.0 RC1

-1 for the this RC based on these native source issues: * Missing license headers: native_shared_ptr.hpp and others listed by travis) * Binary executables in the source distribution: cmake-build-debug * The source distribution is somehow missing this directory:

Re: [VOTE] Apache Geode 1.8.0 RC1

I see some issues with the native source release that I think are a problem. I looked into the travis for the native code - it looks like travis is passing, but finding files with missing license headers? Eg /geode-native/clicache/src/native_shared_ptr.hpp.

Third Iteration of Java Modules Support

All, I’ll start with yuck! I took a stab at adding module-info.java files to core and cq and it isn’t pretty. So all the work done in he second iteration, internal package refactoring, etc., also has to be done for real modules. To achieve this we basically have to compile the sources in a

Re: [VOTE] Apache Geode 1.8.0 RC1

Thanks again for all the input! Both Geode and Geode Native source distributions are now signed with an armored signature. Release manager docs are updated accordingly. I also added tickets to make the geode build also the sign source release

Re: [VOTE] Apache Geode 1.8.0 RC1

+1. Thanks Owen On Mon, Dec 3, 2018, 10:07 Owen Nichols > 2. No zip file for the geode, just .tgz. > > I believe this was changed a few months ago to simplify our build and > release process. Distributing as both .zip and .tgz is a relic of a time > before WinZip, WinRar, 7-Zip, and most other

Re: [VOTE] Apache Geode 1.8.0 RC1

> 2. No zip file for the geode, just .tgz. I believe this was changed a few months ago to simplify our build and release process. Distributing as both .zip and .tgz is a relic of a time before WinZip, WinRar, 7-Zip, and most other popular zip utilities gained native support for .tgz

Re: [VOTE] Apache Geode 1.8.0 RC1

for geode-native following Building.md is a good verfication On Mon, Dec 3, 2018 at 11:02 AM Nabarun Nag wrote: > Thank you Alexander and Anthony for the explanation. > I am sorry for missing the signature checks for the apache geode src. :( > Was able to build and run geode-native code. > >

Re: [VOTE] Apache Geode 1.8.0 RC1

Thank you Alexander and Anthony for the explanation. I am sorry for missing the signature checks for the apache geode src. :( Was able to build and run geode-native code. Regards Nabarun Nag On Mon, Dec 3, 2018 at 9:52 AM Dan Smith wrote: > I see a few things with the artifacts that I think

Re: [VOTE] Apache Geode 1.8.0 RC1

I see a few things with the artifacts that I think should be tweaked 1. No pgp signature for the sources! 2. No zip file for the geode, just .tgz. Older releases on our website have both zip and tgz. See the differences between [1] and [2] 3. pgp signature for the native source is not ascii

Re: Serializing Internal Classes

This would be a good addition to the AnalzeSerializablesJUnitTest. Banning non-DSFID DataSerializables in product code seems like a good idea. On Fri, Nov 30, 2018 at 2:12 PM Michael Stolz wrote: > Jake thanks for bringing this up. > Could have been a big waste of effort if you hadnt. > > -- >

Re: [VOTE] Apache Geode 1.8.0 RC1

Thanks for taking such a detailed a look, Nabarun! That's awesome input. 1. Is there a reason why geode-native is signed with SHA512 while all the > rest are signed with SHA256? Not really. I used the defaults provided by the Gradle signing task in the case of the core codebase and the GPG

Re: [VOTE] Apache Geode 1.8.0 RC1

The ‘gradlew’ script in the source distribution is expected to differ. The gradew[.bat] files generated by gradle rely on the presence of a jar file. We’re using a wrapper script that will download the jar file if needed. This is consistent with a number of other apache projects. KEYS is

Re: [VOTE] Apache Geode 1.8.0 RC1

Following checks completed: - checked signatures - checked SHA's - builds from source [geode] - run gfsh - start locator, server - create region - do put and get - execute OQL query - examples run cleanly [geode-examples] - the correct version in gfsh command version Questions: 1. Is there a