Re: [VOTE] Apache Geode 1.7.0 RC2
+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 roll an RC3, the correction will be included. On Thu, Sep 27, 2018 at 7:13 PM, Nabarun Nag wrote: > Following checks completed: > - checked signatures -src.tgz -examples.tgz -.tgz > - checked SHA's -src.tgz -examples.tgz -.tgz > - builds from source > - run gfsh - start locator, server - create region - do put and get - > execute OQL query > - examples run cleanly > - the correct version in gfsh command version > - out scripts are now present in the source distribution > -> ./ci/resource-types/gce-instances-resource/out > -> ./ci/resource-types/concourse-metadata-resource/files/out > > Regrads > Nabarun Nag > > > On Thu, Sep 27, 2018 at 6:54 PM Nabarun Nag wrote: > > > This is the second release candidate for Apache Geode, version 1.7.0. > > Thanks to all the community members for their contributions to this > > release! > > > > Please do a review and give your feedback. The deadline is the end of day > > 2nd October 2018. > > > > It resolves 351 issues on Apache Geode JIRA system. Release notes can be > > found at: > > https://cwiki.apache.org/confluence/display/GEODE/ > > Release+Notes#ReleaseNotes-1.7.0 > > > > > > Please note that we are voting upon the source tags: rel/v1.7.0.RC2 > > Apache Geode: > > https://github.com/apache/geode/tree/rel/v1.7.0.RC2 > > Apache Geode examples: > > https://github.com/apache/geode-examples/tree/rel/v1.7.0.RC2 > > > > Commit ID: > > Apache Geode: > > 48061cdcc293d42020b8695a5a23c4dd360550ff > > Apache Geode Examples: > > 9dca29c7c10fa8d44abc893271420476cfc0808f > > > > > > Source and binary files: > > https://dist.apache.org/repos/dist/dev/geode/1.7.0.RC2/ > > > > Maven staging repo: > > https://repository.apache.org/content/repositories/orgapachegeode-1046 > > > > Geode's KEYS file containing PGP keys we use to sign the release: > > https://github.com/apache/geode/blob/develop/KEYS > > > > Signed the release with fingerprint: > > rsa4096 2018-01-04 [SC] [expires: 2022-01-04] > > CE6CD0A89480B1B9FCB98699274C66710770C135 > > > > rsa4096 2018-01-04 [SC] [expires: 2022-01-04] > > > > I do apologize if there was an oversight. > > > > PS: Command to run geode-examples: ./gradlew -PgeodeReleaseUrl= > > https://dist.apache.org/repos/dist/dev/geode/1.7.0.RC2 > > -PgeodeRepositoryUrl= > > https://repository.apache.org/content/repositories/orgapachegeode-1046 > > build runAll > > > > Regards > > Nabarun Nag > > >
Re: [Discuss] Transitive dependencies and internal .pom changes
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 dependencies that are no long needed, if possible. On Thu, Sep 27, 2018 at 10:07 PM, Anthony Baker wrote: > I don’t follow why we should get rid of transitive dependencies. Can you > help me understand? How does this help with decoupling modules? > > The whole java ecosystem is based on declaring and consuming transitive > dependencies via maven pom’s. I get the api/implementation dependency > separation, but that’s different. > > Anthony > > > > On Sep 27, 2018, at 7:04 PM, Patrick Rhomberg > wrote: > > > > Hello all! > > > > # As a one paragraph elevator pitch: > > > > A module should declare its own dependencies and not expose those > > dependencies to a consumer unless explicitly intending to do so. As part > > of working towards better decoupling between Geode's modules, we should > > eliminate our reliance on transitive dependencies. Dependencies required > > by the top-level project should remain unchanged. Please review these > > changes [1] and discuss possible impact. > > > > > > # Verbosely: > > > > As part of general build improvements, becoming Gradle 5 ready, and > > positioning the build to be more modular, Robert Houghton and I have been > > investigating reducing our (internal) reliance on transitive > dependencies, > > explicitly declaring those dependencies a given module has, and removing > > dependencies that are no longer consumed by a given module. > > > > Leaking dependencies has the potential to effect user experience. For > > instance, if a user would like to use a different implementation of > logging > > than we use internally, doing so should not ruin the classpath. Leaking > > our own implementations are dangerous in these sorts of situation, and > this > > has been a pain-point of interaction between Geode and Spring in the > past. > > For instance, GEODE-5001 found at its crux exactly this logging version > > mismatch as its issue. Conversely, a great deal of preparation for this > PR > > was spent tracking down which plugins were leaking conflicting versions > > JGit. Let's do better by the consumers of Geode! > > > > Much of our investigation has been driven by the Nebula dependency linter > > plugin, which I would additionally propose to be a valuable addition in > > verifying and maintaining the quality of our build. > > > > Note all dependency and POM changes effect only each module. The > > dependences for the product as a whole should and will remain unchanged > by > > this. The core driving force will be to allow for better modularity for > > Geode and extension developers interacting with individual pieces of > Geode. > > > > See pull request 2532 [1] for comparison in explicit dependency > declaration > > and potential changes to existing POMs. > > > > Regards. > > > > Imagination is Change. > > ~Patrick Rhomberg > > > > [1] https://github.com/apache/geode/pull/2532 > > -- -John john.blum10101 (skype)
Re: [Discuss] Transitive dependencies and internal .pom changes
>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 it ostensibly shows us all the things that geode-connectors actually depends on. The challenge I see is two-fold: • as with Java imports and "unused imports", there is the risk of listing more dependencies than we actually need • there's also the risk that we still don't have a complete list of dependencies Patrick: do you have tool support for this? Is there a tool that can identify or even remove unused dependencies? What process do you use for finding these heretofore hidden dependencies? Did you run gradle app:dependencies?
Re: [Discuss] Transitive dependencies and internal .pom changes
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 documentation is here [ https://github.com/nebula-plugins/gradle-lint-plugin/wiki/Unused-Dependency-Rule ] Thank you, -Robert Houghton On Fri, Sep 28, 2018 at 10:18 AM Bill Burcham wrote: > 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 it ostensibly shows us all > the things that geode-connectors actually depends on. > > The challenge I see is two-fold: > > • as with Java imports and "unused imports", there is the risk of listing > more dependencies than we actually need > • there's also the risk that we still don't have a complete list of > dependencies > > Patrick: do you have tool support for this? Is there a tool that can > identify or even remove unused dependencies? What process do you use for > finding these heretofore hidden dependencies? Did you run gradle > app:dependencies? >
Re: [Discuss] Transitive dependencies and internal .pom changes
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 elect to share with our consumers, we should use `api`. For modularity, it should not break one module's ability to build for another module to declare a `compile` configuration to be `implementation`, unless of course that dependency is an active and necessary component part of that module's consumption. In that case, it should be declared part of the modules `api`. In this vein and as Bill pointed out, a module should have an accurate representation of its own build-time dependencies. In time, this will allow a much improved build experience, since `implementation` and `api` are positioned for better granularity of incremental building. On Fri, Sep 28, 2018 at 10:23 AM, Robert Houghton wrote: > 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 documentation is here [ > https://github.com/nebula-plugins/gradle-lint-plugin/ > wiki/Unused-Dependency-Rule > ] > > Thank you, > -Robert Houghton > > On Fri, Sep 28, 2018 at 10:18 AM Bill Burcham wrote: > > > 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 it ostensibly shows us > all > > the things that geode-connectors actually depends on. > > > > The challenge I see is two-fold: > > > > • as with Java imports and "unused imports", there is the risk of listing > > more dependencies than we actually need > > • there's also the risk that we still don't have a complete list of > > dependencies > > > > Patrick: do you have tool support for this? Is there a tool that can > > identify or even remove unused dependencies? What process do you use for > > finding these heretofore hidden dependencies? Did you run gradle > > app:dependencies? > > >
Re: Rat is failing due to generated files under bin directories
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 `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 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 build seems to create these bin directories under each > >> module > >> > which is fine. > >> > > >> > But now Rat is failing because of the generated files under these bin > >> > directories. This in turn causes my local command-line build to fail. > >> > > >> > Does anyone know how to make this problem go away without using "-x > >> rat"? > >> > > >> > Unapproved licenses: > >> > > >> > > >> > > >> /Users/klund/dev/gemfire3/open/extensions/geode-modules/ > bin/main/modules-version.properties > >> > > >> > > >> /Users/klund/dev/gemfire3/open/extensions/geode-modules/ > bin/test/org/apache/geode/modules/Event.hbm.xml > >> > > >> > > >> /Users/klund/dev/gemfire3/open/extensions/geode-modules/ > bin/test/org/apache/geode/modules/Person.hbm.xml > >> > > >> > > >> /Users/klund/dev/gemfire3/open/geode-core/bin/main/org/ > apache/geode/cache/query/internal/parse/OQLLexer.smap > >> > > >> > > >> /Users/klund/dev/gemfire3/open/geode-core/bin/main/org/ > apache/geode/cache/query/internal/parse/OQLParser.smap > >> > > >> > > >> /Users/klund/dev/gemfire3/open/geode-core/bin/test/org/ > apache/geode/management/internal/configuration/utils/ > XmlUtilsAddNewNodeJUnitTest.testAddNewNodeNewNamed.xml > >> > > >> > > >> /Users/klund/dev/gemfire3/open/geode-core/bin/test/org/ > apache/geode/management/internal/configuration/utils/ > XmlUtilsAddNewNodeJUnitTest.testAddNewNodeNewUnnamed.xml > >> > > >> > > >> /Users/klund/dev/gemfire3/open/geode-core/bin/test/org/ > apache/geode/management/internal/configuration/utils/ > XmlUtilsAddNewNodeJUnitTest.testAddNewNodeNewUnnamedExtension.xml > >> > > >> > > >> /Users/klund/dev/gemfire3/open/geode-core/bin/test/org/ > apache/geode/management/internal/configuration/utils/ > XmlUtilsAddNewNodeJUnitTest.testAddNewNodeReplaceNamed.xml > >> > > >> > > >> /Users/klund/dev/gemfire3/open/geode-core/bin/test/org/ > apache/geode/management/internal/configuration/utils/ > XmlUtilsAddNewNodeJUnitTest.testAddNewNodeReplaceUnnamed.xml > >> > > >> > > >> /Users/klund/dev/gemfire3/open/geode-core/bin/test/org/ > apache/geode/management/internal/configuration/utils/ > XmlUtilsAddNewNodeJUnitTest.testAddNewNodeReplaceUnnamedExtension.xml > >> > > >> > > >> /Users/klund/dev/gemfire3/open/geode-core/bin/test/org/ > apache/geode/management/internal/configuration/utils/ > XmlUtilsAddNewNodeJUnitTest.testDeleteNodeNamed.xml > >> > > >> > > >> /Users/klund/dev/gemfire3/open/geode-core/bin/test/org/ > apache/geode/management/internal/configuration/utils/ > XmlUtilsAddNewNodeJUnitTest.testDeleteNodeUnnamed.xml > >> > > >> > > >> /Users/klund/dev/gemfire3/open/geode-core/bin/test/org/ > apache/geode/management/internal/configuration/utils/ > XmlUtilsAddNewNodeJUnitTest.testDeleteNodeUnnamedExtension.xml > >> > > >> > > >> /Users/klund/dev/gemfire3/open/geode-core/bin/test/org/ > apache/geode/management/internal/configuration/utils/ > XmlUtilsAddNewNodeJUnitTest.xml > >> > > >> > > >> /Users/klund/dev/gemfire3/open/geode-core/bin/test/org/ > apache/geode/management/internal/configuration/utils/XmlUtilsJUnitTest. > testBuildSchemaLocationMapAttribute.xml > >> > > >> > > >> /Users/klund/dev/gemfire3/open/geode-core/bin/test/org/ > apache/geode/management/internal/configuration/utils/XmlUtilsJUnitTest. > testBuildSchemaLocationMapEmptyAttribute.xml > >> > > >> > > >> /Users/klund/dev/gemfire3/open/geode-core/bin/test/org/ > apache/geode/management/internal/configuration/utils/XmlUtilsJUnitTest. > testBuildSchemaLocationMapNullAttribute.xml > >> > > >> > > >> /Users/klund/dev/gemfire3/open/geode-core/bin/test/org/ > apache/geode/management/internal/configuration/utils/XmlUtilsJUnitTest. > testQuerySingleElement.xml > >> > >> >
[CANCEL][VOTE] Apache Geode 1.7.0 RC1
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 the process of create a new release candidate.
>
> Hello Geode community,
>
> We are terminating all tasks related to RC1 for Apache Geode 1.7.0. Please
> stay tuned for the next release candidate.
>
> Regards
> Nabarun Nag
>
>
> On Wed, Sep 26, 2018 at 5:41 PM Jason Huynh wrote:
>
> > Hi Nabarun,
> >
> >
> >
> > Thanks for delaying the vote, after investigating, it looks like we may
> > have increased our chances of WAN inconsistency in a specific scenario.
> > After trying this same app on previous releases, I was able to pinpoint
> > which checkin started to amplify the problem and increase the number of
> > scenarios this inconsistency can occur.
> >
> >
> > The ticket in question is GEODE-3967, the problem with this checkin is
> that
> > we try to enqueue wan events in a catch block for
> > ConcurrentCacheModificationExceptions. We end up enqueueing these “old”
> > events (which can now be considered out of order) and then get
> transmitted
> > to the other WAN site and leaves the sites inconsistent with each other.
> >
> >
> > I’ve reverted the commit for GEODE-3967 on develop if you want to pull
> this
> > into the release.
> >
> >
> >
> > Thanks,
> >
> > -Jason
> >
> > On Mon, Sep 24, 2018 at 12:23 PM Nabarun Nag wrote:
> >
> > > Hi Jason,
> > >
> > > We can wait until the investigation is completed, as this can be a
> > > potential -1 to the RC.
> > >
> > > Regards
> > > Nabarun Nag
> > >
> > > On Mon, Sep 24, 2018 at 12:20 PM Jason Huynh
> wrote:
> > >
> > > > I'm currently looking into an issue in WAN when running this rc. Not
> > > sure
> > > > if it's a showstopper and I can't actually describe what the problem
> > is,
> > > > but a sample application I have is not behaving the same as before,
> > there
> > > > may be a data inconsistency... if it's not too late, would you be
> able
> > to
> > > > extend the vote?
> > > >
> > > >
> > > >
> > > >
> > > > On Wed, Sep 19, 2018 at 11:47 AM Dave Barnes
> > wrote:
> > > >
> > > > > +0
> > > > > Recasting my vote, just for full disclosure. I found a (very minor)
> > > > problem
> > > > > in the source release doc files: If a user builds their own docs
> from
> > > > > sources, they'll say version 1.8.
> > > > >
> > > > >- NOT (even close to) a showstopper
> > > > >- This will NOT affect the User Guide we'll push to the website
> > with
> > > > the
> > > > >release, which will be correctly labeled 1.7
> > > > >- Javadocs are NOT affected - they are correctly versioned as
> 1.7
> > > > >
> > > > >
> > > > > On Wed, Sep 19, 2018 at 11:09 AM, Sai Boorlagadda <
> > > > > sai.boorlaga...@gmail.com
> > > > > > wrote:
> > > > >
> > > > > > +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 Anthony Baker <
> aba...@pivotal.io
> > >
> > > > > wrote:
> > > > > > >
> > > > > > > > I think we can get rid of the **/out/** exclusion in the
> build
> > > > > script,
> > > > > > > > let’s do that for the next release.
> > > > > > > >
> > > > > > > > Anthony
> > > > > > > >
> > > > > > > >
> > > > > > > > > On Sep 18, 2018, at 3:52 PM, Dan Smith
> > > > wrote:
> > > > > > > > >
> > > > > > > > > +0
> > > > > > > > >
> > > > > > > > > I noticed that someone added some files called "out" to the
> > > repo
> > > > > that
> > > > > > > > > aren't included in the source distribution:
> > > > > > > > >
> > > > > > > > > ./ci/resource-types/gce-instances-resource/out
> > > > > > > > > ./ci/resource-types/concourse-metadata-resource/files/out
> > > > > > > > >
> > > > > > > > > These aren't included in the source distribution because we
> > are
> > > > > > > > explicitly
> > > > > > > > > excluding anything called "out." Presumably we thought
> > anything
> > > > > > called
> > > > > > > > out
> > > > > > > > > is an output directory ("out" is also in .gitignore). So
> the
> > ci
> > > > > > > directory
> > > > > > > > > in the source distribution is incomplete. But maybe that
> > > doesn't
> > > > > > matter
> > > > > > > > > because it is just CI configuration?
> > > > > > > > >
> > > > > > > > > Everything else looks good.
> > > > > > > > >
> > > > > > > > > -Dan
> > > > > > > > >
> > > > > > > > > On Mon, Sep 17, 2018 at 5:06 PM, Nabarun Nag <
> > n...@apache.org>
> > > > > > wrote:
> > > > > > > > >
> > > > > > > > >> *DEADLINE
Queries on key fields
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/
Re: Queries on key fields
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 : { Listmessages}
>
> and message can be like {
>
> id1,
>
> sessionid,
>
> name
>
> }
>
> etc.
>
>
>
>
>
> --
> Sent from:
> http://apache-geode-incubating-developers-forum.70738.x6.nabble.com/
>
Re: Rat is failing due to generated files under bin directories
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 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 at 7:02 PM Sai Boorlagadda < > sai.boorlaga...@gmail.com > > > > > 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 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 build seems to create these bin directories under each > > >> module > > >> > which is fine. > > >> > > > >> > But now Rat is failing because of the generated files under these > bin > > >> > directories. This in turn causes my local command-line build to > fail. > > >> > > > >> > Does anyone know how to make this problem go away without using "-x > > >> rat"? > > >> > > > >> > Unapproved licenses: > > >> > > > >> > > > >> > > > >> /Users/klund/dev/gemfire3/open/extensions/geode-modules/ > > bin/main/modules-version.properties > > >> > > > >> > > > >> /Users/klund/dev/gemfire3/open/extensions/geode-modules/ > > bin/test/org/apache/geode/modules/Event.hbm.xml > > >> > > > >> > > > >> /Users/klund/dev/gemfire3/open/extensions/geode-modules/ > > bin/test/org/apache/geode/modules/Person.hbm.xml > > >> > > > >> > > > >> /Users/klund/dev/gemfire3/open/geode-core/bin/main/org/ > > apache/geode/cache/query/internal/parse/OQLLexer.smap > > >> > > > >> > > > >> /Users/klund/dev/gemfire3/open/geode-core/bin/main/org/ > > apache/geode/cache/query/internal/parse/OQLParser.smap > > >> > > > >> > > > >> /Users/klund/dev/gemfire3/open/geode-core/bin/test/org/ > > apache/geode/management/internal/configuration/utils/ > > XmlUtilsAddNewNodeJUnitTest.testAddNewNodeNewNamed.xml > > >> > > > >> > > > >> /Users/klund/dev/gemfire3/open/geode-core/bin/test/org/ > > apache/geode/management/internal/configuration/utils/ > > XmlUtilsAddNewNodeJUnitTest.testAddNewNodeNewUnnamed.xml > > >> > > > >> > > > >> /Users/klund/dev/gemfire3/open/geode-core/bin/test/org/ > > apache/geode/management/internal/configuration/utils/ > > XmlUtilsAddNewNodeJUnitTest.testAddNewNodeNewUnnamedExtension.xml > > >> > > > >> > > > >> /Users/klund/dev/gemfire3/open/geode-core/bin/test/org/ > > apache/geode/management/internal/configuration/utils/ > > XmlUtilsAddNewNodeJUnitTest.testAddNewNodeReplaceNamed.xml > > >> > > > >> > > > >> /Users/klund/dev/gemfire3/open/geode-core/bin/test/org/ > > apache/geode/management/internal/configuration/utils/ > > XmlUtilsAddNewNodeJUnitTest.testAddNewNodeReplaceUnnamed.xml > > >> > > > >> > > > >> /Users/klund/dev/gemfire3/open/geode-core/bin/test/org/ > > apache/geode/management/internal/configuration/utils/ > > XmlUtilsAddNewNodeJUnitTest.testAddNewNodeReplaceUnnamedExtension.xml > > >> > > > >> > > > >> /Users/klund/dev/gemfire3/open/geode-core/bin/test/org/ > > apache/geode/management/internal/configuration/utils/ > > XmlUtilsAddNewNodeJUnitTest.testDeleteNodeNamed.xml > > >> > > > >> > > > >> /Users/klund/dev/gemfire3/open/geode-core/bin/test/org/ > > apache/geode/management/internal/configuration/utils/ > > XmlUtilsAddNewNodeJUnitTest.testDeleteNodeUnnamed.xml > > >> > > > >> > > > >> /Users/klund/dev/gemfire3/open/geode-core/bin/test/org/ > > apache/geode/management/internal/configuration/utils/ > > XmlUtilsAddNewNodeJUnitTest.testDeleteNodeUnnamedExtension.xml > > >> > > > >> > > > >> /Users/klund/dev/gemfire3/open/geode-core/bin/test/org/ > > apache/geode/management/internal/configuration/utils/ > > XmlUtilsAddNewNodeJUnitTest.xml > > >> > > > >> > > > >> /Users/klund/dev/gemfire3/open/geode-core/bin/test/org/ > > apache/geode/management/internal/configuration/utils/XmlUtilsJUnitTest. > > testBuildSchemaLocationMapAttribute.xml > > >> > > > >> > > > >> /Users/klund/dev/gemfire3/open/geode-core/bin/test/org/ > > apache/geode/management/internal/configuration/utils/XmlUtilsJUnitTest. > > testBuildSchemaLocationMapEmptyAttribute.xml > > >> > > > >> > > > >> /Users/klund/dev/gemfire3/open/geode-core/bin/test/org/ > > apache/geode/management/internal/configuration/utils/XmlUtilsJUnitTest. > > testBuildSchemaLocationMapNullAttribute.xml > > >> > > > >> > > > >> /Users/klund/dev/gemfire3/open/geode-core/bin/test/org/ > > apache/geode/management/internal/configuration/utils/XmlUtilsJUnitTest. > > testQuerySingleElement.xml > > >> > > >> > > >
Re: Rat is failing due to generated files under bin directories
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 wrote: > 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 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 at 7:02 PM Sai Boorlagadda < > > sai.boorlaga...@gmail.com > > > > > > > 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 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 build seems to create these bin directories under > each > > > >> module > > > >> > which is fine. > > > >> > > > > >> > But now Rat is failing because of the generated files under these > > bin > > > >> > directories. This in turn causes my local command-line build to > > fail. > > > >> > > > > >> > Does anyone know how to make this problem go away without using > "-x > > > >> rat"? > > > >> > > > > >> > Unapproved licenses: > > > >> > > > > >> > > > > >> > > > > >> /Users/klund/dev/gemfire3/open/extensions/geode-modules/ > > > bin/main/modules-version.properties > > > >> > > > > >> > > > > >> /Users/klund/dev/gemfire3/open/extensions/geode-modules/ > > > bin/test/org/apache/geode/modules/Event.hbm.xml > > > >> > > > > >> > > > > >> /Users/klund/dev/gemfire3/open/extensions/geode-modules/ > > > bin/test/org/apache/geode/modules/Person.hbm.xml > > > >> > > > > >> > > > > >> /Users/klund/dev/gemfire3/open/geode-core/bin/main/org/ > > > apache/geode/cache/query/internal/parse/OQLLexer.smap > > > >> > > > > >> > > > > >> /Users/klund/dev/gemfire3/open/geode-core/bin/main/org/ > > > apache/geode/cache/query/internal/parse/OQLParser.smap > > > >> > > > > >> > > > > >> /Users/klund/dev/gemfire3/open/geode-core/bin/test/org/ > > > apache/geode/management/internal/configuration/utils/ > > > XmlUtilsAddNewNodeJUnitTest.testAddNewNodeNewNamed.xml > > > >> > > > > >> > > > > >> /Users/klund/dev/gemfire3/open/geode-core/bin/test/org/ > > > apache/geode/management/internal/configuration/utils/ > > > XmlUtilsAddNewNodeJUnitTest.testAddNewNodeNewUnnamed.xml > > > >> > > > > >> > > > > >> /Users/klund/dev/gemfire3/open/geode-core/bin/test/org/ > > > apache/geode/management/internal/configuration/utils/ > > > XmlUtilsAddNewNodeJUnitTest.testAddNewNodeNewUnnamedExtension.xml > > > >> > > > > >> > > > > >> /Users/klund/dev/gemfire3/open/geode-core/bin/test/org/ > > > apache/geode/management/internal/configuration/utils/ > > > XmlUtilsAddNewNodeJUnitTest.testAddNewNodeReplaceNamed.xml > > > >> > > > > >> > > > > >> /Users/klund/dev/gemfire3/open/geode-core/bin/test/org/ > > > apache/geode/management/internal/configuration/utils/ > > > XmlUtilsAddNewNodeJUnitTest.testAddNewNodeReplaceUnnamed.xml > > > >> > > > > >> > > > > >> /Users/klund/dev/gemfire3/open/geode-core/bin/test/org/ > > > apache/geode/management/internal/configuration/utils/ > > > XmlUtilsAddNewNodeJUnitTest.testAddNewNodeReplaceUnnamedExtension.xml > > > >> > > > > >> > > > > >> /Users/klund/dev/gemfire3/open/geode-core/bin/test/org/ > > > apache/geode/management/internal/configuration/utils/ > > > XmlUtilsAddNewNodeJUnitTest.testDeleteNodeNamed.xml > > > >> > > > > >> > > > > >> /Users/klund/dev/gemfire3/open/geode-core/bin/test/org/ > > > apache/geode/management/internal/configuration/utils/ > > > XmlUtilsAddNewNodeJUnitTest.testDeleteNodeUnnamed.xml > > > >> > > > > >> > > > > >> /Users/klund/dev/gemfire3/open/geode-core/bin/test/org/ > > > apache/geode/management/internal/configuration/utils/ > > > XmlUtilsAddNewNodeJUnitTest.testDeleteNodeUnnamedExtension.xml > > > >> > > > > >> > > > > >> /Users/klund/dev/gemfire3/open/geode-core/bin/test/org/ > > > apache/geode/management/internal/configuration/utils/ > > > XmlUtilsAddNewNodeJUnitTest.xml > > > >> > > > > >> > > > > >> /Users/klund/dev/gemfire3/open/geode-core/bin/test/org/ > > > apache/geode/management/internal/configuration/utils/ > XmlUtilsJUnitTest. > > > testBuildSchemaLocationMapAttribute.xml > > > >> > > > > >> > > > > >> /Users/klund/dev/gemfire3/open/geode-core/bin/test/org/ > > > apache/geode/management/internal/configuration/utils/ > XmlUtilsJUnitTest. > > > testBuildSchemaLocationMapEmptyAttribute.xml > > > >> >
[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #1054 was SUCCESSFUL (with 2456 tests)
--- Spring Data GemFire > Nightly-ApacheGeode > #1054 was successful. --- Scheduled 2458 tests in total. https://build.spring.io/browse/SGF-NAG-1054/ -- This message is automatically generated by Atlassian Bamboo
Re: [Discuss] Transitive dependencies and internal .pom changes
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 list the *sufficient* list of dependencies per build.gradle. Patrick, you just mentioned the java-library plugin's ability to distinguish between api and implementation dependencies. Geode doesn't use that plugin yet AFAIK, nor does the PR introduce that plugin right? All this seems of a piece with the march toward modularity, exemplified by Java 9 modules. Patrick, is your vision something like: 1. accept this PR … 2. introduce the java-library plugin and segregate dependencies into api vs. implementation ones … N. define Java modules On Fri, Sep 28, 2018 at 10:39 AM Patrick Rhomberg wrote: > 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 elect to share > with our consumers, we should use `api`. > > For modularity, it should not break one module's ability to build for > another module to declare a `compile` configuration to be `implementation`, > unless of course that dependency is an active and necessary component part > of that module's consumption. In that case, it should be declared part of > the modules `api`. > In this vein and as Bill pointed out, a module should have an accurate > representation of its own build-time dependencies. > > In time, this will allow a much improved build experience, since > `implementation` and `api` are positioned for better granularity of > incremental building. > > On Fri, Sep 28, 2018 at 10:23 AM, Robert Houghton > wrote: > > > 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 documentation is here [ > > https://github.com/nebula-plugins/gradle-lint-plugin/ > > wiki/Unused-Dependency-Rule > > ] > > > > Thank you, > > -Robert Houghton > > > > On Fri, Sep 28, 2018 at 10:18 AM Bill Burcham > wrote: > > > > > 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 it ostensibly shows us > > all > > > the things that geode-connectors actually depends on. > > > > > > The challenge I see is two-fold: > > > > > > • as with Java imports and "unused imports", there is the risk of > listing > > > more dependencies than we actually need > > > • there's also the risk that we still don't have a complete list of > > > dependencies > > > > > > Patrick: do you have tool support for this? Is there a tool that can > > > identify or even remove unused dependencies? What process do you use > for > > > finding these heretofore hidden dependencies? Did you run gradle > > > app:dependencies? > > > > > >
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 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 roll an RC3, the correction will be > included. > > On Thu, Sep 27, 2018 at 7:13 PM, Nabarun Nag wrote: > > > Following checks completed: > > - checked signatures -src.tgz -examples.tgz -.tgz > > - checked SHA's -src.tgz -examples.tgz -.tgz > > - builds from source > > - run gfsh - start locator, server - create region - do put and get - > > execute OQL query > > - examples run cleanly > > - the correct version in gfsh command version > > - out scripts are now present in the source distribution > > -> ./ci/resource-types/gce-instances-resource/out > > -> ./ci/resource-types/concourse-metadata-resource/files/out > > > > Regrads > > Nabarun Nag > > > > > > On Thu, Sep 27, 2018 at 6:54 PM Nabarun Nag wrote: > > > > > This is the second release candidate for Apache Geode, version 1.7.0. > > > Thanks to all the community members for their contributions to this > > > release! > > > > > > Please do a review and give your feedback. The deadline is the end of > day > > > 2nd October 2018. > > > > > > It resolves 351 issues on Apache Geode JIRA system. Release notes can > be > > > found at: > > > https://cwiki.apache.org/confluence/display/GEODE/ > > > Release+Notes#ReleaseNotes-1.7.0 > > > > > > > > > Please note that we are voting upon the source tags: rel/v1.7.0.RC2 > > > Apache Geode: > > > https://github.com/apache/geode/tree/rel/v1.7.0.RC2 > > > Apache Geode examples: > > > https://github.com/apache/geode-examples/tree/rel/v1.7.0.RC2 > > > > > > Commit ID: > > > Apache Geode: > > > 48061cdcc293d42020b8695a5a23c4dd360550ff > > > Apache Geode Examples: > > > 9dca29c7c10fa8d44abc893271420476cfc0808f > > > > > > > > > Source and binary files: > > > https://dist.apache.org/repos/dist/dev/geode/1.7.0.RC2/ > > > > > > Maven staging repo: > > > https://repository.apache.org/content/repositories/orgapachegeode-1046 > > > > > > Geode's KEYS file containing PGP keys we use to sign the release: > > > https://github.com/apache/geode/blob/develop/KEYS > > > > > > Signed the release with fingerprint: > > > rsa4096 2018-01-04 [SC] [expires: 2022-01-04] > > > CE6CD0A89480B1B9FCB98699274C66710770C135 > > > > > > rsa4096 2018-01-04 [SC] [expires: 2022-01-04] > > > > > > I do apologize if there was an oversight. > > > > > > PS: Command to run geode-examples: ./gradlew -PgeodeReleaseUrl= > > > https://dist.apache.org/repos/dist/dev/geode/1.7.0.RC2 > > > -PgeodeRepositoryUrl= > > > https://repository.apache.org/content/repositories/orgapachegeode-1046 > > > build runAll > > > > > > Regards > > > Nabarun Nag > > > > > >
