Hi Jack,
Done! You should have access now.
Thanks,
-Dan
On Thu, May 23, 2019 at 1:18 PM Jack Weissburg
wrote:
> Hello,
>
> Could you please add jackw26 to Geode JIRA so that I can be assigned to
> tickets.
>
> Thanks,
>
> Jack
>
+1 to implementing this method in a minor release.
I'm with Jake on this one. Every bug we fix changes the behavior of the
product in some small way. This seems like a behavior change for the better
- I can't picture a use case where someone is actually *relying* on this
method throwing
Folks, this thread is dead. Please stop voting here!
>From Anthony:
Discussions related to committers and PMC members should be held on the
private@geode mailing list not the dev@ list.
On Mon, May 20, 2019 at 1:43 PM Xiaojian Zhou wrote:
> +1
>
> On Mon, May 20, 2019 at 11:50 AM Mike Stolz
d since it's just testing test code it seemed reasonable to ignore
> it).
>
> LauncherMemberMXBeanIntegration test still needs some love and I can look
> at that since I've worked on it in the past.
>
> --Jens
>
> On Fri, May 17, 2019 at 9:33 AM Dan Smith wrote:
>
> >
Looking at the metrics for the windows jobs, it looks like the windows
tests are mostly red due to a few specific tests. The acceptance and gfsh
distributed tests jobs seem to be ok, it's just the unit tests and
integration tests that have problems. It also looks like
ExportConfigCommandTest
ublic API
> > was changed?
> >
> > Well done Gester for finding this!!
> >
> > --Udo
> >
> > On 5/14/19 10:40, Dan Smith wrote:
> > > I think the changes for GEODE-6327 broke backwards compatibility in
> > > JSONFormatter with the change from fromJSON
I think the changes for GEODE-6327 broke backwards compatibility in
JSONFormatter with the change from fromJSON(String jsonString) to
fromJSON(String jsonString, String... identityFields)
Adding an additional varargs parameter to the method breaks code that was
compiled against the non-varargs
Hi Geet,
Welcome! I think I already gave you access to work with geode JIRAs
earlier? I see you listed as having access in JIRA. Is there something you
are trying to do that isn't working?
-Dan
On Mon, May 13, 2019 at 2:23 PM Geetanjali rawat
wrote:
> Hello Devs
>
> I would like to request
You should have access now.
Thanks!
-Dan
On Fri, May 3, 2019 at 1:15 PM Donal Evans wrote:
> Hi,
>
> Could I please be granted access to the Jira for Geode? My username is
> DonalEvans,
>
> Thanks,
> Donal
>
Option 2 does sound like a good way to go. It does seem like if you are
making changes to fix non-embedded mode, you probably need to add an
acceptance test for that mode since there is non already, regardless of
whether you deprecate non-embedded mode.
I have no issues with deprecating either
+1
Looks good to me. I ran the geode-release-check against the repo.
-Dan
On Fri, Apr 19, 2019 at 5:00 PM Owen Nichols wrote:
> Hello, Geode dev community,
>
>
> This is the fourth release candidate for Apache Geode, version 1.9.0.
>
> Thanks to all the community members for their
Hi devs,
I'm looking at trying to automate some of the geode release steps, but one
thing I noticed is that we are inconsistent about when or if we create a
release branch in our different repos that we release (geode,
geode-examples, geode-native). For geode, we create a branch when we start
the
Owen and I talked to Kirk and Aaron. It sounds like this issue does not
need to hold up release 1.9.0 because it's been in all previous versions.
If we need to create another RC we will get this fix in there.
-Dan
On Fri, Apr 19, 2019 at 1:50 PM Owen Nichols wrote:
> Hi Aaron, Kirk and Geode
+1 - this looks like a good fix to get in if it was introduced in 1.9.0.
-Dan
On Thu, Apr 18, 2019 at 1:28 PM Eric Shu wrote:
> I'd like to include the fix for the NPE.
> It is new in 1.9.
>
> Regards,
> Eric
>
You just need to do git remote prune origin. Git doesn't remove remote
branches from your local copy automatically.
-Dan
On Thu, Apr 18, 2019 at 8:08 AM Bruce Schuchardt
wrote:
> Sorry to spam everyone. "git branch -r" seems to be a local thing. I
> made a fresh clone of the apache repo and
As Anthony pointed out, each member (client, server, locator, etc.) writes
it's own statistics to it's own stats file.
There is are some server side stats that might have the information you are
looking for - see CacheServerStats. That has information about how many
operations the server has
+1
The java bits look good to me. I didn't look too much at geode-native -
Maybe someone who knows more about the geode-native codebase can take a
look at part?
Thanks,
-Dan
On Mon, Apr 15, 2019 at 3:06 PM Sai Boorlagadda
wrote:
> Hello, Geode dev community,
>
>
> This is the second release
Hi Sai,
It looks like you left some signing properties in gradle.properties in the
source distribution. Building the source distribution is failing with this
error to this. Maybe you could make a clean source distribution and
re-upload it?
1: Task failed with an exception.
---
* What
Hi Alberto,
You should have access to both now.
Thanks!
-Dan
On Thu, Apr 11, 2019 at 7:53 AM Alberto Gomez
wrote:
> Hi,
>
>
> Could you please grant me permissions to edit the wiki and assign JIRA
> tickets?
>
>
> My id is alberto.gomez
>
>
> Thanks!
>
>
> Alberto
>
>
>
WaitCriterion extends ThrowingRunnable. So this pattern should still work
as WaitCriterion did before. But just using an assertion inside of a lambda
is the better option.
-Dan
On Thu, Apr 11, 2019 at 12:02 PM Kirk Lund wrote:
> Just a quick heads up... I'm seeing an Awaitility usage pattern
r modify the
> currently-used XML files that live inside of the /.idea directory.
>
> +1 to removal of the idea plugin.
>
> On Wed, Apr 3, 2019 at 3:22 PM Dan Smith wrote:
>
> > I was under the impression that intellij's import actually used some of
> the
> > inf
I was under the impression that intellij's import actually used some of the
information in the idea{} blocks in the build. See
https://docs.gradle.org/current/userguide/idea_plugin.html.
But if the import works well without that extra configuration, I think we
should get rid of it.
-Dan
On Wed,
> But this "hidden" feature, what is that? Is this something that we would
> like to support or is this something that would be replaced with our
> existing efforts in the ConfigurationService and Metrics area.
>
The old JMX agent [1] was superseded by the newer JMX manager [2] sometime
before
Hi devs,
The org.apache.geode.admin package has been deprecated for about 7 years
[1].
I'd like to remove it, or at least move it to a separate module. I actually
started some work to move it to a separate module [2]. However in the
course of this process, I've found that this module has
Hi Mario,
You should have access to assign geode tickets now.
Thanks!
-Dan
On Fri, Mar 29, 2019 at 1:12 AM Mario Kevo wrote:
> Hi all,
>
> Can you give me access to Jira so I can assigne on tickets?
> My Jira Username is 'mkevo'.
>
> Thanks and BR,
> Mario
>
Hi Mario,
You should have access to assign geode tickets now.
Thanks!
-Dan
On Fri, Mar 29, 2019 at 1:29 AM Mario Ivanac wrote:
> Hi Geode Dev,
>
>
> Can you give me access to JIRA, so I can assign to tickets.
>
> My JIRA username is "mivanac".
>
>
> Thanks,
>
> Mario
>
Hi Bill,
You should have access now.
-Dan
On Tue, Mar 26, 2019 at 3:06 PM Bill Burcham wrote:
> I need edit access to https://cwiki.apache.org for:
>
> bill.burc...@gmail.com
>
> The immediate need is to update some UML here:
>
>
I have had several issues running clean in combination with other gradle
commands - I think because of our parallel build. Maybe do this?
$ ./gradlew clean; ./gradlew build -xtest
On Tue, Mar 26, 2019 at 10:43 AM Kirk Lund wrote:
> Intermittent build error caused by spotlessJava. My checkout
be
> >> too slow if we're overflowing the queue to disk.
> >>
> >> I've also walked through the conflation code. It applies only to the
> >> current batch being processed by the gateway sender. The data structure
> >> used to perform conflation is
> >>>>>
> >>>>> On Tue, Mar 19, 2019 at 5:20 PM Dale Emery
> wrote:
> >>>>>
> >>>>>> The Micrometer API is in, and marked as experimental. But we have
> >> not
> >>>> yet
> >>>>>
> 2) The developer wants to replicate _state_. This means that implicit
> state changes (expiration or eviction w/ destroy) could allow us to
> optimize the queue size. This is very similar to conflation, just a
> different kind of optimization.
>
> For this second case, does it make sense to
Sounds like a good feature. I'm interested to see what ordering guarantees
we want to implement - if we can expire things in the order they were added
to the queue that seems like a good way to go.
As Anil pointed out - do you really want to let the user pass in an
ExpirationAttributes object?
Is the geode-managability sub-project and the new micrometer API in a place
where we can cut a release branch? I know a bunch of changes have gone in
since the release branch, are we comfortable releasing these new
experimental features as they are right now?
-Dan
On Tue, Mar 19, 2019 at 2:38 PM
Huh, it looks like org.skyscreamer.jsonassert.JSONAssert is actually
dependent that vaadin artifact anyway, but we *excluded* it our geode-junit
build file! That's why you are getting a runtime error. Maybe just remove
the exclusion.
>From geode-junit:
compile('org.skyscreamer:jsonassert') {
Here's the original legal ticket -
https://issues.apache.org/jira/browse/LEGAL-349. It does seem kinda fuzzy.
What error are you getting if you remove geode-json? I don't see org.json
anywhere in the dependenies of geode-web-api:
./gradlew geode-web-api:dependencies
I also found this thing -
Hi,
We would like to start using gradle's new implementation dependency
notation in our build files.
This will affect downstream consumers of geode-core, hopefully in a good
way, in that many of our dependencies will now be marked runtime
dependencies in the pom instead of compile. That means it
t; > Definitely a reasonable change. Perhaps, for consistency sake, the same
> > should be applied to Geode's Memcached support? (in another PR).
> >
> >
> > On Tue, Mar 12, 2019 at 4:23 PM Dan Smith wrote:
> >
> > > I created a PR to move our redis support t
I created a PR to move our redis support to a separate module. Let me know
what you think:
https://github.com/apache/geode/pull/3284
Geode servers will still include redis on the classpath, so the only effect
of this is that if you are launching a server based on the maven
dependencies, you will
Hi Michael,
What's your JIRA username?
-Dan
On Fri, Mar 8, 2019 at 11:28 AM Michael Martell wrote:
> Hello,
>
> I can already create tickets.
> I am requesting access to Jira so that I may be assigned tickets.
>
> Thanks,
> Mike
>
Hi Matthew,
What's your JIRA username?
-Dan
On Fri, Mar 8, 2019 at 11:21 AM Matthew Reddington
wrote:
> Hello,
>
> I am requesting access to Jira so that I may be assigned tickets.
>
> Matthew Reddington
>
Hi Gang,
I've added you to the wiki. You may want to subscribe to the dev list
(email dev-subscr...@geode.apache.org).
Thanks!
-Dan
On Thu, Mar 7, 2019 at 2:12 PM Anthony Baker wrote:
> What’s your username?
>
> > On Mar 7, 2019, at 12:15 PM, Gang Yan wrote:
> >
> > Hi Geode dev
> >
> >
Sure! What is your username on the apache wiki?
-Dan
On Thu, Mar 7, 2019 at 12:19 PM Gang Yan wrote:
> Hi Geode dev
>
> could you help to get edit permission of wiki page :
>
> https://cwiki.apache.org/confluence/display/GEODE/Cluster+Management+Service
>
> thanks.
>
> Thanks and regards
>
>
For example, `geode-lucene` would only pull in the Apache Lucene
> dependencies if the `geode-lucene` module is used.
>
> No brainer.
>
> On Thu, Feb 28, 2019 at 9:47 AM Charlie Black wrote:
>
> > Hopefully, we are thinking about classpath of the server and lazily
> adding
> &
I see that geo, grumpy-core, and commons math came from adding geospatial
support to redis -
https://github.com/apache/geode/commit/7bf02251fd047cb1cf575c01b80a9807108618da
-Dan
On Thu, Feb 28, 2019 at 9:41 AM Anthony Baker wrote:
> Looks a number of the new dependencies came in transitively
hneider
> GEODE-5817 - CI Failure: StopServerAccepta... - Kenneth Howe
> GEODE-5816 - ClusterStartupRule fails to ... - Dan Smith
> GEODE-5711 - create jndi-binding gfsh ... - Karen Smoler
> Miller
> GEODE-4794 - ConfigurePDXCommand - Joey
+1
On Wed, Feb 20, 2019 at 12:24 PM Jacob Barrett wrote:
> Anyone have issue with merging
> https://issues.apache.org/jira/browse/GEODE-6424 <
> https://issues.apache.org/jira/browse/GEODE-6424> into release/1.9.0?
>
> Without it we will have to wait for the next release before we can have
>
I added a 1.10.0 release to JIRA.
-Dan
On Wed, Feb 20, 2019 at 9:29 AM Sai Boorlagadda
wrote:
> 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
+1 to what Jake said about MemberMXBean - that is definitely a public API
class, so we need to deprecate the old method and introduce a new one.
I'm also not clear about the stats. Technically, they are discoverable
through the public API, so maybe? It seems like they are mix of things
users
Regarding @Immutable - yes it's intentionally a field annotation as well as
a class annotation. The reason to make it a field annotation is that the
static analysis tools aren't quite cool enough to figure out if a field is
really immutable so we have to manually tell the tool that the field is
+1 - Looks good to me.
-Dan
On Tue, Feb 12, 2019 at 3:34 PM Dave Barnes wrote:
> Please respond by noon tomorrow.
> Pretty complete, as far as I know, except for public events and
> presentations.
> Thanks,
> Dave
>
> Description:
>
> Apache Geode provides a database-like consistency model,
Hi devs,
We've expressed interest in getting rid of singletons and allowing multiple
copies of cache to run in the same JVM.
I'd like to get a handle on what static state we have. As a first step I'd
like to introduce a few annotations and some static analysis to find all of
our mutable static
Thanks Kirk - this is GEODE-5676. I'm glad the callstacks are finally
working again, that should help us track this down! I'll update that ticket
with anything I can figure out from this failure.
-Dan
On Wed, Jan 23, 2019 at 10:05 AM Kirk Lund wrote:
> Looks like there's a Test worker thread
Sounds good. +1 to failing the build if new warnings are introduced.
-Dan
On Tue, Jan 15, 2019 at 12:59 PM Galen O'Sullivan
wrote:
> I'm for failing CI on warnings. It would be nice to reduce or eliminate our
> existing build warnings as well.
>
> Thanks,
> Galen
>
>
> On Tue, Jan 15, 2019 at
If I understand this right, you are talking about a way to create a
PdxInstance that has no corresponding java class. How about just a
RegionService.createPdxInstanceFactory() method that doesn't take a
classname, and therefore has no corresponding java class? It seems a
PdxInstances without a
+1 Micrometer looks awesome.
I'd love to see more details on how this will work. How will you hook
micrometer in? Will all of the stats that are currently exposed in VSD be
exposed in micrometer, or just some subset? How does a user configure which
monitoring system(s) micrometer is sending data
What sort of services are you thinking of adding?
Technically, things like a CacheLoader or a SecurityManager are SPIs in the
sense that they places where you can plug your code into geode. Using a
ServiceLoader might ok in cases where we want something to be plugged in if
the jar is on the
Done! You should have access now.
-Dan
On Thu, Jan 3, 2019 at 3:53 PM Charlie Black wrote:
> Dan,
>
> Awesome and thanks! My username is charliemblack
>
> Charlie
>
> On Thu, Jan 3, 2019 at 3:17 PM Dan Smith wrote:
>
> > Hi Charlie,
> >
> > Sure
Hi Charlie,
Sure, what's your user name in the apache JIRA?
-Dan
On Thu, Jan 3, 2019 at 3:02 PM Charlie Black wrote:
> I am currently acting as a product manager for geode native client
> component. I was wondering if I could have edit privileges for the Geode
> JIRA?
>
> Thanks,
>
>
Good question! I think we intentionally left the default branch as master
so that users cloning the examples from github will get examples that work
against a released version of geode.
That said, I don't feel too strongly if we would rather make things more
consistent with the geode repo - it
Hi Peter,
You should have access now.
Thanks!
-Dan
On Wed, Dec 12, 2018 at 7:04 AM Peter Tran wrote:
> Thanks Dan!
>
> It's ptran
>
> On Tue, Dec 11, 2018 at 4:16 PM Dan Smith wrote:
>
> > Hi Peter,
> >
> > Sure, what's your user name on the apache wiki?
Hi Peter,
Sure, what's your user name on the apache wiki?
-Dan
On Tue, Dec 11, 2018 at 1:08 PM Peter Tran wrote:
> Hi Geode Devs,
>
> I was having a look at
>
>
-0.
Code looks good to me and it passes geode-release-check. But I'd really
like to see some people who have worked on the native code sign off on this
release. We haven't released the native code before, and I don't know how
to validate it other than just to see that it compiles, which doesn't
The native source distribution tarball seems to have a lot of files that
aren't in source control. See attached:
-Dan
On Wed, Dec 5, 2018 at 6:19 PM Alexander Murmann
wrote:
> Hi Apache Geode community,
>
> Below you find all the information for the the second release candidate of
> Geode
+1 to removing PowerMock. Any situation that needs PowerMock needs
refactoring more.
-Dan
On Tue, Dec 4, 2018 at 10:27 AM Kirk Lund wrote:
> Anyone have any ideas which unit test is using PowerMock and is injecting a
> mock ClassLoader? This keeps failing in my precheckin runs. I think we need
/master_middleman/source/subnavs
-Dan
On Mon, Dec 3, 2018 at 1:43 PM Dan Smith wrote:
> 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 lice
s
> gained
> > > native support for .tgz archives. If there is still a segment of the
> > Geode
> > > user community that would suffer hardship due to lack of .zip
> packaging,
> > we
> > > should revisit this decision.
> > >
> > > -Owe
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
eal wire-format with a well-defined
> protocol but that's probably a separate project in its own right.
>
> Are you really convinced that we could move internal classes around without
> breaking rolling upgrades, client-server backwards compatibility and
> diskstore contents?
>
>
Congratulations Karen! And thanks for all of your hard work, Mark!
-Dan
On Mon, Nov 26, 2018 at 11:56 AM Mark Bretl wrote:
> Hello Geode Community,
>
> After two years, the Project Management Committee (PMC) agreed to
> transition the role of PMC chair from me to another PMC member. I would
>
Done!
-Dan
On Mon, Nov 26, 2018 at 11:15 AM Sean Goller wrote:
> Hi, In order to start dealing with some JIRA tickets could I get assign and
> resolve access?
> My apache username is smgoller.
>
> Thanks!
>
> -Sean.
>
Does anyone have the creds to enable travis on the geode-benchmarks repo?
We have it enabled on all of our other geode repos.
https://travis-ci.org/apache/geode-benchmarks
-Dan
I think we can actually fix most of these issues without geode-2.0. Most of
these are in internal packages, which means we can change the package of
these classes without breaking users. The only concerning one is
org.apache.geode.cache.util, which is a public package. However, the
AutoBalancer is
tTest is old flaky. The PR to
> > refactor the test passed all checks, even the repeatTest as well. I had a
> > closed PR that just touched the "un-refactored" EvictionDUnitTest, it
> > wouldn't even pass the repeatTest at all.
> >
> > On Mon, Nov 12,
Seems like there is enough consensus. I will go ahead and create the repo.
Thanks!
-Dan
On Fri, Nov 16, 2018 at 1:37 PM Kirk Lund wrote:
> +1 total agreement then!
>
> On Fri, Nov 16, 2018 at 10:05 AM Dan Smith wrote:
>
> > Hi Kirk,
> >
> > What we're thinking
Ok, you should have access now.
-Dan
On Mon, Nov 19, 2018 at 3:03 PM Robert Houghton
wrote:
> rhoughton
>
> On Mon, Nov 19, 2018 at 2:54 PM Dan Smith wrote:
>
> > What's your jira user name?
> >
> > -Dan
> >
> > On Mon, Nov 19, 2018 at 1:39 PM Rober
What's your jira user name?
-Dan
On Mon, Nov 19, 2018 at 1:39 PM Robert Houghton
wrote:
> Hi all. I have a few opened Geode JIRA issues that I would like to be able
> to delegate and work on, but I don't have access to the 'assign' or
> 'resolve' actions. Can I get access?
>
> Thank you,
>
e repo (or worse, after a release)
>
> On Thu, Nov 15, 2018 at 10:47 AM Dan Smith wrote:
>
> > Hi all,
> >
> > We (Naba, Sean, Brian and I) would like to add some benchmarks for geode,
> > with a goal of eventually running them as part of our concourse build and
> &g
Hi all,
We (Naba, Sean, Brian and I) would like to add some benchmarks for geode,
with a goal of eventually running them as part of our concourse build and
detecting performance changes.
We think it makes sense to put these benchmarks in a separate
geode-benchmarks repository. That will make
> bschucha...@pivotal.io
> >>>
> >>> wrote:
> >>>
> >>>> I'm in favor of this.
> >>>>
> >>>> Several times over the years we've made a big push to get precheckin
> to
> >>>> reliably only to see rapi
Hi all,
Kirks emails reminded me - I think we are at the point now with our PR
checks where we should not be merging anything to develop that doesn't pass
all of the PR checks.
I propose we disable the merge button unless a PR is passing all of the
checks. If we are in agreement I'll follow up
Our release tags should already be protected. We create all of our release
tags under rel/ which apache protects by default. [1]
Maybe we should just create rel/XXX tags for the heads of the branches
Anthony mentioned and delete the branches themselves?
AM Jinmei Liao wrote:
> Dan, are you saying we do or do not need --add-opens for reflection? The
> opens directive is for open up classes in its own modules for reflection. I
> don't think we can use that to open up jdk's packages, can we?
>
> On Fri, Nov 2, 2018 at 3:52 PM D
pport is still in beta mode.
> > >
> > > On Thu, Nov 1, 2018 at 10:33 AM Jinmei Liao wrote:
> > >
> > > > 1) yes, gfsh script will need to be updated to add these
> > configurations.
> > > > 2) yes, these ad-opens are required to run geode clients as
A couple of questions:
1) Are you proposing changing gfsh start server to automatically add these
add-opens, or are you suggesting users will have to do that?
2) Are these add-opens required for running a geode client?
-Dan
On Thu, Nov 1, 2018 at 9:48 AM Patrick Rhomberg
wrote:
> In case
Yay for APIs that don't require singletons!
-Dan
On Wed, Oct 31, 2018 at 2:54 PM Jinmei Liao wrote:
> +1. sounds like a good addition and since we already have package level
> getters for them anyway.
>
> On Wed, Oct 31, 2018 at 2:48 PM Kirk Lund wrote:
>
> > LocatorLauncher provides an API
We are coming up on the date where we said we would start the 1.8 release
(Nov 1st).
Any volunteers to be release manager for this release?
-Dan
(2) seems like the only reasonable option. We don't want to get stuck not
being able to support newer TLS versions!
-Dan
On Wed, Oct 24, 2018 at 11:23 AM Jinmei Liao wrote:
> Most of our SSL tests failed with jdk11 because jdk11 includes an
> implementation of TLS1.3 protocol, so if tcpServer
Done, you should have access now.
Thanks,
-Dan
On Fri, Oct 19, 2018 at 10:50 AM Owen Nichols wrote:
> I would like to request Jira permissions (in order to mark associated
> tickets as resolved that were fixed by my recently-accepted pull request
> #2643)
>
> My Jira username is
;>
> >> > After further discussion, based on GC variability +1 for what Dan
> said.
> >> >
> >> > Thanks,
> >> > Mark
> >> >
> >> > > On Jul 11, 2018, at 12:53 PM, Jacob Barrett
> >> wrote:
> >> >
this release go a
little smoother.
[1] https://travis-ci.org/apache/geode-native/branches
[2] https://cwiki.apache.org/confluence/display/GEODE/Releasing+Apache+Geode
On Thu, Oct 11, 2018 at 3:23 PM Dan Smith wrote:
> +1 for a source release. Awesome!
>
> -Dan
>
> On Thu, Oct 1
Should be fixed now, if you rebase/merge on the latest develop.
-Dan
On Wed, Oct 17, 2018 at 3:10 PM Dan Smith wrote:
> Hi all,
>
> It looks like some recent changes caused the StressNewTest job in the PR
> checks to not use docker to run the tests. This means you may
Hi all,
It looks like some recent changes caused the StressNewTest job in the PR
checks to not use docker to run the tests. This means you may see failures
such as a DiskAccessExceptions due to concurrent modification of files, or
just "Could not start dunit VMS" until GEODE-5893 is fixed.
-Dan
What I think is important is that any java code should be in a Java source
file that is compiled as part of a build. Don't put java source or bytecode
in as resource or as a constant.
For testing deploy jar I thought what Helena and I ended up doing in
StartServerCommandDUnitTest worked pretty
On Thu, Oct 11, 2018 at 3:36 PM Owen Nichols wrote:
> Does same go for Windows jobs? They seem to be reliably green at this
> point, yet are not gating. Should they be hidden by default as well for
> consistency?
>
Seems reasonable. I don't know if that means we should hide the windows
jobs
of the native client is a
> > > good
> > > > first step. That lets us focus on verifying that all the tasks
> > outlined
> > > in
> > > > [1] are complete and correct.
> > > >
> > > > Anthony
> > > >
> > &g
At the current moment I don't think it makes sense to run old versions with
anything but JDK 8, since they didn't support JDK 9+ or anything like that.
Going forward though it seems like we should start running the backwards
compatibility tests between versions that do support JDK 9+, once we
out compiling
> > > >> module-info.java in Java 9+ and including it in a jar with classes
> > > >> compiled
> > > >> for Java 8.
> > > >>
> > > >> https://github.com/google/guava/issues/2970
> > > >>
> &g
I feel like it would be better to keep the Java 11 jobs off of the main tab
in the pipeline until they are actually working. In the spirit of keeping
develop releasable, we should keep the main pipeline clean and only include
what is releasable today in the pipeline.
Thoughts?
-Dan
#2 seems like the least hacky way to continue using things like
sun.misc.Unsafe. Could we just compile a module-info.java with Java 9 and
bundle it? This would also help consumers of geode that want to use Java 9
modules.
I'm a little bit sceptical of this permit-reflect libary, seeing as it's
That is awesome! Let's get it in!
I think there are some details to work out:
- Do we need to build any automation for creating the native source
release (similar to ./gradlew srcDist on the java side)?
- Will we release binaries? Which platforms and how to does the release
manager build them?
301 - 400 of 886 matches
Mail list logo
