Review Request 38060: GEODE-300 new gradle script for Pulse

[Nitin Lamba]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/38060/
---

Review request for geode, Jens Deppe, Mark Bretl, and Dan Smith.


Repository: geode


Description
---

Create new gradle script for PULSE to build archives (jar, war files) using the 
dependencies from existing ant build.xml file.

These chances will be tracked on GEODE-12 branch until all subtasks are 
completed.


Diffs
-

  build.gradle 3bad39c 
  gemfire-assembly/build.gradle 0e51563 
  gemfire-assembly/src/test/java/AgentUtilJUnitTest.java 0f7563b 
  pulse/build.gradle PRE-CREATION 
  settings.gradle 7f6ed61 

Diff: https://reviews.apache.org/r/38060/diff/


Testing
---

- pulse.war file gets generated correctly and placed in tools/Pulse folder
- Starting locator starts pulse within the embedded jetty instance
- Unit and integration tests are blocked. GEODE-304 is tracking the issue 
separately


Thanks,

Nitin Lamba

Re: Review Request 37973: GEODE-77: added more tests to increase code coverage for services

[Jason Huynh]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/37973/#review97473
---



gemfire-core/src/test/java/com/gemstone/gemfire/distributed/internal/membership/gms/membership/GMSJoinLeaveJUnitTest.java
 (line 408)


maybe add a check to make sure this flag is false before the remove?



gemfire-core/src/test/java/com/gemstone/gemfire/distributed/internal/tcpserver/TcpServerJUnitTest.java
 (line 30)


Use junit 4 annotations instead of extending TestCase?



gemfire-core/src/test/java/com/gemstone/gemfire/distributed/internal/tcpserver/TcpServerJUnitTest.java
 (line 47)


Would we be able to add comments or a description of what this test is 
doing?



gemfire-core/src/test/java/com/gemstone/gemfire/distributed/internal/tcpserver/TcpServerJUnitTest.java
 (line 74)


I see we have a few sleeps after a countdown latch.  Is there a reason why 
the latch would be unlocked before the test was ready to continue?


- Jason Huynh


On Aug. 31, 2015, 11:05 p.m., Bruce Schuchardt wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/37973/
> ---
> 
> (Updated Aug. 31, 2015, 11:05 p.m.)
> 
> 
> Review request for geode, anilkumar gingade, Hitesh Khamesra, Jason Huynh, 
> Jianxia Chen, Lynn Gallinat, and Qihong Chen.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> JaCoCo now shows over 70% code coverage for the new membership service 
> components from these unit tests alone:
> 
> MembershipJUnitTest
> LocatorJUnitTest
> GMSLocatorJUnitTest
> JGroupsMessengerJUnitTest
> GMSHealthMonitorJUnitTest
> GMSAuthenticatorJUnitTest
> GMSJoinLeaveJUnitTest
> 
> 
> Coverage:
> 
> GMSAuthenticator - 98%
> GMSHealthMonitor - 77%
> GMSJoinLeave - 80%
> GMSLocator - 77%
> JGroupsMessenger - 71%
> 
> AddressManager - 79%
> GMSUtil - 77%
> Services - 76%
> ServiceConfig - 72%
> StatRecorder - 79%
> 
> 
> Diffs
> -
> 
>   
> gemfire-core/src/main/java/com/gemstone/gemfire/distributed/DistributedSystem.java
>  3f8040e 
>   
> gemfire-core/src/main/java/com/gemstone/gemfire/distributed/internal/InternalLocator.java
>  cfda513 
>   
> gemfire-core/src/main/java/com/gemstone/gemfire/distributed/internal/membership/MemberFactory.java
>  de469d8 
>   
> gemfire-core/src/main/java/com/gemstone/gemfire/distributed/internal/membership/MemberServices.java
>  9e6c27c 
>   
> gemfire-core/src/main/java/com/gemstone/gemfire/distributed/internal/membership/NetView.java
>  7b86159 
>   
> gemfire-core/src/main/java/com/gemstone/gemfire/distributed/internal/membership/gms/GMSMemberFactory.java
>  34e1123 
>   
> gemfire-core/src/main/java/com/gemstone/gemfire/distributed/internal/membership/gms/locator/GMSLocator.java
>  dd4ac51 
>   
> gemfire-core/src/main/java/com/gemstone/gemfire/distributed/internal/membership/gms/messenger/JGroupsMessenger.java
>  a653110 
>   
> gemfire-core/src/main/java/com/gemstone/gemfire/distributed/internal/membership/gms/messenger/StatRecorder.java
>  49dc423 
>   
> gemfire-core/src/test/java/com/gemstone/gemfire/distributed/LocatorJUnitTest.java
>  db7c217 
>   
> gemfire-core/src/test/java/com/gemstone/gemfire/distributed/internal/membership/gms/locator/GMSLocatorJUnitTest.java
>  e79dcbc 
>   
> gemfire-core/src/test/java/com/gemstone/gemfire/distributed/internal/membership/gms/membership/GMSJoinLeaveJUnitTest.java
>  cbabc20 
>   
> gemfire-core/src/test/java/com/gemstone/gemfire/distributed/internal/membership/gms/messenger/InterceptUDP.java
>  aafb466 
>   
> gemfire-core/src/test/java/com/gemstone/gemfire/distributed/internal/membership/gms/messenger/JGroupsMessengerJUnitTest.java
>  515c115 
>   
> gemfire-core/src/test/java/com/gemstone/gemfire/distributed/internal/tcpserver/TcpServerJUnitDisabledTest.java
>  1cab817 
>   
> gemfire-core/src/test/java/com/gemstone/gemfire/distributed/internal/tcpserver/TcpServerJUnitTest.java
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/37973/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Bruce Schuchardt
> 
>

