Hosted API docs update?

Any pointers on how to update hosted API documentation? http://geode.apache.org/releases/latest/javadoc/index.html Sai

Re: Hosted API docs update?

upto data already. Are we missing > anything? > > On Fri, Jan 13, 2017 at 10:05 AM, Sai Boorlagadda < > sai.boorlaga...@gmail.com > > wrote: > > > Any pointers on how to update hosted API documentation? > > http://geode.apache.org/releases/latest/javadoc/index.html > > > > Sai > > >

Re: Hosted API docs update?

+1 to link API docs to release page. On Fri, Jan 13, 2017 at 10:42 AM, Anthony Baker wrote: > +1 > > I’d would like to link the docs + javadocs from the release page, similar > to what we do for the release archives. > > Anthony > > > > On Jan 13, 2017, at 10:39 AM, Joey

Re: Hosted API docs update?

nt to the Geode website Releases page to download the binary > > > distribution (http://geode.apache.org/releases/). It offers v > > > 1.0.0-incubating. > > > > > > > > > > > > On Fri, Jan 13, 2017 at 11:01 AM, Sai Boorlagadda < > &g

Re: Permission to assign issue to myself

Hello, This is Geode mailing list. You are asking in a wrong group. There are no JIRA tickets in Geode JIRA reported by your username. Sai On Fri, Sep 29, 2017 at 12:59 PM, Yuqi Li wrote: > Hi there, > > I reported an issue related to Kafka Connect and I have a

Re: Wiki permissions

Is this an active username or does > it need to be removed? > > --Mark > > On Wed, May 16, 2018 at 12:34 PM, Sai Boorlagadda < > sai_boorlaga...@apache.org> wrote: > > > Hello Devs, > > > > Could someone grant me permissions to edit Apache Wiki? > > > > My Id: sai_boorlagadda > > > > Sai > > >

Wiki permissions

Hello Devs, Could someone grant me permissions to edit Apache Wiki? My Id: sai_boorlagadda Sai

Re: [Proposal] CMS - cluster management service

rder to connect. >>> >>> On Thu, May 24, 2018 at 1:15 PM, Dan Smith wrote: >>> >>>> Hi Sai, >>>> >>>> +1 for making the cluster configuration API public. This looks great! >>>> >>>> One question I have is abo

Re: [VOTE] Apache Geode release - 1.4.0 RC2

+1 * verified commit ids * checked concourse pipeline is green * ran examples with RC2 * built from source On Tue, Jan 30, 2018 at 1:27 PM, Anthony Baker wrote: > +1 > > - tested binary distribution > - built from source > - ran examples > - release pipeline is green > -

Re: Geode Website Docs page: Proposal to limit the number of versions listed.

Adding u...@geode.apache.org to the email thread to see if any users has inputs. I'm fine showing only one version of Java docs, as a developer I access the Java docs in my IDE based on which ever version I am using to build geode application. Sai On Wed, Jan 31, 2018 at 10:23 AM, Dave Barnes

Proposal to support custom java.security.Provider

All, GEODE-5338[1], is a feature request to support CA & KEY rotation on the client application. I am proposing a solution[2] to add a new SSL property ( *ssl-use-default-provider*) to let Geode use default security provider[3] (either JDK provided provider or a custom provider) to load and

Re: Proposal to support custom java.security.Provider

use default SSL context instead of introducing a new parameter 'ssl-use-default-sslcontext'. If user's have specified any existing ssl-* props then the current implementation is exercised (ie to configure the context as per provided properties). Sai On Wed, Aug 1, 2018 at 3:02 PM Sai Boorlagadda

Re: Proposal to support custom java.security.Provider

ust/KeyStoreManager from > the default security provider but still override other SSL properties such > as ciphers or protocols? > > --Jens > > On Mon, Aug 13, 2018 at 8:32 AM Sai Boorlagadda > > wrote: > > > To make it clear about the different options: > > > &g

Re: Proposal to support custom java.security.Provider

user.home if not specified in 2.0 Sai On Mon, Aug 13, 2018 at 8:48 AM Jinmei Liao wrote: > Doing #2 an #3 alone would fix GEODE-5338, right? We don't really need this > new option. > > On Mon, Aug 13, 2018 at 8:32 AM Sai Boorlagadda > > wrote: > > > To make it clear a

Re: [Proposal] SSL - hostname verification

I agree that hostname verification is independent of supporting default context and I like Dan's suggestion of making hostname validation is enabled by default if the user wants to use default SSL context otherwise can be enabled using 'ssl-enable-endpoint-identification'. Here is what the

Re: [Proposal] SSL - hostname verification

b Barrett wrote: > On Tue, Aug 14, 2018 at 7:47 AM Sai Boorlagadda < > sai_boorlaga...@apache.org> > wrote: > > > Geode currently does not implement hostname verification and is probably > > not required per TLS spec. But it can be supported on TLS as an >

Re: [Proposal] SSL - hostname verification

ote: > > > > On Tue, Aug 14, 2018 at 7:47 AM Sai Boorlagadda < > sai_boorlaga...@apache.org> > > wrote: > > > >> Geode currently does not implement hostname verification and is probably > >> not required per TLS spec. But it can be supported on TLS

Re: [Proposal] SSL - hostname verification

connections would this apply? All of them? > > > On 8/14/18 7:46 AM, Sai Boorlagadda wrote: > > Geode currently does not implement hostname verification and is probably > > not required per TLS spec. But it can be supported on TLS as an > additional > > check. The new pro

Re: Proposal to support custom java.security.Provider

I missed follow up emails on this thread, for some reason my email client didn't show there were new messages on this thread. Like Jinmei said, a user has to first enable SSL by configuring ssl-enable-component and then chose between using default context or using specific keystore/trustsore

Re: Proposal to support custom java.security.Provider

ser home directory. 3) if ssl-enabled-component & ssl-* properties are configured then configure SSL context as configured by user. While #2 and #3 are existing behavior, #1 is implemented as part of current proposal for GEODE-5338. On Mon, Aug 13, 2018 at 8:25 AM Sai Boorlagadda wrote: > I m

