---
Spring Data GemFire > Nightly-ApacheGeode > #1054 was successful.
---
Scheduled
2458 tests in total.
https://build.spring.io/browse/SGF-NAG-1054/
--
So it sounds like (per Robert) we use the gradle-lint-plugin's
unused-dependency rule to warn us of unused dependencies. That handles one
side of the equation (only list *necessary* dependencies).
I haven't heard anyone mention tool support for the other side of the
equation: ensuring that we
I filed a PR but then I noticed that there are some */bin/* dirs under the
source trees in Geode, so it's probably not a good exclusion to commit. I
think I'm going to close my PR and try to prevent the IDEs from creating
additional bin dirs.
On Fri, Sep 28, 2018 at 1:21 PM, Sai Boorlagadda
I am wrong, it is probably eclipse.
On Fri, Sep 28, 2018, 11:12 AM Kirk Lund wrote:
> My intellij appears to be configured to use "out" so I'm not sure how it
> created "bin" dirs but it's possible. I added "*/bin/*" to the exclude list
> in rat.gradle to try that out. Thanks!
>
> On Thu, Sep
My intellij appears to be configured to use "out" so I'm not sure how it
created "bin" dirs but it's possible. I added "*/bin/*" to the exclude list
in rat.gradle to try that out. Thanks!
On Thu, Sep 27, 2018 at 8:34 PM, Sai Boorlagadda
wrote:
> Kirk,
>
> We can exclude bin directory in
Officially canceling vote for mail archive.
--Mark
On Wed, Sep 26, 2018 at 8:54 PM Nabarun Nag wrote:
> Hi Jason,
>
> Thanks for sharing your finding with the community and doing the needful to
> resolve the issue. I will be cherry-picking the resolution to the release
> branch and start with
Usually key fields are faster
--
Mike Stolz
Principal Engineer, GemFire Product Lead
Mobile: +1-631-835-4771
On Fri, Sep 28, 2018 at 2:49 PM siby_sekar wrote:
> Which is more performant running queries on key fields or non key fields?
>
> we have an object in the form
>
> sessionid : { List
Which is more performant running queries on key fields or non key fields?
we have an object in the form
sessionid : { Listmessages}
and message can be like {
id1,
sessionid,
name
}
etc.
--
Sent from: http://apache-geode-incubating-developers-forum.70738.x6.nabble.com/
+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
+1
Downloaded the release & successfully ran some representative gfsh commands.
There is still a problem that I noted in my RC1 review: the user guide
config files incorrectly specify v1.8.
This is not a showstopper, but this time I have created a JIRA ticket
(GEODE-5795) so if (heaven forfend) we
Agreed, plus many times you can declare that a dependency is either
(appropriately) "test" scope (for test dependencies only), "optional", or
(in certain cases) "provided", which will (should) have no impact to end
users, e.g. like conflicting dependencies.
However, I am in favor of reducing
>From the PR, Anthony, it seems to me that Patrick is proposing that each
build.gradle be explicit about mentioning the "things" it depends on. For
example:
[image: image.png]
Look at how geode-connectors goes from mentioning a few dependencies to
mentioning many more. The value of this is that
Hi Bill,
We are using a Gradle plug-in to identify dependencies that are unused, or
are declared in the wrong module or scope.
This is called out by the Gradle documents on improving build [
https://guides.gradle.org/performance/#avoid_unnecessary_and_unused_dependencies].
The plug-in
Bill has the heart of it, yes.
I should have also mentioned that this ties into java-library plugin
configuration, notably that the `compile` configuration is deprecated.
For dependences that we do not wish to leak, we will need to use
`implementation`. For dependencies which we intentionally
14 matches
Mail list logo
