How "optional" should the NoSQL integration be for WildFly...

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

How "optional" should the NoSQL integration be for WildFly...

Scott Marlow
Hi,

I'm thinking that the NoSQL unit tests should be optional, since most
WildFly developers won't have access to a local NoSQL database server.
Currently, to run the unit tests, you have to define "nosql-tests" (e.g.
./integration-tests.sh -Dnosql-tests).

As we work towards our first (NoSQL integration) pull requests for
WildFly master (and some small wildfly-core changes to the Phase class),
does anything else need to be optional?

Currently we are building WildFly to include the NoSQL driver artifacts,
for the specific versions of the drivers that we support.  We also allow
other versions of the NoSQL drivers to be brought into WildFly, as long
as they are (API) compatible with the version that we (loosely)
integrate with.

Thanks for the feedback!

Scott
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: How "optional" should the NoSQL integration be for WildFly...

Brian Stansberry

> On Sep 12, 2016, at 9:31 AM, Scott Marlow <[hidden email]> wrote:
>
> Hi,
>
> I'm thinking that the NoSQL unit tests should be optional, since most
> WildFly developers won't have access to a local NoSQL database server.
> Currently, to run the unit tests, you have to define "nosql-tests" (e.g.
> ./integration-tests.sh -Dnosql-tests).
>

The standard pattern for this kind of switch is something like

-Dts.nosql

So please stick with that pattern.

How does this related to -DallTests, which right now turns on all tests except the mixed domain ones.

That “allTests” is an unfortunate name as it’s not all any more, but it’s widely known and used as the simple way to execute the vast bulk of the testsuite.

> As we work towards our first (NoSQL integration) pull requests for
> WildFly master (and some small wildfly-core changes to the Phase class),
> does anything else need to be optional?
>
> Currently we are building WildFly to include the NoSQL driver artifacts,
> for the specific versions of the drivers that we support.  We also allow
> other versions of the NoSQL drivers to be brought into WildFly, as long
> as they are (API) compatible with the version that we (loosely)
> integrate with.
>
> Thanks for the feedback!
>
> Scott
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

--
Brian Stansberry
Manager, Senior Principal Software Engineer
JBoss by Red Hat




_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: How "optional" should the NoSQL integration be for WildFly...

Scott Marlow


On 09/12/2016 11:00 AM, Brian Stansberry wrote:

>
>> On Sep 12, 2016, at 9:31 AM, Scott Marlow <[hidden email]> wrote:
>>
>> Hi,
>>
>> I'm thinking that the NoSQL unit tests should be optional, since most
>> WildFly developers won't have access to a local NoSQL database server.
>> Currently, to run the unit tests, you have to define "nosql-tests" (e.g.
>> ./integration-tests.sh -Dnosql-tests).
>>
>
> The standard pattern for this kind of switch is something like
>
> -Dts.nosql

Thanks, we will switch over to -Dts.nosql

>
> So please stick with that pattern.
>
> How does this related to -DallTests, which right now turns on all tests except the mixed domain ones.

I don't think -DallTests should include the NoSQL tests, since many
developers will not have (local) access to all of the NoSQL databases.

I did a -DallTests run and the NoSQL tests were included.

>
> That “allTests” is an unfortunate name as it’s not all any more, but it’s widely known and used as the simple way to execute the vast bulk of the testsuite.
>
>> As we work towards our first (NoSQL integration) pull requests for
>> WildFly master (and some small wildfly-core changes to the Phase class),
>> does anything else need to be optional?
>>
>> Currently we are building WildFly to include the NoSQL driver artifacts,
>> for the specific versions of the drivers that we support.  We also allow
>> other versions of the NoSQL drivers to be brought into WildFly, as long
>> as they are (API) compatible with the version that we (loosely)
>> integrate with.
>>
>> Thanks for the feedback!
>>
>> Scott
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: How "optional" should the NoSQL integration be for WildFly...

Brian Stansberry

> On Sep 12, 2016, at 11:42 AM, Scott Marlow <[hidden email]> wrote:
>
>
>
> On 09/12/2016 11:00 AM, Brian Stansberry wrote:
>>
>>> On Sep 12, 2016, at 9:31 AM, Scott Marlow <[hidden email]> wrote:
>>>
>>> Hi,
>>>
>>> I'm thinking that the NoSQL unit tests should be optional, since most
>>> WildFly developers won't have access to a local NoSQL database server.
>>> Currently, to run the unit tests, you have to define "nosql-tests" (e.g.
>>> ./integration-tests.sh -Dnosql-tests).
>>>
>>
>> The standard pattern for this kind of switch is something like
>>
>> -Dts.nosql
>
> Thanks, we will switch over to -Dts.nosql
>
>>
>> So please stick with that pattern.
>>
>> How does this related to -DallTests, which right now turns on all tests except the mixed domain ones.
>
> I don't think -DallTests should include the NoSQL tests, since many developers will not have (local) access to all of the NoSQL databases.
>
> I did a -DallTests run and the NoSQL tests were included.

