I'm just experimenting with this configuration now in Solder, however I'm getting the following exception when I run the tests - anyone seen this before? Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.244 sec <<< FAILURE!

Time elapsed: 0.004 sec <<< ERROR! java.lang.NoClassDefFoundError: org/jboss/shrinkwrap/descriptor/api/Node at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:2389) at java.lang.Class.getConstructor0(Class.java:2699) at java.lang.Class.getConstructor(Class.java:1657) at

at

On 21/08/11 09:18, John D. Ament wrote: > > I am willing to convert seam JCR to this to see how it runs. > > John > > On Aug 20, 2011 7:17 PM, "George Gastaldi" <gegastaldi(a)gmail.com > <mailto:gegastaldi@gmail.com>> wrote: > > +1 to the multiple sources idea > > > > Em 20/08/2011, às 20:01, Shane Bryzak <sbryzak(a)redhat.com > <mailto:sbryzak@redhat.com>> escreveu: > > > > We could possibly do it by specifying additional source directories > for each > > profile. > > > > >

> > > > On 21/08/11 08:59, Jason Porter wrote: > > > > Can we add additional tests with this though for each container? > > > > Sent from my iPhone > > > > On Aug 20, 2011, at 16:35, Shane Bryzak <sbryzak(a)redhat.com > <mailto:sbryzak@redhat.com>> 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 <sbryzak(a)redhat.com > <mailto:sbryzak@redhat.com>> 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 <sbryzak(a)redhat.com > <mailto:sbryzak@redhat.com>> 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

> > > > 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 <sbryzak(a)redhat.com > <mailto:sbryzak@redhat.com>> 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: > > >

> > to: > > >

> > [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

> > 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

> > embedded and AS7. Others can be found at > > >

> > - 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

> > - 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

> > 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 > > - >

> > 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,

> > 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://

> <http://lists.jboss.org/mailman/listinfo/seam-dev> > > > > > > > > _______________________________________________ > > seam-dev mailing list > > seam-dev(a)lists.jboss.org <mailto:seam-dev@lists.jboss.org> > > https://lists.jboss.org/mailman/listinfo/seam-dev > > > > > > > > > > _______________________________________________ > > seam-dev mailing list > > seam-dev(a)lists.jboss.org <mailto:seam-dev@lists.jboss.org> > > https://lists.jboss.org/mailman/listinfo/seam-dev