[JBoss JIRA] (WFLY-629) TS: Find a way to retain same value of property with ${basedir} in submodules.
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-629?page=com.atlassian.jira.plugin.s... ]
Jason Greene moved AS7-3122 to WFLY-629:
----------------------------------------
Project: WildFly (was: Application Server 7)
Key: WFLY-629 (was: AS7-3122)
Component/s: (was: Test Suite)
> TS: Find a way to retain same value of property with ${basedir} in submodules.
> ------------------------------------------------------------------------------
>
> Key: WFLY-629
> URL: https://issues.jboss.org/browse/WFLY-629
> Project: WildFly
> Issue Type: Sub-task
> Reporter: Ondrej Zizka
> Assignee: Ondrej Zizka
>
> John Casey:
> {quote}
> Can you explain exactly how the ${basedir} property will be used? This matters, because expression resolution happens two different ways, once for POM interpolation and again for plugin parameter injection. For more information on the differences, you can play with an expression plugin I built: http://github.com/jdcasey/expression-maven-plugin (see the README for information on using it).
> {quote}
> We need to refer to ${basedir} for two purposes:
> 1) To be able to pass important directories to the tests, for example:
> * AS project root dir
> * Testsuite root dir (to access global resources)
> * Integration testsuite root dir (to access int. ts. resources)
> In this case, we need to be able to define the value in parent pom and retain it for sub-modules.
> 2) For various operations (plugin executions) which are defined in parent pom, but inherited in sub-modules.
> In this case, we really need to have it done using relative paths, e.g. ${basedir}/src/config/arquillian .
> In both cases, ${basedir} is used for plugins configuration.
> John Casey:
> {quote}
> I've written a plugin called org.commonjava.maven.plugins:directory-maven-plugin that has goals:
> * execution-root = Resolves to the directory where maven was invoked
> * directory-of = uses a <project/> configuration with groupId and artifactId to find another project in the current session, and returns its basedir
> * highest-basedir = traverses the parent hierarchies of all current projects, up until it finds a parent that has been resolved instead of loaded locally. Then, it sorts these basedir paths and returns the one closest to the filesystem root. If the top two hits (highest results) are not nested within one another, it will fail.
> I'd expect you to use something like these to pin down a particular project basedir reference, and inject it consistently into each project in the session. It may be that you actually need something like a combination of the last two, to reference a particular parent project that was loaded from disk (but may not be in the current session per se). If so, that's another easy one to write.
> The plugin is here:
> http://github.com/jdcasey/directory-maven-plugin
> You can take a look at the README.md for more information.
> {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-631) TS: Make commons-lang3, commons-io and commons-codec available in tests.
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-631?page=com.atlassian.jira.plugin.s... ]
Jason Greene moved AS7-3306 to WFLY-631:
----------------------------------------
Project: WildFly (was: Application Server 7)
Key: WFLY-631 (was: AS7-3306)
Affects Version/s: (was: 7.1.0.CR1b)
Component/s: (was: Test Suite)
> TS: Make commons-lang3, commons-io and commons-codec available in tests.
> ------------------------------------------------------------------------
>
> Key: WFLY-631
> URL: https://issues.jboss.org/browse/WFLY-631
> Project: WildFly
> Issue Type: Sub-task
> Reporter: Ondrej Zizka
> Assignee: Ondrej Zizka
>
> To relieve people from writing methods like toHex(), defaultIfNull() and escapeHtml(),
> I'd like to add commons-lang3, commons-io and commons-codec.
> These are de-facto standard, well tested, mostly thread-safe.
> For tests running in server, these would still need to be packaged into the deployment.
--
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-630) TS: Check endorsed jboss-annotations-api.
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-630?page=com.atlassian.jira.plugin.s... ]
Jason Greene moved AS7-3123 to WFLY-630:
----------------------------------------
Project: WildFly (was: Application Server 7)
Key: WFLY-630 (was: AS7-3123)
Component/s: (was: Test Suite)
Fix Version/s: (was: Awaiting Volunteers)
> TS: Check endorsed jboss-annotations-api.
> -----------------------------------------
>
> Key: WFLY-630
> URL: https://issues.jboss.org/browse/WFLY-630
> Project: WildFly
> Issue Type: Sub-task
> Reporter: Ondrej Zizka
> Assignee: Ondrej Zizka
>
> (22.12.2011 04:09:13) ozizka: Speaking of hacks, how about jboss-annotations-api_1.1_spec being set as endorsed during testsuite compilation
> (04:09:25) ozizka: The comment says "Big complex hack just to get @Resource(lookup="foo")."
> (04:09:34) ozizka: Is that stil needed?
> (04:37:14) bstansberry: I don't know. I never really knew what that was all about
> (04:37:39) bstansberry: i doubt it's needed, just because it sounds so weird and dates so far back
> (04:38:12) bstansberry: oh, i can guess what it's about
> (04:38:50) bstansberry: wacky Sun/Oracle have the same class in both SE and EE but with extra members in EE
> (04:39:20) bstansberry: "lookup" isn't in @Resource in SE
--
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-623) TS: Configurable timeouts
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-623?page=com.atlassian.jira.plugin.s... ]
Jason Greene moved AS7-2827 to WFLY-623:
----------------------------------------
Project: WildFly (was: Application Server 7)
Key: WFLY-623 (was: AS7-2827)
Component/s: (was: Test Suite)
Fix Version/s: (was: 7.1.1.Final)
> TS: Configurable timeouts
> -------------------------
>
> Key: WFLY-623
> URL: https://issues.jboss.org/browse/WFLY-623
> Project: WildFly
> Issue Type: Sub-task
> Reporter: Ondrej Zizka
> Assignee: Ondrej Zizka
>
> Testsuite run can take different amount of time on various HW (or virtuals).
> All timeouts must be configurable, in the sense of being possible to prolong.
> We should also divide them into categories, depending on what is expected to take long (consider slow disks, slow networks, cloud environment)
> Few ideas for categories:
> * Filesystem I/O
> * Processor
> * Network I/O
> * Memory I/O
> * Database operations
> For each category, there would be a ratio, 1.0 by default, which would multiply the timeout.
> So the timeout would look like:
> {code}
> something.setTimeout( 1000 * Timeouts.getFSIORatio() );
> {code}
> Other possibility is to use @Annotations to mark tests belonging to certain group, like @LongRunning or such.
--
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-621) TS: Implement self-test.
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-621?page=com.atlassian.jira.plugin.s... ]
Jason Greene moved AS7-2807 to WFLY-621:
----------------------------------------
Project: WildFly (was: Application Server 7)
Key: WFLY-621 (was: AS7-2807)
Component/s: (was: Test Suite)
Fix Version/s: (was: 7.1.0.Final)
> TS: Implement self-test.
> ------------------------
>
> Key: WFLY-621
> URL: https://issues.jboss.org/browse/WFLY-621
> Project: WildFly
> Issue Type: Sub-task
> Reporter: Ondrej Zizka
> Assignee: Ondrej Zizka
> Original Estimate: 4 days
> Remaining Estimate: 4 days
>
> Implement a script which would verify the health of the testsuite - i.e.:
> * Run scripts with various params & check the results
> * Run mvn with various params & check the results
> By results, we mean:
> * Same set of tests run
> * Same results as before
> * AS is configured the same way (if not intentionally changed)
--
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