It is the plan that this structure would become standard for all Seam 3 modules.

I agree that the container specific requirements for tests can be achieved through profiles.  However, I don't believe there is a way to run all tests against all container types within a single module as activating all the required profiles would add every arquillian container to the classpath and it wouldn't know which one to use  (Could be wrong on this but that's my understanding).

It also provides the added benefit of being part of the regular build/test cycle for a module, rather than having to remember to run the tests against each profile (and also remembering the correct names of the profiles).

Whether the configuration is within a single module and there are multiple profiles, or multiple modules with a single profile, I wouldn't consider any one to be more complex than the other as they simply provide the same configuration in a slightly different fashion.

On Wed, Jul 13, 2011 at 10:03 AM, Jozef Hartinger <> wrote:
Do you plan to use this new structure in every Seam 3 module? If so ,I don't think it is a good idea. Modules like Servlet, REST, Solder, ... have very few container-specific setup requirements. All that many modules need is the correct Arquillian dependency which is currently achieved by a Maven profile. Optionally, some of the modules add or exclude container-specific tests from the testsuite. This can again be done with Maven profiles.

Since these module do not need any container-specific artifacts for their testsuite, I find the proposed structure unnecessary complex. Also, I find splitting the testsuite into categories like smoke, cluster, internals, etc. quite artificial in this case.

On 07/11/2011 04:41 PM, Ken Finnigan wrote:
Yes it is a new structure for a Seam module for container testing.

Do you mean that you would want to run the three below scenarios, for all tests, against whichever containers you define (ie. AS7, SE, etc)?  I believe this should be possible by having base tests that define what the test does (in terms of the Seam JMS classes) and then separate tests that extend the base to add the specific libraries for that scenario, ie OWB + Apache ActiveMQ, which can then be further specialized for any specific container configuration that is required.

So I would see you needing something like:

       \base (holds the base test cases, with the extended versions for each scenario of CDI/JMS provider combos)
       \jboss (profile for as7, with test case extended from the base that holds specific container config)
       \tomcat (profile plus test extended with container specific config.

You can then have as many container modules as you want.

Does that make sense?

Over the next day or two I'll be completing the migration of i18n to option 3 so that it can be used as a base for other modules.


On Sun, Jul 10, 2011 at 1:35 PM, John D. Ament < <>> wrote:

   So what exactly is this?  Is this a new structure to support testing?

   Here's something I'm interested in.  I want to be able to test
   seam JMS in an SE type of environment, potentially with starting
   the JMS server in the same VM or a separate VM.  Part of this
   requires special modules in Seam JMS that connect to remote JMS
   providers, some of this requires special testing scenarios.     Ideally, I would want to run the full test suite repeatedly for
   each matching pair.  For example:

   Seam JMS + OWB + Apache ActiveMQ
   Seam JMS + Weld + Hornetq
   Seam JMS + Weld + OpenMQ

   Is this approach attainable through this setup?


   On Fri, Jul 8, 2011 at 12:11 PM, Jason Porter <
   <> <>> wrote:

       I'm liking #3

       Sent from my iPhone

       On Jul 8, 2011, at 9:28, Ken Finnigan <
       <>> wrote:

       I've been doing some further thinking around this over the
       last couple of days and have come up with 3 possible
       structures (there are undoubtedly more but that is as far as
       my brain got!):

       1) The original idea below.  ie.

       This setup requires each container, and version there of, to
       be a separate profile.  Container specific tests can be
       excluded with surefire.

       This does get quite messy quickly if there are lots of
       containers, and lots of container specific tests that need to
       be written (ie. lots of exclusions in profiles for tests you
       don't want to run)

       2) More along the lines of Seam Persistence.  ie.

       Each version of a container will have their own profile
       within a container module.

       This nicely breaks down the containers, but makes it
       difficult to know what pieces of a module (ie. API,
       internals, etc) are being tested on each container.

       3) A hybrid approach ie.
           \base or common

       We could either go with a base/common module at the root of
       testsuite, which would hold utilities for artifact creation
       and all common tests or base tests for all modules, and/or a
       base/common for each submodule (ie. api, internals).  Could
       take either approach, but a single base/common at the
       testsuite root may make it simpler.

       Each container module would then have a profile for each
       version, with the version of a container that you want to
       test as part of builds set to be active by default.

       I'm personally leaning towards 3 as it gives us a breakdown
       of types of testing, api, internals, smoke, cluster, etc
       while also providing a breakdown of container specific test

       Note: All pure unit tests that do not require a container
       would still remain in the appropriate module, ie. api or
       impl, of the project.

       Any other options anyone can think of, or tweaks to any of
       the above options?

       What does everyone think?


       On Wed, Jul 6, 2011 at 1:43 PM, Jason Porter <
       <> <>> wrote:

           Adding the rest of the list as I think we're nearing the
           point we want some more feedback.

           On Wed, Jul 6, 2011 at 10:35, Ken Finnigan
           < <>> wrote:

               Nasty, read the irc log, not nice at all on AS7 part!

               At the moment I have a structure similar to
               persistence, but more following AS7. ie:


           I like the ideas, but I think the structure should be
           along the lines of the containers (perhaps in addition
           to, if we're going to test things like clustering and perf).

               Idea being that pure unit tests (ie. no container)
               remain within either api/impl modules, then any
               container testing falls within the testsuite
               somewhere.  Default test only runs api, internals and
               smoke, others are picked up by a profile.

           Having the different containers be different test modules
           also gets us away from having to rely on a profile (so
           you could run each set of tests in one go instead of
           multiple invocations or lots of profiles).

               At present most of these folders are just ideas about
               the kinds of tests we could do (along the AS7 lines),
               but they seemed appropriate.  Existing i18n module
               tests are now in internals for testing the
               implementation.  I see smoke as being more
               comprehensive tests covering combined use of features
               in the module, and quite possibly integration with
               other modules too.

           I do kind of like the idea of all the tests being inside
           the test suite, but I'm also okay with basic unit tests
           living in api and impl. I think we probably need to do
           some lifecycle tweaking and have those tests under the
           testsuite run under the integration phase like Solder.

               Which container is run is then all down to profile.                 Not sure whether to continue with embedded weld being
               the default container that is run when no profile is
               specified, or to force a profile to be specified for
               any container testing.

               Also had another thought today as to whether the poms
               for the test modules should define dependencies, or
               whether dependent libraries should be added directly
               to deployment artifact as library to prevent
               unintended libraries from appearing on test classpath.

           If we go with test modules instead of profiles this
           becomes a non issue as they'd just be test deps for the


               On Wed, Jul 6, 2011 at 11:35 AM, Jason Porter
               < <>

               <>> wrote:

                   Very cool. I got stuff working for catch last
                   night too, but there is a problem if you're
                   testing deployment errors. It's actually an AS7
                   and Arquillian issue. I've opened JIRA tickets
                   about both. I think what we'll want to do is set
                   up testing similar to what Stuart has done in
                   Persistence with multiple modules. We'll
                   eventually want to test in (probably) embedded
                   weld (it's runs quickly, could probably be like a
                   smoke test), JBoss AS7, AS6, GF 3.1, Resin and an
                   OWB container or embedded OWB. Not all of those
                   containers work right now but then we really
                   could say we know it all works on each CDI impl.

                   Sent from my iPhone

                   On Jul 6, 2011, at 7:44, Ken Finnigan
                   < <>>

                   I actually "stole" some day job time to try at
                   work as I thought the problem might be caused by
                   the local build of as7 I had in my repo, but
                   that wasn't it.

                   Figured out the problem I was having with the
                   aether class not being found was caused by the
                   arquillian junit container dependency being
                   specified in a parent pom, and then the managed
                   container being specified in the pom running the
                   tests, which meant Maven decided the versions of
                   the jars in the pom running the tests should
                   take precedence.

                   Adding the junit container dependency to the pom
                   running the tests fixed that problem.

                   Should be able to finish up the test setup some
                   time tonight to then forward to the mailing list
                   for review.


                   On Tue, Jul 5, 2011 at 11:13 PM, Jason Porter
                   < <>

                   <>> wrote:

                       Sure, you let me know a time. I'm working on
                       getting Catch up to date as well. BTW,
                       Arquillian 1.0.0.Final will be out tomorrow,
                       not sure about container support though.

                       On Tue, Jul 5, 2011 at 20:22, Ken Finnigan
                       <>> wrote:


                           If you have some time tomorrow it would
                           be appreciated if you could take a look
                           at the new testsuite setup on i18n.                             Here's the branch:

                           I thought I was making progress but now
                           I seem to have managed to move
                           backwards!  For some reason I keep
                           getting a NoClassDef errors on aether
                           classes.  It appears that the classes
                           are brought in correctly from the
                           arquillian junit container (from
                           shrinkwrap beta 3), but then the jboss
                           as managed container brings in an older
                           version of shrinkwrap that doesn't
                           include aether.

                           I'm sure it's a simple fix, as I've
                           mirrored it off confbuzz, servlet and
                           rest, as well as jbossas, that all run
                           as7 arquillian tests, but can't see the
                           wood for the trees tonight.  Will be
                           looking at it again tomorrow evening,
                           but if you can spot an easy fix that
                           would be great!


                           On Tue, Jul 5, 2011 at 1:39 PM, Jason
                           Porter <

                           <>> wrote:

                               Okay, great. Let me or Dan know if
                               you need some help.

                               On Tue, Jul 5, 2011 at 11:37, Ken
                               Finnigan <
                               <>> wrote:

                                   Pretty good.

                                   Have the basic structure for the
                                   module in terms of what needs to
                                   go where.

                                   Currently going through and
                                   getting the existing i18n tests
                                   working in AS7, which is proving
                                   more of a challenge than I expected!

                                   Of all the tests that pass in
                                   weld-ee-embedded, about a third
                                   actually pass in AS7!  Most of
                                   it, I think, is down to
                                   differing classpaths, but should
                                   be in a position to push the
                                   feature branch to my fork of
                                   i18n in a couple of days.

                                   Once I've pushed it to my fork I
                                   was going to send an email to
                                   everyone on seam-dev to get
                                   their thoughts on the
                                   layout/setup for testing.

                                   btw, you don't need to worry
                                   about cc'ing my sorstech email
                                   in the future as I don't use
                                   that much anymore.


                                   On Tue, Jul 5, 2011 at 1:20 PM,
                                   Jason Porter <

                                   <>> wrote:

                                       How goes things with i18n
                                       and the new Arquillian?

                                       --                                         Jason Porter

                                       Software Engineer
                                       Open Source Advocate
                                       Author of Seam Catch - Next
                                       Generation Java Exception

                                       PGP key id: 926CCFF5
                                       PGP key available at:

                               --                                 Jason Porter

                               Software Engineer
                               Open Source Advocate
                               Author of Seam Catch - Next
                               Generation Java Exception Handling

                               PGP key id: 926CCFF5
                               PGP key available at:

                       --                         Jason Porter

                       Software Engineer
                       Open Source Advocate
                       Author of Seam Catch - Next Generation Java
                       Exception Handling

                       PGP key id: 926CCFF5
                       PGP key available at:

           --             Jason Porter

           Software Engineer
           Open Source Advocate
           Author of Seam Catch - Next Generation Java Exception

           PGP key id: 926CCFF5
           PGP key available at:
           <>, <>

       seam-dev mailing list <>

seam-dev mailing list