Re: [Proposal] Windows CI integration to 'develop' pipeline.

Windows jobs are live and run in parallel to existing jobs. On Wed, Aug 8, 2018 at 11:49 AM Dan Smith wrote: > +1 for in parallel. > > -Dan > > On Wed, Aug 8, 2018 at 11:37 AM, Jacob Barrett > wrote: > > > Parallel > > > > > On Aug 8, 2018, at

[Proposal] SSL - hostname verification

Geode currently does not implement hostname verification and is probably not required per TLS spec. But it can be supported on TLS as an additional check. The new proposed[1] implementation to use the default SSL context could cause certain man-in-the-middle attacks possible if there is no

[Proposal] Windows CI integration to 'develop' pipeline.

All, We would like to add windows jobs (UnitTests, Integration, Acceptance, and GfshDistributedTests) to the 'develop' pipeline. Looking for feedback on what the community wants to see: 1) Add windows jobs parallel to existing test jobs 2) Add windows jobs serial to the corresponding non-windows

Re: [Proposal] SSL - hostname verification

nt > between the two algorithms by scanning the RFCs. The HTTPS algorithm is a > bit more defined and covers IP addresses. The LDAPS has language explicitly > denying DNS resolution in the process. I can’t imagine why we would use the > LDAPS algorithm. > > > > On Aug 17, 2018,

Re: [Proposal] SSL - hostname verification

ge might require users to > regenerate certificates when upgrading. Perhaps we start by logging a > warning for N releases, then make HN verification a hard requirement. > > > > Anthony > > > > > >> On Aug 14, 2018, at 8:59 AM, Jacob Barrett wrote: > >

no test category, rename tests?

