Check the reports pom. I fixed that by adding a dependencymanagement section

Em 20/08/2011, às 20:38, Shane Bryzak <sbryzak@redhat.com> escreveu:

It was my fault, there was a hard-coded arquillian dependency (for an older version of Arquillian) in the Solder impl.

On 21/08/11 09:28, John D. Ament wrote:

Do you have shrinkwrap descriptor api and impl in your reps somewhere?

John (sent from my DroidX)

On Aug 20, 2011 7:20 PM, "Shane Bryzak" <sbryzak@redhat.com> wrote:
> 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!
> initializationError(org.jboss.seam.solder.test.resourceLoader.ResourceLoaderTest)
> 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
> org.jboss.shrinkwrap.descriptor.impl.base.DescriptorImporterBase.from(DescriptorImporterBase.java:145)
> at
> org.jboss.arquillian.impl.bootstrap.ConfigurationRegistrar.loadConfiguration(ConfigurationRegistrar.java:50)
>
> 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@gmail.com
>> <mailto:gegastaldi@gmail.com>> wrote:
>> > +1 to the multiple sources idea
>> >
>> > Em 20/08/2011, às 20:01, Shane Bryzak <sbryzak@redhat.com
>> <mailto:sbryzak@redhat.com>> escreveu:
>> >
>> > We could possibly do it by specifying additional source directories
>> for each
>> > profile.
>> >
>> >
>> http://chadthedeveloper.blogspot.com/2008/02/maven2-multiple-source-directories-and.html
>> >
>> > 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@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@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@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 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 <sbryzak@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:
>> >
>> /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
>> >
>> listseam-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/seam-dev
>> <http://lists.jboss.org/mailman/listinfo/seam-dev>
>> >
>> >
>> >
>> > _______________________________________________
>> > seam-dev mailing list
>> > seam-dev@lists.jboss.org <mailto:seam-dev@lists.jboss.org>
>> > https://lists.jboss.org/mailman/listinfo/seam-dev
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > seam-dev mailing list
>> > seam-dev@lists.jboss.org <mailto:seam-dev@lists.jboss.org>
>> > https://lists.jboss.org/mailman/listinfo/seam-dev
>