I want reproducible builds. If dependency locking [1] works I would be open to
dynamic versions [2].
Anthony
[1] https://docs.gradle.org/current/userguide/dependency_locking.html
[2]
https://docs.gradle.org/current/userguide/declaring_dependencies.html#sub:declaring_dependency_with_dynamic_ver
Hello all!
I've been working here and there on making each Geode module's dependencies
explicit. Some previous discussion can be found in the archives [1].
My current question surrounds the structure of POMs in specifying version
information. Gradle supports `dependency constraints` to unify li
Cool - okay, I'm convinced
On 11/2/18 6:02 PM, John Blum wrote:
To make this example a bit more concrete for everyone else...
gfsh>start server --name=*Server1* --log-level=config
Starting a Geode Server in /Users/jblum/pivdev/lab/Server1...
Server in /Users/jblum/pivdev/lab/Server1 on
I'm logged into https://concourse.apachegeode-ci.info/ but I can't see
anything but the public pipeline. Can I please get permissions needed to
see and create a personal pipeline?
Thanks,
Kirk
I think we should try really hard to avoid using PowerMock. If you have
some code that you need to use PowerMock to make it testable, please
consider refactoring the code to a) avoid statics, b) pass all dependencies
in via the constructor.
The following was spit out by one of my unit test runs. N