[JBoss JIRA] (WFLY-594) TS: Add a module for shared util classes.
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-594?page=com.atlassian.jira.plugin.s... ]
Jason Greene moved AS7-2102 to WFLY-594:
----------------------------------------
Project: WildFly (was: Application Server 7)
Key: WFLY-594 (was: AS7-2102)
Component/s: (was: Test Suite)
> TS: Add a module for shared util classes.
> -----------------------------------------
>
> Key: WFLY-594
> URL: https://issues.jboss.org/browse/WFLY-594
> Project: WildFly
> Issue Type: Sub-task
> Reporter: Ondrej Zizka
> Assignee: Ondrej Zizka
>
> To prevent people coding their own impl of what was coded twenty-times in other packages of TS.
> There's already a package: `org.jboss.as.test.integration.common`
> It could be a module to keep it's dependencies separated.
> Perhaps also Apache Commons Util should be added as a dependency.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 8 months
[JBoss JIRA] (WFLY-595) TS: Review smoke tests
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-595?page=com.atlassian.jira.plugin.s... ]
Jason Greene moved AS7-2103 to WFLY-595:
----------------------------------------
Project: WildFly (was: Application Server 7)
Key: WFLY-595 (was: AS7-2103)
Component/s: (was: Test Suite)
Fix Version/s: (was: EAP 6.1.0.Alpha (7.2.0.Final))
> TS: Review smoke tests
> ----------------------
>
> Key: WFLY-595
> URL: https://issues.jboss.org/browse/WFLY-595
> Project: WildFly
> Issue Type: Sub-task
> Reporter: Ondrej Zizka
> Assignee: Ondrej Zizka
>
> Currently, smoke tests are in package .smoke.
> I'd rather see them in appropriate package,
> and differentiated by some grouping mechanism. See AS7-2086.
> Also:
> (02:07:46) stuartdouglas: but really, the smoke tests need review
> (02:08:03) stuartdouglas: to make sure they cover lots of different stuff in a general way
> (02:08:12) stuartdouglas: and also I would like to remove their dependency on the demo's
> (02:08:22) stuartdouglas: my thoughts where to just have them named SmokeTestCase
> Also, let's remove the "embedded" from package name.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 8 months
[JBoss JIRA] (WFLY-596) TS: Pick the most acceptable test packages organization
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-596?page=com.atlassian.jira.plugin.s... ]
Jason Greene moved AS7-2104 to WFLY-596:
----------------------------------------
Project: WildFly (was: Application Server 7)
Key: WFLY-596 (was: AS7-2104)
Component/s: (was: Test Suite)
> TS: Pick the most acceptable test packages organization
> -------------------------------------------------------
>
> Key: WFLY-596
> URL: https://issues.jboss.org/browse/WFLY-596
> Project: WildFly
> Issue Type: Sub-task
> Reporter: Ondrej Zizka
> Assignee: Ondrej Zizka
>
> 1) Split classes to src/main and src/test ?
> This seems to be decided before - integration tests suite has all classes in src/test.
> {quote}
> (02:35:15) barreiro: When I start I done it that way so that it clear to me what was the test code, the test subject and the resources --- I knew that probably I would have to change the location later.
> {quote}
> 2) Low-level Test packages micro
> {quote}
> (02:37:51) barreiro: should I create one sub package for each test --- like /web/xxxTestCase --- or stick with the old schema of having web/tests and web/servlets, ... etc.
> (02:38:01) ozizka: Not sure if democracy is the principle to follow here, but I'd like devs to agree upon these things. TBD next week
> (02:38:41) ozizka: Depends if you reuse them.
> (02:39:24) ozizka: But generally, I'd prefer the first approach -
> (02:39:53) ozizka: with reused things being placed one level higher, or next to
> (02:40:16) ozizka: The structure should reflect test's structure
> (02:40:24) barreiro: IMO, democracy is not the way to go in a OSS project :P ... I'll do it the way you ask me to ;)
> (02:40:34) ozizka: Ok :)
> (02:40:57) ozizka: But anyway - what's your preference?
> (02:41:07) ozizka: Or what would suite better for _your_ case
> (02:42:42) barreiro: the ultimate goal is that someone from outside can easily understand what's going on. Like me, I just landed in this project. :P
> (02:43:58) barreiro: surely that it should reflect the test's structure. but I would rather have a common structure in most modules ...
> (02:45:30) barreiro: like, at some level there is a clear list of the tests in the package that is not mixed with other stuff --- be it a list of packages or a test package with all the test classes
> (02:45:43) ozizka: Well, 1st option is current practice, I'd stick with that.
> (02:46:47) barreiro: and from there should be clear (as possible) what resources are used.
> (02:47:34) ozizka: I was thinking about using a mechanism used in Wicket framework, if you know that,
> (02:47:57) ozizka: which is, having a mechanism to load resources from places
> (02:48:04) barreiro: After a while I start to understand how AS6 is structured ... the problem is that there is too much voodoo in the back that defeats it's purpose.
> (02:48:18) ozizka: where the test class is loaded, or it's superclass, etc.
> (02:48:45) ozizka: Eventually it could go by packages up. But perhaps too magical for a testsuite
> (02:49:10) ozizka: Right. That's the voodoo.
> (02:56:27) barreiro: yep. Shrinkwrap and arquilling are great for that. The magic is greatly reduced, without adding much complexity.
> (02:58:10) ozizka: One other argument to have the package-per-test separation is that if we decided the other way, moving the files would be easier
> {quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 8 months
[JBoss JIRA] (WFLY-598) Alternative JDKs for building and running - OpenJDK 6, 7, Sun JDK 7, IcedTea
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-598?page=com.atlassian.jira.plugin.s... ]
Jason Greene moved AS7-2166 to WFLY-598:
----------------------------------------
Project: WildFly (was: Application Server 7)
Key: WFLY-598 (was: AS7-2166)
Component/s: (was: Test Suite)
Fix Version/s: (was: 7.1.2.Final (EAP))
> Alternative JDKs for building and running - OpenJDK 6, 7, Sun JDK 7, IcedTea
> ----------------------------------------------------------------------------
>
> Key: WFLY-598
> URL: https://issues.jboss.org/browse/WFLY-598
> Project: WildFly
> Issue Type: Sub-task
> Reporter: Ondrej Zizka
> Assignee: Ondrej Zizka
> Labels: eap6_prd_req
>
> James Perkins:
> {quote}
> At one point there was a JIRA for OpenJDK 6, in fact I think a couple. The issue with OpenJDK 6 is in the build we use some JavaScript and OpenJDK 6 doesn't come with a JavaScript engine. I tried a couple things to get Rhino working with it as that's what the Sun JDK uses, but I think it needs to implement an SPI to get it to work. I didn't look into it much beyond that.
> JDK 7 is a different issue. It's a bug in the annotation processing API which the JBoss Logging Tooling uses. I just refreshed my OpenJDK 7 update source and it looks like the bug is fixed in there. It's fixed in IcedTea as well. There could be the JavaScript issue here as well I can't actually remember, but I thought I had some successful builds with custom JDK's I compiled.
> I did just try with IcedTea 7 and got some other errors. I'm building the latest upstream of OpenJDK 7 now and we'll see if it works. I'll let you know either way.
> Let me know if you have any more questions on this. I did dig into a while ago a little.
> {quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 8 months
[JBoss JIRA] (WFLY-589) TS: Check clustering and compat and spec tests
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-589?page=com.atlassian.jira.plugin.s... ]
Jason Greene moved AS7-2062 to WFLY-589:
----------------------------------------
Project: WildFly (was: Application Server 7)
Key: WFLY-589 (was: AS7-2062)
Component/s: (was: Test Suite)
> TS: Check clustering and compat and spec tests
> ----------------------------------------------
>
> Key: WFLY-589
> URL: https://issues.jboss.org/browse/WFLY-589
> Project: WildFly
> Issue Type: Sub-task
> Reporter: Ondrej Zizka
> Assignee: Ondrej Zizka
>
> Stuart Douglas:
> 1) Clustering tests do not run, and as they require a different arquillian adaptor they must not be in the same maven module as other integration tests.
> 2) Compat tests do not run correctly. Even though they have a different hibernate version specified in the profile, when attempting to run alongside other tests the hibernate version will be overriden. Also as this modifies a build time dependency test classes need to be re-compiled each run, to make sure they are built against the correct hibernate version.
> I'll merge our changes into Stuart's branch since moving poms and scripts is easier than moving Clustering and Compat dirs back to their original location.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 8 months