Re: Review Request 38060: GEODE-300 new gradle script for Pulse

[Dan Smith]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/38060/#review97495
---

Ship it!


Hi Nitin,

Looks like good progress! I had a few comments/questions:

1. Is there are reason why you added the pulseCompile, pulseTestCompile 
configurations rather than just use the standard compile and testCompile ones?
2. I think it would be better to just rename and categorize the the tests to 
follow the conventions, rather than add different test and integrationTest 
targets. Maybe we can add another JIRA for that?


gemfire-assembly/build.gradle (line 188)


I don't think this is necessary to include the pulse jars in the lib 
directory - at least when I tried dropping a just the pulse war into the 
tools/Pulse directory with the old gemfire pulse it worked fine. I'm not sure 
what the classpath implications of putting them one place vs. the other are 
though.


- Dan Smith


On Sept. 2, 2015, 4:32 p.m., Nitin Lamba wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38060/
> ---
> 
> (Updated Sept. 2, 2015, 4:32 p.m.)
> 
> 
> Review request for geode, Jens Deppe, Mark Bretl, and Dan Smith.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Create new gradle script for PULSE to build archives (jar, war files) using 
> the dependencies from existing ant build.xml file.
> 
> These chances will be tracked on GEODE-12 branch until all subtasks are 
> completed.
> 
> 
> Diffs
> -
> 
>   build.gradle 3bad39c 
>   gemfire-assembly/build.gradle 0e51563 
>   gemfire-assembly/src/test/java/AgentUtilJUnitTest.java 0f7563b 
>   pulse/build.gradle PRE-CREATION 
>   settings.gradle 7f6ed61 
> 
> Diff: https://reviews.apache.org/r/38060/diff/
> 
> 
> Testing
> ---
> 
> - pulse.war file gets generated correctly and placed in tools/Pulse folder
> - Starting locator starts pulse within the embedded jetty instance
> - Unit and integration tests are blocked. GEODE-304 is tracking the issue 
> separately
> 
> 
> Thanks,
> 
> Nitin Lamba
> 
>

Re: [rtds-dev] Backward Compatibility and RollingUpgrade.

[Justin Erenkrantz]

On Wed, Sep 2, 2015 at 6:12 PM, Darrel Schneider  wrote:
> For backwards compatibility I see at least two levels of compatibility:
> 1. client compatibility: can an old client work with a new server?
> 2. code compatibility: can old code be used as is with the new product?
>a. class compatibility: can I use my already compiled old classes/jars
> with the new product?
>b. source compatibility: can I use my already written code, after
> recompiling it with the new product?

One of the very best things that I think we nailed in APR and
Subversion was having a clearly-documented API and compatibility
document.

http://apr.apache.org/versioning.html
http://subversion.apache.org/docs/community-guide/releasing.html#release-process

As Geode has some downstream legacy users (due to Gemfire), while it
could use this opportunity to change, it would be really good to be
transparent about it as soon as possible - perhaps before the first
incubation release is cut.

It could be fine if Gemfire decides to maintain compatibility for its
users in a specific set of libraries that aren't shipped with Geode
(or even ALv2).

Lots of different ways to go about it!  -- justin

Artifacts of jenkins build

[Dan Smith]