Many tests file names are *JUnitTest.java[1] even though it is an integration test or distributed test. After we segregated into respective folders and removed the test category it is not visible which test it is unless we look back into the path of the source directory (integrationTest or

Re: [DISCUSS] Apache Geode 1.7.0 release branch created

If not late, I would also like to include GEODE-5594 (enabling hostname verification) and GEODE-5338 (using the default SSL context) into 1.7.0. PRs for both are open and currently up for review. On Tue, Aug 21, 2018 at 2:26 PM Dan Smith wrote: > I think we do want to wait for GEODE-5615

Re: PutCommandWithJsonTest and DeployWithLargeJarTest

gging the problem. > > > > > > > Actually I thought we were using Docker to run each AcceptanceTest in > > > isolation. Then when the test finishes the Docker instances goes away. > > Did > > > we stop using Docker for these? > > > > > >

Re: no test category, rename tests?

the pages on the Wiki to match > our > > recent changes involving JUnit categories. > > > > [1] https://cwiki.apache.org/confluence/display/GEODE/Writing+tests > > > > On Tue, Aug 21, 2018 at 9:52 AM, Sai Boorlagadda < > sai_boorlaga...@apache.org > >> wro

Re: [DISCUSS] Apache Geode 1.7.0 release branch created

Regarding GEODE-5594, though the current implementation is good and needed more coverage. While adding tests to cover negative cases, I found something about JDK's default implementation of hostname validation which I am not happy about and so it needs a rethought. It could result in implementing

Looking for examples to assert expected exceptions in distributed tests

Are there any tests that I can refer to catch expected exceptions in distributed tests? I have a scenario where GW sender tries to send an event to other site and the connection fails with an expected exception. Currently, the event is retired a few times an exception is logged every time but does

Re: [Proposal] SSL - hostname verification

there is a need for implementing a custom validation algorithm but after re-reading the RFC I started to believe that JDK's implementation is okay. [1] https://tersesystems.com/blog/2014/03/23/fixing-hostname-verification/ [2] https://tools.ietf.org/search/rfc6125#section-6.4.4 On Mon, Aug

Re: [DISCUSS] Remove CatchException testing dependency

Kirk, Yes I have seen this thread. But in my case, In my case, the exception is in a background thread. SerialGatewaySenderEventProcessor uses ConnectionPool to initiate and send events in the background when the test code does a put. So the test code is in not control to handle or even catch

Re: [DISCUSS] Apache Geode 1.7.0 release branch created

gt; > >> in-progress, > > > > > >>> and a release branch was already created. But we stopped that > > > process > > > > > mid > > > > > >>> way. This happened in May 2018. > > > > > >>&g

Re: [DISCUSS] Apache Geode 1.7.0 release branch created

I waiting for a green precheckin for GEODE-5594. Sai On Tue, Aug 28, 2018 at 10:43 AM Alexander Murmann wrote: > Thanks for chiming in, Sai! Are you at this point waiting for more reviews? > > On Tue, Aug 28, 2018 at 10:30 AM, Sai Boorlagadda < > sai.boorlaga...@gmail.com > &g

Re: [DISCUSS] Apache Geode 1.7.0 release branch created

. > > Once we have reliable test results we can take additional time to improve > the build/test process for future releases. > > > On Aug 28, 2018, at 10:48 AM, Sai Boorlagadda > wrote: > > > > I waiting for a green precheckin for GEODE-5594. > > >

derived property + default value

is there a recommended way in GEODE to implement a derived property's default behavior? I have a boolean property 'ssl-endpoint-identification-enabled' which has to have a default value (if unspecified) but the default value is derived from other property 'ssl-use-default-context'. I see two

Re: PutCommandWithJsonTest and DeployWithLargeJarTest

Metrics show these started failing recently. https://concourse.apachegeode-ci.info/teams/main/pipelines/metrics/jobs/GeodeAcceptanceTestMetrics/builds/20 On Tue, Aug 21, 2018 at 10:07 AM Kirk Lund wrote: > Are PutCommandWithJsonTest and DeployWithLargeJarTest known to be flaky? > > My latest

Re: PutCommandWithJsonTest and DeployWithLargeJarTest

21, 2018 at 10:15 AM Kirk Lund wrote: > Those metrics show AcceptanceTests consistently GREEN. Do these metrics > include test failures from pull request precheckin runs like mine? Or does > it just cover CI test runs? > > On Tue, Aug 21, 2018 at 10:09 AM, Sai Boorlagadda &

Re: PutCommandWithJsonTest and DeployWithLargeJarTest

jobs/AcceptanceTest/builds/334 On Tue, Aug 21, 2018 at 10:18 AM Sai Boorlagadda wrote: > The metrics job themselves will be green (as they complete to success) but > you can expand the get_metrics task output and see that build#20 started > reporting these failures, so probably these are

Re: [DISCUSS] Apache Geode 1.7.0 release branch created

/906540e18fa6f85fc77c88c28fc74a61402471d2eed4ee9dab4813c9@%3Cdev.geode.apache.org%3E On Fri, Aug 24, 2018 at 5:07 PM Sai Boorlagadda wrote: > Regarding GEODE-5594, though the current implementation is good and needed > more coverage. > > While adding tests to cover negative cases, I found som

testCategory property for gradle test tasks

All, I merged a commit to 'develop' to remove all sub-category testing tasks like dlockTest,clientSubscriptionTest etc. After we moved integration & distributed tests to respective folders these tasks are running against only unit test source. Added a new property 'testCategory' to run specific

Re: [Proposal] SSL - hostname verification

okay! If users choose to disable hostname validation, then the warning in the log says in future releases the ability to disable will be removed. On Thu, Aug 30, 2018 at 2:59 PM Anthony Baker wrote: > > > > Also added a log to warn users if they disable hostname validation that > it > > will >

Re: [Proposal] SSL - hostname verification

rtificates > 3) Do a rolling restart > 4) Do a rolling upgrade to geode 1.7 > > *I think* that w/o steps 1-3 my application would break. What if we > deferred enabling hostname verification by default until the next major > version? > > Anthony > > > > On Aug 30, 20

