That would be my preference. As much as possible for versioning in seam-parent.
I did look closer at what Aslak posted. It looks like the underlying capabilities are based on a modification to surefire. The patch itself that he sent doesn't compile though. On Sun, Aug 21, 2011 at 7:42 AM, Shane Bryzak <[email protected]> wrote: > Hmm, actually what do you guys think about putting the profile > dependencies for these into seam-parent? It would certainly simplify > configuring tests across all the modules. > > > On 21/08/11 08:35, Shane Bryzak wrote: > > That might be one way we can do it - Ken, what do you think about > structuring the test suite like this? > > https://gist.github.com/1155271 > > > On 21/08/11 08:27, Jason Porter wrote: > > Maybe something in surefire, or what aslak said on twitter may be helpful. > > Sent from my iPhone > > On Aug 20, 2011, at 16:21, Shane Bryzak <[email protected]> wrote: > > I'm currently looking into it. > > On 21/08/11 08:04, Jason Porter wrote: > > Is it possible to add a source directory or test directory? > > Sent from my iPhone > > On Aug 20, 2011, at 15:36, Shane Bryzak <[email protected]> wrote: > > Unfortunately that doesn't work - the issue occurs when the artifacts > being unpacked are in the same reactor. See > http://jira.codehaus.org/browse/MDEP-98 > > On 21/08/11 01:11, Ken Finnigan wrote: > > If I'm not mistaken, that error is resolved by installing the artifacts. > > The problem is that it doesn't know how to unpack a directory, so the jar > with the test classes needs to be installed for it to work > > Ken > > Sent from my iPhone > > On Aug 20, 2011, at 11:02, Shane Bryzak <[email protected]> wrote: > > I've made some progress in this area, so far I've created a few of the > container boms in seam-parent and also started converting the Solder tests > to use the new structure. > > I have run into one issue though - when running the tests I'm encountering > the error below. The reason it hasn't manifested in the International > module is because there was a version mismatch between some of the test > suite artifacts, however if you synchronize them all you get the same error. > > [INFO] Reactor Summary: > [INFO] > [INFO] Seam International Test Suite: Aggregator ......... SUCCESS [1.224s] > [INFO] Seam Container BOMs Aggregator .................... SUCCESS [0.025s] > [INFO] Weld EE Embedded 1.1 Container .................... SUCCESS [0.899s] > [INFO] JBoss AS7 Managed Container ....................... SUCCESS [2.722s] > [INFO] Seam International Test Suite Common .............. SUCCESS [0.376s] > [INFO] Seam International Test Suite: Internals Integration Tests SUCCESS > [0.013s] > [INFO] Seam International Test Suite: Internals Integration Tests Base > SUCCESS [0.743s] > [INFO] Seam International Test Suite: Internals Integration Tests for JBoss > AS FAILURE [2.529s] > [INFO] Seam International Test Suite: Internals Integration Tests for Weld > EE Embedded SKIPPED > [INFO] > ------------------------------------------------------------------------ > [INFO] BUILD FAILURE > [INFO] > ------------------------------------------------------------------------ > [INFO] Total time: 9.393s > [INFO] Finished at: Sun Aug 21 00:55:38 EST 2011 > [INFO] Final Memory: 25M/348M > [INFO] > ------------------------------------------------------------------------ > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-dependency-plugin:2.1:unpack > (unpack-base-tests) on project > seam-international-testsuite-integration-internals-jbossas: Error unpacking > file: > /home/shane/project/seam/international/testsuite/internals/base/target/classes > to: > /home/shane/project/seam/international/testsuite/internals/jbossas/target/test-classes > [ERROR] org.codehaus.plexus.archiver.ArchiverException: The source must not > be a directory. > [ERROR] -> [Help 1] > > > I've spent a little time trying to find a workaround but it seems that this > has been a known bug in Maven for at least 4 years. If anyone wants to take > a look at this and try to figure out a workaround in the meantime please be > my guest. > > Shane > > > 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 > > > > > > _______________________________________________ > 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 > >
_______________________________________________ seam-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/seam-dev