Would it be possible to archive the **/*-progress.txt files as part of the
jenkins build? I was recently trying to track down the why a test failed,
and it looked like it was due to a previous test. If we had those files I
could figure out what the previous tests were. Who has authority to
configure this?

https://builds.apache.org/job/Geode-nightly/

Re: [rtds-dev] Backward Compatibility and RollingUpgrade.

[William Markito]

+1

We should definitely produce a table similar to that with
version/compatibility information.

On Wed, Sep 2, 2015 at 5:34 PM, Justin Erenkrantz 
wrote:

> On Wed, Sep 2, 2015 at 6:12 PM, Darrel Schneider 
> wrote:
> > For backwards compatibility I see at least two levels of compatibility:
> > 1. client compatibility: can an old client work with a new server?
> > 2. code compatibility: can old code be used as is with the new product?
> >a. class compatibility: can I use my already compiled old classes/jars
> > with the new product?
> >b. source compatibility: can I use my already written code, after
> > recompiling it with the new product?
>
> One of the very best things that I think we nailed in APR and
> Subversion was having a clearly-documented API and compatibility
> document.
>
> http://apr.apache.org/versioning.html
>
> http://subversion.apache.org/docs/community-guide/releasing.html#release-process
>
> As Geode has some downstream legacy users (due to Gemfire), while it
> could use this opportunity to change, it would be really good to be
> transparent about it as soon as possible - perhaps before the first
> incubation release is cut.
>
> It could be fine if Gemfire decides to maintain compatibility for its
> users in a specific set of libraries that aren't shipped with Geode
> (or even ALv2).
>
> Lots of different ways to go about it!  -- justin
>



-- 

William Markito Oliveira
Enterprise Architect
-- For questions about Apache Geode, please write to
*dev@geode.incubator.apache.org
*

[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #54 was SUCCESSFUL (with 1140 tests)

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #54 was successful.
---
Scheduled
1144 tests in total.

https://build.spring.io/browse/SGF-NAG-54/





--
This message is automatically generated by Atlassian Bamboo

Re: Review Request 38060: GEODE-300 new gradle script for Pulse

[Mark Bretl]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/38060/#review97513
---



pulse/build.gradle (line 4)


Why add a custom pulseCompile configuration?



pulse/build.gradle (line 8)


Why add a custom testPulseCompile configuration?



pulse/build.gradle (line 81)


Add war file to archive list?



pulse/build.gradle (line 93)


This can be removed, only for commercial license


- Mark Bretl


On Sept. 2, 2015, 6:42 p.m., Nitin Lamba wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38060/
> ---
> 
> (Updated Sept. 2, 2015, 6:42 p.m.)
> 
> 
> Review request for geode, Jens Deppe, Mark Bretl, and Dan Smith.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Create new gradle script for PULSE to build archives (jar, war files) using 
> the dependencies from existing ant build.xml file.
> 
> These chances will be tracked on GEODE-12 branch until all subtasks are 
> completed.
> 
> 
> Diffs
> -
> 
>   build.gradle 3bad39c 
>   gemfire-assembly/build.gradle 0e51563 
>   gemfire-assembly/src/test/java/AgentUtilJUnitTest.java 0f7563b 
>   pulse/build.gradle PRE-CREATION 
>   settings.gradle 7f6ed61 
> 
> Diff: https://reviews.apache.org/r/38060/diff/
> 
> 
> Testing
> ---
> 
> - pulse.war file gets generated correctly and placed in tools/Pulse folder
> - Starting locator starts pulse within the embedded jetty instance
> - Unit and integration tests are blocked. GEODE-304 is tracking the issue 
> separately
> 
> 
> Thanks,
> 
> Nitin Lamba
> 
>

[GitHub] incubator-geode pull request: GEODE-222 Allow redis adapter to han...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/incubator-geode/pull/18


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Review Request 38060: GEODE-300 new gradle script for Pulse

[Anthony Baker]

Would it make sense to use a single version of Spring jars throughout the build?

> On Sep 2, 2015, at 1:10 PM, Nitin Lamba  wrote:
> 
> 
> 
>> On Sept. 2, 2015, 5:35 p.m., Dan Smith wrote:
>>> Hi Nitin,
>>> 
>>> Looks like good progress! I had a few comments/questions:
>>> 
>>> 1. Is there are reason why you added the pulseCompile, pulseTestCompile 
>>> configurations rather than just use the standard compile and testCompile 
>>> ones?
>>> 2. I think it would be better to just rename and categorize the the tests 
>>> to follow the conventions, rather than add different test and 
>>> integrationTest targets. Maybe we can add another JIRA for that?
> 
> Thanks Dan,
> 
> 1. compile and test targets inherit from parent gradle project and use newer 
> versions of Spring framework jars. I tried hard but couldn't override those 
> dependencies from within a sub-project. Besides creating new tasks, the other 
> option is to remove those from parent and move them downstream to different 
> sub-projects using it. Is there a different way?
> 
> 2. The new targets are required anyway to add a couple of new system 
> properties. Agree that the tests need to be cleaned-up to follow conventions 
> so I'll update GEODE-304 with those comments
> 
> 
>> On Sept. 2, 2015, 5:35 p.m., Dan Smith wrote:
>>> gemfire-assembly/build.gradle, line 188
>>> 
>>> 
>>>I don't think this is necessary to include the pulse jars in the lib 
>>> directory - at least when I tried dropping a just the pulse war into the 
>>> tools/Pulse directory with the old gemfire pulse it worked fine. I'm not 
>>> sure what the classpath implications of putting them one place vs. the 
>>> other are though.
> 
> Thanks. I've removed the lines from gemfire-assembly's build gradle file.
> 
> 
> - Nitin
> 
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38060/#review97495
> ---
> 
> 
> On Sept. 2, 2015, 6:42 p.m., Nitin Lamba wrote:
>> 
>> ---
>> This is an automatically generated e-mail. To reply, visit:
>> https://reviews.apache.org/r/38060/
>> ---
>> 
>> (Updated Sept. 2, 2015, 6:42 p.m.)
>> 
>> 
>> Review request for geode, Jens Deppe, Mark Bretl, and Dan Smith.
>> 
>> 
>> Repository: geode
>> 
>> 
>> Description
>> ---
>> 
>> Create new gradle script for PULSE to build archives (jar, war files) using 
>> the dependencies from existing ant build.xml file.
>> 
>> These chances will be tracked on GEODE-12 branch until all subtasks are 
>> completed.
>> 
>> 
>> Diffs
>> -
>> 
>>  build.gradle 3bad39c 
>>  gemfire-assembly/build.gradle 0e51563 
>>  gemfire-assembly/src/test/java/AgentUtilJUnitTest.java 0f7563b 
>>  pulse/build.gradle PRE-CREATION 
>>  settings.gradle 7f6ed61 
>> 
>> Diff: https://reviews.apache.org/r/38060/diff/
>> 
>> 
>> Testing
>> ---
>> 
>> - pulse.war file gets generated correctly and placed in tools/Pulse folder
>> - Starting locator starts pulse within the embedded jetty instance
>> - Unit and integration tests are blocked. GEODE-304 is tracking the issue 
>> separately
>> 
>> 
>> Thanks,
>> 
>> Nitin Lamba
>> 
>> 
> 

Re: Review Request 38060: GEODE-300 new gradle script for Pulse

[Nitin Lamba]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/38060/
---

(Updated Sept. 2, 2015, 6:42 p.m.)


Review request for geode, Jens Deppe, Mark Bretl, and Dan Smith.


Repository: geode


Description
---

Create new gradle script for PULSE to build archives (jar, war files) using the 
dependencies from existing ant build.xml file.

These chances will be tracked on GEODE-12 branch until all subtasks are 
completed.


Diffs (updated)
-

  build.gradle 3bad39c 
  gemfire-assembly/build.gradle 0e51563 
  gemfire-assembly/src/test/java/AgentUtilJUnitTest.java 0f7563b 
  pulse/build.gradle PRE-CREATION 
  settings.gradle 7f6ed61 

Diff: https://reviews.apache.org/r/38060/diff/


Testing
---

- pulse.war file gets generated correctly and placed in tools/Pulse folder
- Starting locator starts pulse within the embedded jetty instance
- Unit and integration tests are blocked. GEODE-304 is tracking the issue 
separately


Thanks,

Nitin Lamba

Re: Review Request 38060: GEODE-300 new gradle script for Pulse

[Mark Bretl]

> On Sept. 2, 2015, 6:59 p.m., Mark Bretl wrote:
> >

Echoing what Dan said, great job Nitin! Only a few minor points to follow up on.

Thanks for 'porting' the build script from Ant to Gradle!


- Mark


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/38060/#review97513
---


On Sept. 2, 2015, 6:42 p.m., Nitin Lamba wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38060/
> ---
> 
> (Updated Sept. 2, 2015, 6:42 p.m.)
> 
> 
> Review request for geode, Jens Deppe, Mark Bretl, and Dan Smith.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Create new gradle script for PULSE to build archives (jar, war files) using 
> the dependencies from existing ant build.xml file.
> 
> These chances will be tracked on GEODE-12 branch until all subtasks are 
> completed.
> 
> 
> Diffs
> -
> 
>   build.gradle 3bad39c 
>   gemfire-assembly/build.gradle 0e51563 
>   gemfire-assembly/src/test/java/AgentUtilJUnitTest.java 0f7563b 
>   pulse/build.gradle PRE-CREATION 
>   settings.gradle 7f6ed61 
> 
> Diff: https://reviews.apache.org/r/38060/diff/
> 
> 
> Testing
> ---
> 
> - pulse.war file gets generated correctly and placed in tools/Pulse folder
> - Starting locator starts pulse within the embedded jetty instance
> - Unit and integration tests are blocked. GEODE-304 is tracking the issue 
> separately
> 
> 
> Thanks,
> 
> Nitin Lamba
> 
>

Re: Review Request 38060: GEODE-300 new gradle script for Pulse

[Nitin Lamba]

> On Sept. 2, 2015, 5:35 p.m., Dan Smith wrote:
> > Hi Nitin,
> > 
> > Looks like good progress! I had a few comments/questions:
> > 
> > 1. Is there are reason why you added the pulseCompile, pulseTestCompile 
> > configurations rather than just use the standard compile and testCompile 
> > ones?
> > 2. I think it would be better to just rename and categorize the the tests 
> > to follow the conventions, rather than add different test and 
> > integrationTest targets. Maybe we can add another JIRA for that?

Thanks Dan,

1. compile and test targets inherit from parent gradle project and use newer 
versions of Spring framework jars. I tried hard but couldn't override those 
dependencies from within a sub-project. Besides creating new tasks, the other 
option is to remove those from parent and move them downstream to different 
sub-projects using it. Is there a different way?

2. The new targets are required anyway to add a couple of new system 
properties. Agree that the tests need to be cleaned-up to follow conventions so 
I'll update GEODE-304 with those comments


> On Sept. 2, 2015, 5:35 p.m., Dan Smith wrote:
> > gemfire-assembly/build.gradle, line 188
> > 
> >
> > I don't think this is necessary to include the pulse jars in the lib 
> > directory - at least when I tried dropping a just the pulse war into the 
> > tools/Pulse directory with the old gemfire pulse it worked fine. I'm not 
> > sure what the classpath implications of putting them one place vs. the 
> > other are though.

Thanks. I've removed the lines from gemfire-assembly's build gradle file.


- Nitin


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/38060/#review97495
---


On Sept. 2, 2015, 6:42 p.m., Nitin Lamba wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38060/
> ---
> 
> (Updated Sept. 2, 2015, 6:42 p.m.)
> 
> 
> Review request for geode, Jens Deppe, Mark Bretl, and Dan Smith.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Create new gradle script for PULSE to build archives (jar, war files) using 
> the dependencies from existing ant build.xml file.
> 
> These chances will be tracked on GEODE-12 branch until all subtasks are 
> completed.
> 
> 
> Diffs
> -
> 
>   build.gradle 3bad39c 
>   gemfire-assembly/build.gradle 0e51563 
>   gemfire-assembly/src/test/java/AgentUtilJUnitTest.java 0f7563b 
>   pulse/build.gradle PRE-CREATION 
>   settings.gradle 7f6ed61 
> 
> Diff: https://reviews.apache.org/r/38060/diff/
> 
> 
> Testing
> ---
> 
> - pulse.war file gets generated correctly and placed in tools/Pulse folder
> - Starting locator starts pulse within the embedded jetty instance
> - Unit and integration tests are blocked. GEODE-304 is tracking the issue 
> separately
> 
> 
> Thanks,
> 
> Nitin Lamba
> 
>

Re: Review Request 38060: GEODE-300 new gradle script for Pulse

[Nitin Lamba]

Great! Makes sense.


I did a quick check and seems that we can safely move Pulse dependencies to 
3.2.12, the current Spring release defined in root gradle script. Also, Spring 
Security modules can be bumped-up to 3.1.7 and Spring LDAP to 1.3.2.


Given how global dependencies are defined in the root project, I'm pulling an 
additional jar file into war's WEB-INF/lib folder: 
spring-context-support-3.2.12.RELEASE.jar. I could explicitly exclude it but a 
cleaner fix is to move that dependency down to sub-project(s) that use it. If 
we do nothing, the pulse war can carry the extra 0.1 Mb baggage for now :)


Let me know what is preferred - will make changes accordingly.


Thanks,

Nitin





From: Mark Bretl 
Sent: Wednesday, September 2, 2015 2:10 PM
To: Anthony Baker
Cc: dev@geode.incubator.apache.org; Nitin Lamba; Dan Smith; Jens Deppe
Subject: Re: Review Request 38060: GEODE-300 new gradle script for Pulse

Yes, it does make sense and should be a goal. I think they only got out of sync 
due to separate teams managing dependencies. Now would be a good time to 
re-sync them.

--Mark

On Wed, Sep 2, 2015 at 2:04 PM, Anthony Baker 
> wrote:
Would it make sense to use a single version of Spring jars throughout the build?

> On Sep 2, 2015, at 1:10 PM, Nitin Lamba 
> > wrote:
>
>
>
>> On Sept. 2, 2015, 5:35 p.m., Dan Smith wrote:
>>> Hi Nitin,
>>>
>>> Looks like good progress! I had a few comments/questions:
>>>
>>> 1. Is there are reason why you added the pulseCompile, pulseTestCompile 
>>> configurations rather than just use the standard compile and testCompile 
>>> ones?
>>> 2. I think it would be better to just rename and categorize the the tests 
>>> to follow the conventions, rather than add different test and 
>>> integrationTest targets. Maybe we can add another JIRA for that?
>
> Thanks Dan,
>
> 1. compile and test targets inherit from parent gradle project and use newer 
> versions of Spring framework jars. I tried hard but couldn't override those 
> dependencies from within a sub-project. Besides creating new tasks, the other 
> option is to remove those from parent and move them downstream to different 
> sub-projects using it. Is there a different way?
>
> 2. The new targets are required anyway to add a couple of new system 
> properties. Agree that the tests need to be cleaned-up to follow conventions 
> so I'll update GEODE-304 with those comments
>
>
>> On Sept. 2, 2015, 5:35 p.m., Dan Smith wrote:
>>> gemfire-assembly/build.gradle, line 188
>>> 
>>>
>>>I don't think this is necessary to include the pulse jars in the lib 
>>> directory - at least when I tried dropping a just the pulse war into the 
>>> tools/Pulse directory with the old gemfire pulse it worked fine. I'm not 
>>> sure what the classpath implications of putting them one place vs. the 
>>> other are though.
>
> Thanks. I've removed the lines from gemfire-assembly's build gradle file.
>
>
> - Nitin
>
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38060/#review97495
> ---
>
>
> On Sept. 2, 2015, 6:42 p.m., Nitin Lamba wrote:
>>
>> ---
>> This is an automatically generated e-mail. To reply, visit:
>> https://reviews.apache.org/r/38060/
>> ---
>>
>> (Updated Sept. 2, 2015, 6:42 p.m.)
>>
>>
>> Review request for geode, Jens Deppe, Mark Bretl, and Dan Smith.
>>
>>
>> Repository: geode
>>
>>
>> Description
>> ---
>>
>> Create new gradle script for PULSE to build archives (jar, war files) using 
>> the dependencies from existing ant build.xml file.
>>
>> These chances will be tracked on GEODE-12 branch until all subtasks are 
>> completed.
>>
>>
>> Diffs
>> -
>>
>>  build.gradle 3bad39c
>>  gemfire-assembly/build.gradle 0e51563
>>  gemfire-assembly/src/test/java/AgentUtilJUnitTest.java 0f7563b
>>  pulse/build.gradle PRE-CREATION
>>  settings.gradle 7f6ed61
>>
>> Diff: https://reviews.apache.org/r/38060/diff/
>>
>>
>> Testing
>> ---
>>
>> - pulse.war file gets generated correctly and placed in tools/Pulse folder
>> - Starting locator starts pulse within the embedded jetty instance
>> - Unit and integration tests are blocked. GEODE-304 is tracking the issue 
>> separately
>>
>>
>> Thanks,
>>
>> Nitin Lamba
>>
>>
>




--
Mark Bretl
Software Build Engineer
Pivotal
503-533-3869
www.pivotal.io

Re: Review Request 38060: GEODE-300 new gradle script for Pulse

[Mark Bretl]

Yes, it does make sense and should be a goal. I think they only got out of
sync due to separate teams managing dependencies. Now would be a good time
to re-sync them.

--Mark

On Wed, Sep 2, 2015 at 2:04 PM, Anthony Baker  wrote:

> Would it make sense to use a single version of Spring jars throughout the
> build?
>
> > On Sep 2, 2015, at 1:10 PM, Nitin Lamba  wrote:
> >
> >
> >
> >> On Sept. 2, 2015, 5:35 p.m., Dan Smith wrote:
> >>> Hi Nitin,
> >>>
> >>> Looks like good progress! I had a few comments/questions:
> >>>
> >>> 1. Is there are reason why you added the pulseCompile,
> pulseTestCompile configurations rather than just use the standard compile
> and testCompile ones?
> >>> 2. I think it would be better to just rename and categorize the the
> tests to follow the conventions, rather than add different test and
> integrationTest targets. Maybe we can add another JIRA for that?
> >
> > Thanks Dan,
> >
> > 1. compile and test targets inherit from parent gradle project and use
> newer versions of Spring framework jars. I tried hard but couldn't override
> those dependencies from within a sub-project. Besides creating new tasks,
> the other option is to remove those from parent and move them downstream to
> different sub-projects using it. Is there a different way?
> >
> > 2. The new targets are required anyway to add a couple of new system
> properties. Agree that the tests need to be cleaned-up to follow
> conventions so I'll update GEODE-304 with those comments
> >
> >
> >> On Sept. 2, 2015, 5:35 p.m., Dan Smith wrote:
> >>> gemfire-assembly/build.gradle, line 188
> >>> <
> https://reviews.apache.org/r/38060/diff/1/?file=1062329#file1062329line188
> >
> >>>
> >>>I don't think this is necessary to include the pulse jars in the
> lib directory - at least when I tried dropping a just the pulse war into
> the tools/Pulse directory with the old gemfire pulse it worked fine. I'm
> not sure what the classpath implications of putting them one place vs. the
> other are though.
> >
> > Thanks. I've removed the lines from gemfire-assembly's build gradle file.
> >
> >
> > - Nitin
> >
> >
> > ---
> > This is an automatically generated e-mail. To reply, visit:
> > https://reviews.apache.org/r/38060/#review97495
> > ---
> >
> >
> > On Sept. 2, 2015, 6:42 p.m., Nitin Lamba wrote:
> >>
> >> ---
> >> This is an automatically generated e-mail. To reply, visit:
> >> https://reviews.apache.org/r/38060/
> >> ---
> >>
> >> (Updated Sept. 2, 2015, 6:42 p.m.)
> >>
> >>
> >> Review request for geode, Jens Deppe, Mark Bretl, and Dan Smith.
> >>
> >>
> >> Repository: geode
> >>
> >>
> >> Description
> >> ---
> >>
> >> Create new gradle script for PULSE to build archives (jar, war files)
> using the dependencies from existing ant build.xml file.
> >>
> >> These chances will be tracked on GEODE-12 branch until all subtasks are
> completed.
> >>
> >>
> >> Diffs
> >> -
> >>
> >>  build.gradle 3bad39c
> >>  gemfire-assembly/build.gradle 0e51563
> >>  gemfire-assembly/src/test/java/AgentUtilJUnitTest.java 0f7563b
> >>  pulse/build.gradle PRE-CREATION
> >>  settings.gradle 7f6ed61
> >>
> >> Diff: https://reviews.apache.org/r/38060/diff/
> >>
> >>
> >> Testing
> >> ---
> >>
> >> - pulse.war file gets generated correctly and placed in tools/Pulse
> folder
> >> - Starting locator starts pulse within the embedded jetty instance
> >> - Unit and integration tests are blocked. GEODE-304 is tracking the
> issue separately
> >>
> >>
> >> Thanks,
> >>
> >> Nitin Lamba
> >>
> >>
> >
>
>


-- 
Mark Bretl
Software Build Engineer
Pivotal
503-533-3869
www.pivotal.io

Re: [rtds-dev] Backward Compatibility and RollingUpgrade.

[Darrel Schneider]

For backwards compatibility I see at least two levels of compatibility:
1. client compatibility: can an old client work with a new server?
2. code compatibility: can old code be used as is with the new product?
   a. class compatibility: can I use my already compiled old classes/jars
with the new product?
   b. source compatibility: can I use my already written code, after
recompiling it with the new product?


On Wed, Sep 2, 2015 at 2:38 PM, Anilkumar Gingade 
wrote:

> Hi Team,
>
> Wanted to get a closure on these topic.
>
> This may not impact Geode as its not yet released. But will impact the
> existing GemFire installation (where next GemFire release is based on
> Geode).
>
> *Rolling Upgrade *- Server upgrades without bringing down the cluster.
>
> Since we are changing the our membership layer (GEODE-77), the
> RollingUpgrade from older GemFire versions will not be supported. We had
> multiple conservation on this with GemFire PMs, Engineering team and agreed
> on this.
>
> *Backward Compatibility* - Support for older versions of client to work
> with newer versions of server cluster.
>
> We can still work towards to have backward compatibility supported with
> membership changes (adds extra effort to do so); but with package name
> changes we may not be able to support this. There was a discussion thread
> started on this (below email); where possibility of keeping old package
> names was discussed; but there was no final decision made on that thread.
>
> Do we need to support backward compatibility?
>
> Thanks,
> -Anil.
>
>
> Original Subject: Re: Repackaging src code to org.apache.geode
>
> On Thu, Jul 2, 2015 at 2:06 PM, Kirk Lund  wrote:
>
>> Yep, having 99% of the code in org.apache.geode pkgs with 1% in
>> com.gemstone.gemfire pkgs just to facilitate rolling upgrades seems like
>> something that would be reasonable to discuss on general@incubator.
>>
>>
>> On Thu, Jul 2, 2015 at 12:35 PM, Bruce Schuchardt > >
>> wrote:
>>
>> > Hey, if we can do this then we should leave versions of exception
>> classes
>> > in com.gemstone.gemfire so we can send them to old GemFire clients!  If
>> we
>> > do that and swizzle package names in DataSerializer maybe we'll be able
>> to
>> > support migration of GemFire clients to Geode.  That would facilitate
>> > faster adoption of Geode by users of the commercial product.
>> >
>> >
>> >
>> >
>> > Le 7/2/2015 12:28 PM, Sean Busbey a écrit :
>> >
>> >> On Thu, Jul 2, 2015 at 1:25 PM, William Markito 
>> >> wrote:
>> >>
>> >>  My reading of that is it's specifically for incubation, which indeed
>> is
>> >>> not
>> >>> required based on this thread
>> >>> <
>> >>>
>> >>>
>> https://www.mail-archive.com/search?l=dev@geode.incubator.apache.org=subject:%22Package+renaming%5C%3F%22=newest=1
>> >>> .
>> >>>
>> >>> But for leaving incubation and becoming a TLP my understanding was
>> that
>> >>> it
>> >>> is required.
>> >>>
>> >>>
>> >>>  Many projects leave code in packages that are not org.apache for
>> >> backwards
>> >> compatibility.
>> >>
>> >> Roman is correct, if you want to have things outside of org.apache you
>> >> should bring up the matter on general@incubator. Including the
>> reasoning
>> >> for having things outside of org.apache and the long term plan (if any)
>> >> for
>> >> moving things will help avoid a longer set of questions.
>> >>
>> >>
>> >>
>> >
>>
>
>

Re: DRAFT of August report

[Swapnil Bawaskar]

Thanks for the review!

I updated the wiki and also posted the content on Geode wiki:
https://cwiki.apache.org/confluence/display/GEODE/Community+development

On Wed, Sep 2, 2015 at 3:21 AM, Justin Erenkrantz 
wrote:

> +1.  Thanks!  -- justin
>
> On Tue, Sep 1, 2015 at 2:48 AM, Swapnil Bawaskar 
> wrote:
> > Hi All,
> > The following is a draft of the August report. Please provide any
> feedback
> > you may have.
> >
> > Geode:
> > Geode is a data management platform that provides real-time, consistent
> > access to data-intensive applications throughout widely distributed cloud
> > architectures.
> >
> > Geode has been incubating since 2015-04-27.
> >
> > ** Three most important issues to address in the move towards
> graduation:*
> > 1. Have our first Apache (incubating) release (currently blocked on us
> solving
> > JGroups licensing issues) GEODE-77.
> > 2. Expanding the community to include contributors and committers outside
> > of Pivotal.
> > 3. Execute and manage the project according to governance model required
> by the
> > "Apache Way"
> >
> > ** Any issues that the Incubator PMC or ASF Board might wish/need to
> > be aware of*
> >
> >  None
> >
> > ** How has the community developed since the last report?*
> >
> > Geode now has a Zeppelin interpreter.
> > In August 120 issues were created and 59 resolved, bringing the total to
> > 304 created and 136 resolved.
> > There were 6 pull requests to github in the last 30 days, for a total of
> 18
> > pull requests.
> > There were 322 messages on the dev list and 63 messages on the user list.
> > There are now 117 subscribers on the user and 127 on the dev list.
> >
> > Events and Conferences in August:
> > QCon Rio: (30 attended)
> > In-Memory Analytics and Machine Learning in practice with Spark, Geode,
> > Spring XD and Docker
> > <
> http://qconrio.com/workshop/memory-analytics-e-machine-learning-na-pr%C3%A1tica-com-spark-geode-spring-xd-e-docker
> >
> >
> > Geode Clubhouse: Roundtable where 10 issues were discussed in the
> > community. https://www.youtube.com/watch?v=qaOB3d-pvTI (about 20
> > participated)
> >
> > September:
> > Geode clubhouse: Building Effective *Apache Geode* Applications with
> *Spring
> > Data GemFire (Sept 8th)*
> >
> > Three talks at "Apache: Big Data Europe"
> > - An introduction to Apache Geode (incubating)
> > - Building a highly scalable open-source Real-time Streaming Analytics
> > system using Spark SQL, Apache Geode (incubating), SpringXD and Apache
> > Zeppelin (incubating)
> > - Implementing a Highly Scalable In-Memory Stock Prediction System with
> > Apache Geode (incubating), R and Spring XD
> >
> >
> > **   How has the project developed since the last report.*
> >
> > Great progress has been made on JGroups issue, where many unit and
> > integration tests now pass on the feature/GEODE-77 branch.
> > Good progress has also been made on stabilizing CI, by fixing various
> > intermittent failures in integration tests.
> >
> > ** Date of last release:*
> >
> >N/A - Just nightly builds.
> >
> > *Signed-off-by:*
> > [ ](geode) Konstantin Boudnik
> > [ ](geode) Chip Childers
> > [ ](geode) Justin Erenkrantz
> > [ ](geode) Jan Iversen
> > [ ](geode) Chris Mattmann
> > [ ](geode) William A. Rowe Jr.
> > [ ](geode) Henry Saputra
> > [ ](geode) Roman Shaposhnik
>

Re: DRAFT of August report

[Justin Erenkrantz]

+1.  Thanks!  -- justin

On Tue, Sep 1, 2015 at 2:48 AM, Swapnil Bawaskar  wrote:
> Hi All,
> The following is a draft of the August report. Please provide any feedback
> you may have.
>
> Geode:
> Geode is a data management platform that provides real-time, consistent
> access to data-intensive applications throughout widely distributed cloud
> architectures.
>
> Geode has been incubating since 2015-04-27.
>
> ** Three most important issues to address in the move towards graduation:*
> 1. Have our first Apache (incubating) release (currently blocked on us solving
> JGroups licensing issues) GEODE-77.
> 2. Expanding the community to include contributors and committers outside
> of Pivotal.
> 3. Execute and manage the project according to governance model required by 
> the
> "Apache Way"
>
> ** Any issues that the Incubator PMC or ASF Board might wish/need to
> be aware of*
>
>  None
>
> ** How has the community developed since the last report?*
>
> Geode now has a Zeppelin interpreter.
> In August 120 issues were created and 59 resolved, bringing the total to
> 304 created and 136 resolved.
> There were 6 pull requests to github in the last 30 days, for a total of 18
> pull requests.
> There were 322 messages on the dev list and 63 messages on the user list.
> There are now 117 subscribers on the user and 127 on the dev list.
>
> Events and Conferences in August:
> QCon Rio: (30 attended)
> In-Memory Analytics and Machine Learning in practice with Spark, Geode,
> Spring XD and Docker
> 
>
> Geode Clubhouse: Roundtable where 10 issues were discussed in the
> community. https://www.youtube.com/watch?v=qaOB3d-pvTI (about 20
> participated)
>
> September:
> Geode clubhouse: Building Effective *Apache Geode* Applications with *Spring
> Data GemFire (Sept 8th)*
>
> Three talks at "Apache: Big Data Europe"
> - An introduction to Apache Geode (incubating)
> - Building a highly scalable open-source Real-time Streaming Analytics
> system using Spark SQL, Apache Geode (incubating), SpringXD and Apache
> Zeppelin (incubating)
> - Implementing a Highly Scalable In-Memory Stock Prediction System with
> Apache Geode (incubating), R and Spring XD
>
>
> **   How has the project developed since the last report.*
>
> Great progress has been made on JGroups issue, where many unit and
> integration tests now pass on the feature/GEODE-77 branch.
> Good progress has also been made on stabilizing CI, by fixing various
> intermittent failures in integration tests.
>
> ** Date of last release:*
>
>N/A - Just nightly builds.
>
> *Signed-off-by:*
> [ ](geode) Konstantin Boudnik
> [ ](geode) Chip Childers
> [ ](geode) Justin Erenkrantz
> [ ](geode) Jan Iversen
> [ ](geode) Chris Mattmann
> [ ](geode) William A. Rowe Jr.
> [ ](geode) Henry Saputra
> [ ](geode) Roman Shaposhnik