New "Windows" group on develop pipeline.

I have moved windows jobs into a new group named "windows". Once the windows builds are stable then I will be merging them back to main. Sai

Re: [DISCUSS] Apache Geode 1.7.0 release branch created

I haven't yet merged GEODE-5338. The PR changes the existing behavior and is not acceptable. Working on changing the implementation to have a default value derived based on how user wants to configure SSL. Sai On Wed, Aug 29, 2018 at 11:45 AM Sai Boorlagadda wrote: > I have merged GEODE-5

Re: [DISCUSS] Apache Geode 1.7.0 release branch created

ersion for the following tickets to 1.7.0 from > >> 1.8.0 > >> >> as these fixes will be included in the 1.7.0 release > >> >> > >> >> GEODE-5671 > >> >> GEODE-5662 > >> >> GEODE-5660 > >> >> GEODE-5652 >

Re: 2 minute gateway startup time due to GEODE-5591

> >>>>> really doesn't want to have two minutes of retries for each port. It > >>>>> seems > >>>>> like we need to rework the fix for GEODE-5591. > >>>>> > >>>>> Does it make sense to hold up the release to rew

Re: [DISCUSS] Apache Geode 1.7.0 release branch created

I have merged GEODE-5594 to develop. GEODE-5338 is now waiting for PR review and precheckin. Sai On Tue, Aug 28, 2018 at 10:30 AM Sai Boorlagadda wrote: > GEODE-5338 is downvoted for the security concerns related to trusting > the default trust store and thus resulted in an improvement

Re: [PROPOSAL] Public API for Cluster Configuration

I have few comments: 1, What is ClusterElement/RegionElement interfaces used for? 2. I see that using unary mutator one can mutate both cache and region configurations, so the methods in ClusterConfigurationService can be getClusterConfig and updateClusterConfig? The naming is debatable as

[Proposal] geode-dunit sub module.

All, Geode's dunit framework can provide an easier way to write integration tests for any server-side extensions or server-side application code. Currently the dunit framework is not a published artifact, so developers cannot write distributed tests. So the proposal is to move all dunit framework