Ok, some pom wizardry will be needed to avoid that. The testsuite/mixed-domain module isn’t run via -DallTests so looking at the setup of that one my lead you to the magic potion. Or someone reading this can tell you. ;)

Is there any property that defines how to have "(local) access to all of the NoSQL databases”?

I ask because in the case of testsuite/mixed domain, there is — a property that tells the testsuite the dir to look in to find zips of previous releases. So then we just used that property to control whether the maven profile for that part of the suite is enabled and killed 2 birds with one stone. There’s no -Dts.mixed-domain involved as that would just have been an extra thing to set.

>
>>
>> That “allTests” is an unfortunate name as it’s not all any more, but it’s widely known and used as the simple way to execute the vast bulk of the testsuite.
>>
>>> As we work towards our first (NoSQL integration) pull requests for
>>> WildFly master (and some small wildfly-core changes to the Phase class),
>>> does anything else need to be optional?
>>>
>>> Currently we are building WildFly to include the NoSQL driver artifacts,
>>> for the specific versions of the drivers that we support.  We also allow
>>> other versions of the NoSQL drivers to be brought into WildFly, as long
>>> as they are (API) compatible with the version that we (loosely)
>>> integrate with.
>>>
>>> Thanks for the feedback!
>>>
>>> Scott
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>

--
Brian Stansberry
Manager, Senior Principal Software Engineer
JBoss by Red Hat




_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: How "optional" should the NoSQL integration be for WildFly...

kkhan

> On 12 Sep 2016, at 17:52, Brian Stansberry <[hidden email]> wrote:
>
>
>> On Sep 12, 2016, at 11:42 AM, Scott Marlow <[hidden email]> wrote:
>>
>>
>>
>> On 09/12/2016 11:00 AM, Brian Stansberry wrote:
>>>
>>>> On Sep 12, 2016, at 9:31 AM, Scott Marlow <[hidden email]> wrote:
>>>>
>>>> Hi,
>>>>
>>>> I'm thinking that the NoSQL unit tests should be optional, since most
>>>> WildFly developers won't have access to a local NoSQL database server.
>>>> Currently, to run the unit tests, you have to define "nosql-tests" (e.g.
>>>> ./integration-tests.sh -Dnosql-tests).
>>>>
>>>
>>> The standard pattern for this kind of switch is something like
>>>
>>> -Dts.nosql
>>
>> Thanks, we will switch over to -Dts.nosql
>>
>>>
>>> So please stick with that pattern.
>>>
>>> How does this related to -DallTests, which right now turns on all tests except the mixed domain ones.
>>
>> I don't think -DallTests should include the NoSQL tests, since many developers will not have (local) access to all of the NoSQL databases.
>>
>> I did a -DallTests run and the NoSQL tests were included.
>
> Ok, some pom wizardry will be needed to avoid that. The testsuite/mixed-domain module isn’t run via -DallTests so looking at the setup of that one my lead you to the magic potion. Or someone reading this can tell you. ;)


To run these tests you need to have set up a folder containing old AS release zips. This is specified by passing in -Djboss.test.mixed.domain.dir=/path/to/the/old/releases/folder

The jboss.test.mixed.domain.dir property servers two purposes:
- tells testsuite/mixed-domain where to find the directory containing the zips
- in testsuite/pom.xml (i.e. mixed-domain's parent) the presence of this property will activate the profile which includes the mixed-domain child module, from testsuite/pom.xml:

<profile>
    <id>mixed-domain.module.profile</id>
    <activation><property><name>jboss.test.mixed.domain.dir</name></property></activation>
    <modules>
        <module>mixed-domain</module>
    </modules>
</profile>


>
> Is there any property that defines how to have "(local) access to all of the NoSQL databases”?
>
> I ask because in the case of testsuite/mixed domain, there is — a property that tells the testsuite the dir to look in to find zips of previous releases. So then we just used that property to control whether the maven profile for that part of the suite is enabled and killed 2 birds with one stone. There’s no -Dts.mixed-domain involved as that would just have been an extra thing to set.
>
>>
>>>
>>> That “allTests” is an unfortunate name as it’s not all any more, but it’s widely known and used as the simple way to execute the vast bulk of the testsuite.
>>>
>>>> As we work towards our first (NoSQL integration) pull requests for
>>>> WildFly master (and some small wildfly-core changes to the Phase class),
>>>> does anything else need to be optional?
>>>>
>>>> Currently we are building WildFly to include the NoSQL driver artifacts,
>>>> for the specific versions of the drivers that we support.  We also allow
>>>> other versions of the NoSQL drivers to be brought into WildFly, as long
>>>> as they are (API) compatible with the version that we (loosely)
>>>> integrate with.
>>>>
>>>> Thanks for the feedback!
>>>>
>>>> Scott
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>
> --
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> JBoss by Red Hat
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: How "optional" should the NoSQL integration be for WildFly...

Anil Saldanha
Kabir - hi.  

Should this info be put on a wiki page for Wildfly community for test instructions? :-)

