I've closed out GEODE-327 and will create a new gemfire-common subproject
for GEODE-328. Please let me know if there's any further input on this.
Thanks,
Kirk
On Sat, Sep 12, 2015 at 4:47 PM, Anthony Baker wrote:
> Seems reasonable, as long as we tackle it piecewise. Going back to the
> origin
Seems reasonable, as long as we tackle it piecewise. Going back to the
original purpose, we need a home for @Experimental. We can put that in
gemfire-common and create a separate issue for gemfire-junit -> gemfire-test
and associated code movement.
Anthony
> On Sep 12, 2015, at 11:16 AM, Kir
+1
Jacob Barrett
Manager
GemFire Advanced Customer Engineering (ACE)
Pivotal
jbarr...@pivotal.io
503-533-3763
For immediate support please contact Pivotal Support at
http://support.pivotal.io/
On Sat, Sep 12, 2015 at 11:16 AM, Kirk Lund wrote:
> I'm pretty sure we could rename gemfire
I'm pretty sure we could rename gemfire-junit to gemfire-test.
gemfire-junit was named only because of gemfire-test existing in a
different repo.
Currently, all of our reusable testing utilities/classes/rules are under
src/test/java in either gemfire-junit or gemfire-core (dunit is all under
the l
Yes, I was originally envisioning creation of a src/main with:
src/main/java/com/gemstone/gemfire/annotations/Experimental.java
Currently, the purpose of gemfire-junit is to have zero dependencies on
other subprojects but provide (currently testing related only) annotations
and classes that are u
You don't want runtime libraries and test time libraries in the same jar.
Putting junit utility and annotation classes that would only be used in junits
in a jar that would have to be included in a production class path is broken.
Gemfire-common.jar would imply something common to gemfire at run
Can we have ‘src/main’ and ‘src/test’ in proposed gemfire-common and build a
gemfire-common-test.jar? So we can separate test utilities from common gemfire
utilities.
cloudfoundry/UAA…does it with a common-test.jar and other modules with in UAA
extend/use common test classes.
Sai
> On Sep 12
Annotations are utilities…? The gemfire-junit name seems unnecessarily
restrictive. Currently it only contains annotations related to junit tests.
Hadoop defines both hadoop-annotations and hadoop-common.
Anthony
> On Sep 11, 2015, at 9:08 PM, Jacob Barrett wrote:
>
> -1
>
>
>
>
> Rese
-1
Reserve common for things common to geode development not related to unit
testing. Like utilities classes.
Jacob Barrett
Manager
GemFire Advanced Customer Engineering (ACE)
Pivotal
jbarr...@pivotal.io
503-533-3763
For immediate support please contact Pivotal Support at
http://sup
+1
~/William
> On Sep 11, 2015, at 8:07 PM, Sai Boorlagadda wrote:
>
> +1
>
>> On Sep 11, 2015, at 7:52 PM, Anthony Baker wrote:
>>
>> +1
>>
>>> On Sep 11, 2015, at 12:04 PM, Kirk Lund wrote:
>>>
>>> I filed ticket GEODE-327 to propose renaming gemfire-junit to
>>> gemfire-common.
>>>
>
+1
> On Sep 11, 2015, at 7:52 PM, Anthony Baker wrote:
>
> +1
>
>> On Sep 11, 2015, at 12:04 PM, Kirk Lund wrote:
>>
>> I filed ticket GEODE-327 to propose renaming gemfire-junit to
>> gemfire-common.
>>
>> We'd like to be able to define common annotations in this gemfire-common
>> and not b
+1
> On Sep 11, 2015, at 12:04 PM, Kirk Lund wrote:
>
> I filed ticket GEODE-327 to propose renaming gemfire-junit to
> gemfire-common.
>
> We'd like to be able to define common annotations in this gemfire-common
> and not be limited to code that is specific to junit or testing. The first
> ann
I filed ticket GEODE-327 to propose renaming gemfire-junit to
gemfire-common.
We'd like to be able to define common annotations in this gemfire-common
and not be limited to code that is specific to junit or testing. The first
annotation would be Experimental (see GEODE-328).
Please vote on making
13 matches
Mail list logo