[PROPOSAL]: deprecating gfsh command option --load-cluster-config-from-dir for 'start locator'

All, Currently this option takes (true/false, defaults to false) to let locator load cluster configuration from a specified directory provided with other option '--cluster-config-dir'. Also `--cluster-config-dir` is used to create the persistent disk store to store configuration region entries.

Re: [Proposal] geode-dunit sub module.

ions since geode-core > source and tests are in the same module. Especially for people running > eclipse, since it combines src and test into the same source set (at least > last I checked). I'm sure there is some way to make it work though. > > -Dan > > On Thu, Apr 5, 201

Re: [VOTE] Apache Geode 1.5.0.RC2

+1 - Verified GEODE-4913 - Verified basic gfsh functionality - Ran examples - Builds from source On Fri, Mar 30, 2018 at 12:15 PM, Swapnil Bawaskar wrote: > Both issues mentioned in the RC1 vote thread >

Re: [Discussion] Improving Spotless to be Even More Beautiful

+1 On Mon, Mar 19, 2018 at 4:03 PM, Kirk Lund wrote: > +1 > > On Mon, Mar 19, 2018 at 2:51 PM, Patrick Rhomberg > wrote: > > > Hello all! > > > > I'm making another pass at patching up some of our smellier broken > > windows, to mix metaphors. To that

Re: Release process for Apache Geode wiki

Thanks Naba! it looks comprehensive. I have not done a release myself so cannot ask more. If it's possible would you be able to capture software dependencies that a release manager have to install on his workstation. Following the steps I see docker & svn is needed. On Wed, Oct 10, 2018, 7:01 PM

Re: [DISCUSS] permit-reflect vs --add-opens for Java 11 support

>Do we know what third party libraries are using java internals that >we might have problems with? #2 isn't going to work for those >libraries, unless they also add a module-info.class. So maybe we >will need to do #3 for third-party libraries? Adding these third-party libs on module path[1]

[Discuss] showcasing community work

I would like to discuss what's best to capture all the community work in one place. There are some good plugins/extensions that are built by the community which does not necessarily be merged into the mainstream but would be a great value for others in the community. Capturing all these at one

Re: [Discuss] showcasing community work

; Perhaps a page with a table containing... > > * Project Name > * Project Description (Summary) > * Project License > * Project URL (to GitHub page, Website, etc, where users can find out more > information) > > Food for thought. > > > On Thu, Oct 11, 2018 at

Re: [Discuss] showcasing community work

That a great suggestion. I will see if I can add a new page. On Thu, Oct 18, 2018 at 11:21 AM Swapnil Bawaskar wrote: > Would it make sense to put these under an "extensions" page, rather than a > "community" page? > > On Tue, Oct 16, 2018 at 5:05 PM Sai Boor

Re: [DISCUSS] Cutting 1.8 release branch

; On Thu, Nov 1, 2018 at 12:45 PM Sai Boorlagadda > > wrote: > > > I would like to resolve GEODE-5338 as it is currently waiting for > > doc update. > > > > Sai > > > > On Thu, Nov 1, 2018 at 10:00 AM Alexander Murmann > > wrote: > > > >

Re: [DISCUSS] Cutting 1.8 release branch

I would like to resolve GEODE-5338 as it is currently waiting for doc update. Sai On Thu, Nov 1, 2018 at 10:00 AM Alexander Murmann wrote: > Hi everyone, > > It's time to cut the release branch, since we are moving to time based > releases. Are there any reasons why a release branch should not

Re: [VOTE] Apache Geode 1.7.0 RC2

One correction but this does not change the voting result. PMC members : - Anthony Baker - Dan Smith - Dave Barnes - Sai Boorlagadda Committers: - Ryan McMahon - Alexander Murmann As per voting requirements, we have 4 PMC members with +1 votes and a majority of +1 votes. On Tue, Oct 2

Re: [DISCUSS] Predictable minor release cadence

