The container boms should be pulled in. Anything else would be be a bit of a headache to maintain and make generic enough for everyone to use.
On Mon, Aug 8, 2011 at 17:28, Shane Bryzak <[email protected]> wrote: > Ken, I'd like this to be adopted as the standard for all modules. Which > common dependencies do you think we should put in seam-parent to make it > easier for them? > > On 30/07/11 12:16, Ken Finnigan wrote: > > All, > > I've committed the work on the Arquillian testsuite infrastructure on the > i18n module which can be found here: > https://github.com/seam/international/tree/develop/testsuite > > Here are some notes on how it's structured and what needs to be done: > > > - API and Impl modules still retain unit tests that don't require > container testing > - testsuite/common includes Deployment and Library helpers and anything > that would be common to multiple types of testsuites, such as internals, > smoke, etc > - The helpers from this module could potentially be pulled up into a > common module for all, but that may introduce complexity in trying to > use it > in each module so may be best to leave it there for the moment and see > how > it goes > - testsuite/container-boms contains the container definition for weld > ee embedded and AS7. Others can be found at > > https://github.com/mojavelinux/arquillian-showcase/tree/master/container-boms > - One of the first things that needs to happen is these > container-boms need to be created in a seam parent module of some kind > such > that each module can utilize them without having to replicate the > content > directly > - testsuite/internals/base contains the test classes that used to be > within impl. For i18n I was able to leave the entirety of the test classes > in the bases module and simply explode it into the target/test-classes > directory of the testsuite/internals/${container} modules as part of the > integration-test phase. > - To make it easier to then explode the jar built from this module > into sub modules, the test classes and resources actually need to be in > src/main. As we don't plan using the jar built from this for anything > other > than testing it's not an issue. > - container tests are only activated on the integration-test phase > and skipped on the basic test phase > - > > https://github.com/seam/international/blob/develop/testsuite/README.mdoutlines > all the proposed types of suites that testsuite can contain. I > believe an initial first step should be to move the existing container > tests, or create some, for the internals module. Over time we can then > look > to flesh out the testsuite with additional types such as smoke, cluster, > api, etc > - One area that I haven't looked at yet is code coverage given that the > tests are further spread than previously. I'm hoping that it will be > relatively easy to amalgamate all the coverage data to produce a single > report. > > Any questions about this please let me know. > > Ken > > > _______________________________________________ > seam-dev mailing > [email protected]https://lists.jboss.org/mailman/listinfo/seam-dev > > > > _______________________________________________ > seam-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/seam-dev > > -- Jason Porter http://lightguard-jp.blogspot.com http://twitter.com/lightguardjp Software Engineer Open Source Advocate Author of Seam Catch - Next Generation Java Exception Handling PGP key id: 926CCFF5 PGP key available at: keyserver.net, pgp.mit.edu
_______________________________________________ seam-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/seam-dev
