Shane, Jason's correct, the main extrapolation point at the moment is pulling the container-boms I've created into a location that all modules can use, and expanding them to include the ones that Dan has put together.
Ken On Mon, Aug 8, 2011 at 7:33 PM, Jason Porter <[email protected]>wrote: > 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