I agree with Robert that we should release based on features that go in. I am not sure if Apache Kafka & Spark are a good reference for GEODE. These tools were evolving rapidly in the last couple of years and frequent releases would be good for a growing community. Should we do a patch release

Re: [VOTE] Time-based release schedule for minor releases

+0 My preference would be for - time-based patches and - scope based minors & majors On Mon, Oct 8, 2018 at 2:24 PM Alexander Murmann wrote: > Hi everyone, > > As discussed in "Predictable minor release cadence", I'd like us to find > agreement on releasing a new minor version every three

Re: [VOTE] Time-based release schedule for minor releases

+1 for time-based minors (if patches are reserved for security fixes) On Mon, Oct 8, 2018 at 2:55 PM Anthony Baker wrote: > We reserve the patch version number for when we want to issue a fix for a > security vulnerability or address a critical bug. We did that with 1.1.1 > and 1.2.1. > > I

Re: Rat is failing due to generated files under bin directories

Kirk, We can exclude bin directory in `gradle/rat.gradle`. Sai On Thu, Sep 27, 2018 at 7:02 PM Sai Boorlagadda wrote: > Intellij .uses 'bin' as output folder. > > On Thu, Sep 27, 2018 at 6:56 PM Anthony Baker wrote: > >> That’s weird—I would expect any generated file

Re: Rat is failing due to generated files under bin directories

Intellij .uses 'bin' as output folder. On Thu, Sep 27, 2018 at 6:56 PM Anthony Baker wrote: > That’s weird—I would expect any generated files to go into build/. Anyone > know why stuff is landing in bin? > > Anthony > > > > On Sep 27, 2018, at 7:25 PM, Kirk Lund wrote: > > > > Command-line

Re: Rat is failing due to generated files under bin directories

o try that out. Thanks! > > On Thu, Sep 27, 2018 at 8:34 PM, Sai Boorlagadda < > sai.boorlaga...@gmail.com> > wrote: > > > Kirk, > > > > We can exclude bin directory in `gradle/rat.gradle`. > > > > Sai > > > > On Thu, Sep 27, 2018 a

Re: [VOTE] Time-based release schedule for minor releases

After looking at these definitions are we not talking about time-based patch releases? It is again subjective how much functionality makes a MINOR release. Though this thread is seeking consensus on time-based scheduled it is specifically for minors. it appears to me like we need to update our

Re: [VOTE] Time-based release schedule for minor releases

Looking at the current definition it sounds like we can only decide if its a Minor at the time of release and cannot be scheduled. Thoughts? *> MINOR*: Minor releases can contain minor new features and must definitely include significant improvements > to current API or components that justify

Re: [VOTE] Time-based release schedule for minor releases

erge features, etc. > > On Wed, Oct 10, 2018 at 10:17 AM Sai Boorlagadda < > sai.boorlaga...@gmail.com> > wrote: > > > Looking at the current definition it sounds like we can only decide if > its > > a Minor at the time of release and cannot be scheduled. Thoughts

Re: [DISCUSS] permit-reflect vs --add-opens for Java 11 support

+1 to Dan's idea if its possible. There is a maven plugin to invoke javac twice with respective java targets. https://maven.apache.org/plugins/maven-compiler-plugin/examples/module-info.html On Wed, Oct 10, 2018 at 1:52 PM Galen O'Sullivan wrote: > er, lost the end of that first sentence

Re: [VOTE] Apache Geode 1.7.0 RC2

+1 * verified signatures * verified source distribution builds * ran basic gfsh commands * started pulse * verified examples work with rc2 Sai On Fri, Sep 28, 2018 at 8:57 AM Dave Barnes wrote: > +1 > Downloaded the release & successfully ran some representative gfsh > commands. > There

Re: [DISCUSS] Apache Geode 1.7.0 release branch created

gt; Nabarun Nag > > On Fri, Aug 31, 2018 at 10:18 AM Anthony Baker wrote: > > > Perhaps we should cut 1.7.0 without these changes to give us more time to > > review and complete the work. > > > > Thoughts? > > > > Anthony > > > > > >