> On Sep 13, 2016, at 4:35 AM, Kabir Khan <[hidden email]> wrote:
>
>
>> On 12 Sep 2016, at 17:52, Brian Stansberry <[hidden email]> wrote:
>>
>>
>>> On Sep 12, 2016, at 11:42 AM, Scott Marlow <[hidden email]> wrote:
>>>
>>>
>>>
>>>> On 09/12/2016 11:00 AM, Brian Stansberry wrote:
>>>>
>>>>> On Sep 12, 2016, at 9:31 AM, Scott Marlow <[hidden email]> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I'm thinking that the NoSQL unit tests should be optional, since most
>>>>> WildFly developers won't have access to a local NoSQL database server.
>>>>> Currently, to run the unit tests, you have to define "nosql-tests" (e.g.
>>>>> ./integration-tests.sh -Dnosql-tests).
>>>>
>>>> The standard pattern for this kind of switch is something like
>>>>
>>>> -Dts.nosql
>>>
>>> Thanks, we will switch over to -Dts.nosql
>>>
>>>>
>>>> So please stick with that pattern.
>>>>
>>>> How does this related to -DallTests, which right now turns on all tests except the mixed domain ones.
>>>
>>> I don't think -DallTests should include the NoSQL tests, since many developers will not have (local) access to all of the NoSQL databases.
>>>
>>> I did a -DallTests run and the NoSQL tests were included.
>>
>> Ok, some pom wizardry will be needed to avoid that. The testsuite/mixed-domain module isn’t run via -DallTests so looking at the setup of that one my lead you to the magic potion. Or someone reading this can tell you. ;)
>
>
> To run these tests you need to have set up a folder containing old AS release zips. This is specified by passing in -Djboss.test.mixed.domain.dir=/path/to/the/old/releases/folder
>
> The jboss.test.mixed.domain.dir property servers two purposes:
> - tells testsuite/mixed-domain where to find the directory containing the zips
> - in testsuite/pom.xml (i.e. mixed-domain's parent) the presence of this property will activate the profile which includes the mixed-domain child module, from testsuite/pom.xml:
>
> <profile>
>    <id>mixed-domain.module.profile</id>
>    <activation><property><name>jboss.test.mixed.domain.dir</name></property></activation>
>    <modules>
>        <module>mixed-domain</module>
>    </modules>
> </profile>
>
>
>>
>> Is there any property that defines how to have "(local) access to all of the NoSQL databases”?
>>
>> I ask because in the case of testsuite/mixed domain, there is — a property that tells the testsuite the dir to look in to find zips of previous releases. So then we just used that property to control whether the maven profile for that part of the suite is enabled and killed 2 birds with one stone. There’s no -Dts.mixed-domain involved as that would just have been an extra thing to set.
>>
>>>
>>>>
>>>> That “allTests” is an unfortunate name as it’s not all any more, but it’s widely known and used as the simple way to execute the vast bulk of the testsuite.
>>>>
>>>>> As we work towards our first (NoSQL integration) pull requests for
>>>>> WildFly master (and some small wildfly-core changes to the Phase class),
>>>>> does anything else need to be optional?
>>>>>
>>>>> Currently we are building WildFly to include the NoSQL driver artifacts,
>>>>> for the specific versions of the drivers that we support.  We also allow
>>>>> other versions of the NoSQL drivers to be brought into WildFly, as long
>>>>> as they are (API) compatible with the version that we (loosely)
>>>>> integrate with.
>>>>>
>>>>> Thanks for the feedback!
>>>>>
>>>>> Scott
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> [hidden email]
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>> --
>> Brian Stansberry
>> Manager, Senior Principal Software Engineer
>> JBoss by Red Hat
>>
>>
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: How "optional" should the NoSQL integration be for WildFly...

Emmanuel Hugonnet
Hi,
I've added a README.md for this part of the test suite on my PR https://github.com/wildfly/wildfly/pull/9063
Can't wait for it to be merged ;)
Emmanuel


Le 13/09/2016 à 13:17, Anil Saldanha a écrit :

> Kabir - hi.  
>
> Should this info be put on a wiki page for Wildfly community for test instructions? :-)
>
>> On Sep 13, 2016, at 4:35 AM, Kabir Khan <[hidden email]> wrote:
>>
>>
>>> On 12 Sep 2016, at 17:52, Brian Stansberry <[hidden email]> wrote:
>>>
>>>
>>>> On Sep 12, 2016, at 11:42 AM, Scott Marlow <[hidden email]> wrote:
>>>>
>>>>
>>>>
>>>>> On 09/12/2016 11:00 AM, Brian Stansberry wrote:
>>>>>
>>>>>> On Sep 12, 2016, at 9:31 AM, Scott Marlow <[hidden email]> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I'm thinking that the NoSQL unit tests should be optional, since most
>>>>>> WildFly developers won't have access to a local NoSQL database server.
>>>>>> Currently, to run the unit tests, you have to define "nosql-tests" (e.g.
>>>>>> ./integration-tests.sh -Dnosql-tests).
>>>>>
>>>>> The standard pattern for this kind of switch is something like
>>>>>
>>>>> -Dts.nosql
>>>>
>>>> Thanks, we will switch over to -Dts.nosql
>>>>
>>>>>
>>>>> So please stick with that pattern.
>>>>>
>>>>> How does this related to -DallTests, which right now turns on all tests except the mixed domain ones.
>>>>
>>>> I don't think -DallTests should include the NoSQL tests, since many developers will not have (local) access to all of the NoSQL databases.
>>>>
>>>> I did a -DallTests run and the NoSQL tests were included.
>>>
>>> Ok, some pom wizardry will be needed to avoid that. The testsuite/mixed-domain module isn’t run via -DallTests so looking at the setup of that one my lead you to the magic potion. Or someone reading this can tell you. ;)
>>
>>
>> To run these tests you need to have set up a folder containing old AS release zips. This is specified by passing in -Djboss.test.mixed.domain.dir=/path/to/the/old/releases/folder
>>
>> The jboss.test.mixed.domain.dir property servers two purposes:
>> - tells testsuite/mixed-domain where to find the directory containing the zips
>> - in testsuite/pom.xml (i.e. mixed-domain's parent) the presence of this property will activate the profile which includes the mixed-domain child module, from testsuite/pom.xml:
>>
>> <profile>
>>    <id>mixed-domain.module.profile</id>
>>    <activation><property><name>jboss.test.mixed.domain.dir</name></property></activation>
>>    <modules>
>>        <module>mixed-domain</module>
>>    </modules>
>> </profile>
>>
>>
>>>
>>> Is there any property that defines how to have "(local) access to all of the NoSQL databases”?
>>>
>>> I ask because in the case of testsuite/mixed domain, there is — a property that tells the testsuite the dir to look in to find zips of previous releases. So then we just used that property to control whether the maven profile for that part of the suite is enabled and killed 2 birds with one stone. There’s no -Dts.mixed-domain involved as that would just have been an extra thing to set.
>>>
>>>>
>>>>>
>>>>> That “allTests” is an unfortunate name as it’s not all any more, but it’s widely known and used as the simple way to execute the vast bulk of the testsuite.
>>>>>
>>>>>> As we work towards our first (NoSQL integration) pull requests for
>>>>>> WildFly master (and some small wildfly-core changes to the Phase class),
>>>>>> does anything else need to be optional?
>>>>>>
>>>>>> Currently we are building WildFly to include the NoSQL driver artifacts,
>>>>>> for the specific versions of the drivers that we support.  We also allow
>>>>>> other versions of the NoSQL drivers to be brought into WildFly, as long
>>>>>> as they are (API) compatible with the version that we (loosely)
>>>>>> integrate with.
>>>>>>
>>>>>> Thanks for the feedback!
>>>>>>
>>>>>> Scott
>>>>>> _______________________________________________
>>>>>> wildfly-dev mailing list
>>>>>> [hidden email]
>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>> --
>>> Brian Stansberry
>>> Manager, Senior Principal Software Engineer
>>> JBoss by Red Hat
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

signature.asc (484 bytes) Download Attachment