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 <lightguard.jp(a)gmail.com>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 <sbryzak(a)redhat.com> 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-...
> - 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.mdout... 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
listseam-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/seam-dev
>
>
>
> _______________________________________________
> seam-dev mailing list
> seam-dev(a)lists.jboss.org
>
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