Concourse - max containers reached

All resources are erroring out with "max containers reached"? Anyone looking into it? Sai

Re: [VOTE] Apache Geode 1.7.0 RC1

+1 * verified commit hash * checked concourse pipeline is green * ran examples with RC1 * built from source Sai On Wed, Sep 19, 2018 at 8:46 AM Nabarun Nag wrote: > REMINDER: VOTE deadline is today (EOD 19th September 2018 PDT) > > Regards > Nabarun Nag > > On Wed, Sep 19, 2018 at 7:13 AM

Extension Service - life cycle?

What's the recommended way to define an external service? Is there a set of interfaces that define life-cycle for an extension? I see CacheService[1] but it is currently defined as internal. [1]

Re: [VOTE] Apache Geode 1.8.0 RC2

Thanks Naba. I couldn't get this test to pass. Anyways if it still counts +1 for the release. I am okay to release native code if the version doesn't default to 1.8.0 as we are not including binaries. Sai On Tue, Dec 11, 2018 at 7:15 AM Jacob Barrett wrote: > The java bits generate a property

Re: [VOTE] Apache Geode 1.8.0 RC2

-0 - Ran examples - Building geode from source distribution or release branch consistently fails 1 unit test org.apache.geode.internal.cache.partitioned.rebalance.PartitionedRegionLoadModelJUnitTest > testRedundancySatisfactionPreferRemoteIp FAILED As CI is green on unit tests, I am considering

Re: [DISCUSS] and the NEW Apache Geode 1.7.0 release branch has been created

+1 to revert and fix on develop On Wed, Sep 12, 2018, 4:43 PM Nabarun Nag wrote: > Reverting them on release/1.7.0 will bring it to the previous status quo, > how all previous releases were done. I don't think anyone will build > release/1.7.0 repeatedly, hence there is no advantage of making

Re: Need gradle help

It looks[1] like it is been renamed as 'tests', so you can try testCompile 'org.apache.logging.log4j:log4j-core:' + project.'log4j.version' + ':tests' [1] https://repo.maven.apache.org/maven2/org/apache/logging/log4j/log4j-core/2.11.0/ On Fri, Sep 14, 2018 at 5:17 PM Jacob Barrett wrote: >

Re: Dependency review for release 1.9.0

ar in case of Reconnect" be included in 1.9 if > possible. > > Thanks > --Jens > > On Thu, Mar 28, 2019 at 6:50 AM Sai Boorlagadda > > wrote: > > > Changes to LICENSE and NOTICE files are cherry-picked on to release/1.9.0 > > branch. > > >

Re: [DISCUSS] Proposal to re-cut Geode 1.9.0 release branch

>>>>>>> On Mar 19, 2019, at 3:29 PM, Dan Smith wrote: > >>>>>>> > >>>>>>> Is the geode-managability sub-project and the new micrometer API > >> in > >>>> a > >>>>>> place > >>&

Re: [DISCUSS] Proposal to re-cut Geode 1.9.0 release branch

as experimental. But we have > >>>> not > >>>>>> yet > >>>>>>>> updated CacheFactory to allow injecting a meter registry (or > metrics > >>>>>>>> publishing service) there. So currently the only way to

Re: release/1.9.0 branch has been re-cut

I have updated JIRA tickets to 1.9.0 as in "update fixVersion = '1.9.0' where fixVersion = '1.10.0' AND status in (closed, resolved)" On Mon, Mar 25, 2019 at 8:49 AM Sai Boorlagadda wrote: > Hello Everyone, > > As discussed in other email thread I have re-cut a new release b

release/1.9.0 branch has been re-cut

Hello Everyone, As discussed in other email thread I have re-cut a new release branch for Apache Geode 1.9.0 - "release/1.9.0" off of sha "ec5a24b78c51b6a29b8bf656f91004d09510d244". We already have an existing pipeline for 1.9.0[1], So I will rename the current release branch as

Re: Dependency review for release 1.9.0

> bad pun). > > Anthony > > > > On Mar 15, 2019, at 11:07 AM, Sai Boorlagadda > wrote: > > > > I have a PR[1] to include LICENSE and NOTICE changes to develop. > > Once I have merged this to develop then I will cherry-pick this onto > 1.9.0 > > re

release/1.9.0 - are we ready?

Hello, It looks like we have fixed required licensing and bom related issues and the pipeline is looking much stable with other issues that have been fixed in last couple of weeks after we have re-cut the branch. So I wanted to ask the developers to see if we are ready for building an RC? Are

Re: build is broken on develop

I fixed the build. My apologies I didn't rebase before merging my PR. On Tue, Feb 26, 2019 at 12:33 PM Sai Boorlagadda wrote: > My commit broke the build on develop. I am on it. > >

Merging GEODE-6464 to release/1.9.0

This is a change to windows packer image to use a pinned version of OpenSSH to 7.2.2.1 as the newer version caused the ssh session to not be terminated even after the gradle completes successfully leading the actual CI job to timeout[1]. We never had a green run of *IntegrationTest jobs on

Re: GEODE-6389 fixed in release/1.9.0

FYI all. GEODE-6338 is already on the release branch. Thanks, Bruce for the update. https://issues.apache.org/jira/browse/GEODE-6338 On Wed, Feb 27, 2019 at 10:10 AM Anthony Baker wrote: > Sorry I meant GEODE-6338. > > > On Feb 27, 2019, at 9:41 AM, Sai Boorlagadda > wrote:

next steps on release/1.9.0

By end of this week, I am planning to create the first release candidate. Are there any other issues other than this last one? - GEODE-6359 - Bruce is looking into it. - geode-examples using https in build scripts. There are about 6[1] issues in JIRA that are in open/in-progress/re-opened status

Re: Release branch for Apache Geode 1.9.0 has been cut

uld you like me to? > > Thanks, > -Jason > > On Thu, Feb 21, 2019 at 3:37 PM Sai Boorlagadda > > wrote: > > > GEODE-6359 is unassigned in JIRA. Who is working on it? > > > > On Wed, Feb 20, 2019 at 9:08 AM Jason Huynh wrote: > > > > > Oh ok I thou

Re: GEODE-6389 fixed in release/1.9.0

Are you asking about GEODE-6343? Sai On Wed, Feb 27, 2019 at 7:51 AM Anthony Baker wrote: > Cool! Is GEODE-63438 also important to fix and merge into 1.9.0? > > Anthony > > > > On Feb 22, 2019, at 9:01 AM, Bruce Schuchardt > wrote: > > > > This issue has been resolved on develop and

Re: I need to merge the fix for 6468 into release/1.9.0

+1 for merging this fix to release/1.9.0 as this is required for the NIO related changes that are already merged. On Thu, Feb 28, 2019 at 4:47 PM Bruce Schuchardt wrote: > This is another ticket associated with the SSL/NIO work that is already > in release/1.9.0 > > commit

Re: 1.9 release date

I started working on LICENSE issues. On Fri, Mar 1, 2019 at 3:55 PM Anthony Baker wrote: > I’ll point out that the license issue I mentioned earlier this week isn’t > resolved. And that we’re bundling potentially incompatible Jackson jars. > > Anthony > > > > On Mar 1, 2019, at 3:41 PM,

Re: 1.9 release date

I am aligned here that we should not be firm on a date be flexible to get a more stable release out. But could someone explain to me how would we measure this stability? The pipelines are green and the community members have cherry-picked all issues that were critical. Unless we have some

broken IntegrationTestOpenJDK11 on develop?

I see integration tests are failing on develop. Is there anyone working on it? This is failing on release branch too, so I would want to chery-pick if there is a fix. Sai

Re: Release Managers

Do we need to create an infra ticket to create a new release? I don't seem to have permissions to create releases in Jira. On Wed, Feb 20, 2019 at 8:42 AM Jacob Barrett wrote: > Release manager need to add the next version number to JIRA when they > branch the release. Changes going into

  1   2   >