I guess at a high level, yes it would be. However, I was trying to avoid creating 60 additional classes to support the idea. Essentially there would be
testsuite se-owb-activemq se-weld-openmq se-weld-hornetq John On Mon, Jul 11, 2011 at 10:41 AM, Ken Finnigan <[email protected]> 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: > > \testsuite > \internals > \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. > > Ken > > > > On Sun, Jul 10, 2011 at 1:35 PM, John D. Ament <[email protected]>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? >> >> John >> >> On Fri, Jul 8, 2011 at 12:11 PM, Jason Porter <[email protected]>wrote: >> >>> I'm liking #3 >>> >>> Sent from my iPhone >>> >>> On Jul 8, 2011, at 9:28, Ken Finnigan <[email protected]> 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. >>> \testsuite >>> \api >>> \internals >>> \smoke >>> >>> 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. >>> \testsuite >>> \base >>> \jboss >>> \weld-embedded >>> \jetty >>> >>> 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. >>> \testsuite >>> \base or common >>> \internals >>> \base >>> \jboss >>> \jetty >>> >>> 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 requirements. >>> >>> 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? >>> >>> Ken >>> >>> >>> On Wed, Jul 6, 2011 at 1:43 PM, Jason Porter < <http://lightguard.jp> >>> lightguard.jp@ <http://gmail.com>gmail.com> 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 < <[email protected]> >>>> [email protected]> 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: >>>>> >>>>> \module_parent >>>>> \api >>>>> \impl >>>>> \testsuite >>>>> \api >>>>> \benchmark >>>>> \clustering >>>>> \internals >>>>> \smoke >>>>> \stress >>>>> >>>> >>>> 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 module. >>>> >>>> Thoughts? >>>>> >>>>> >>>>> >>>>> On Wed, Jul 6, 2011 at 11:35 AM, Jason Porter < <http://lightguard.jp> >>>>> lightguard.jp@ <http://gmail.com>gmail.com> 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 < <[email protected]> >>>>>> [email protected]> wrote: >>>>>> >>>>>> 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. >>>>>> >>>>>> Ken >>>>>> >>>>>> On Tue, Jul 5, 2011 at 11:13 PM, Jason Porter >>>>>> <<http://lightguard.jp><http://lightguard.jp> >>>>>> lightguard.jp@ <http://gmail.com> <http://gmail.com>gmail.com> 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 < >>>>>>> <[email protected]><[email protected]> >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Jason, >>>>>>>> >>>>>>>> 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: >>>>>>>> git://<http://github.com/kenfinnigan/international.git><http://github.com/kenfinnigan/international.git> >>>>>>>> github.com/kenfinnigan/international.git >>>>>>>> >>>>>>>> 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! >>>>>>>> >>>>>>>> Thanks >>>>>>>> Ken >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Jul 5, 2011 at 1:39 PM, Jason Porter >>>>>>>> <<http://lightguard.jp><http://lightguard.jp> >>>>>>>> lightguard.jp@ <http://gmail.com> <http://gmail.com>gmail.com>wrote: >>>>>>>> >>>>>>>>> Okay, great. Let me or Dan know if you need some help. >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, Jul 5, 2011 at 11:37, Ken Finnigan < >>>>>>>>> <[email protected]><[email protected]> >>>>>>>>> [email protected]> 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. >>>>>>>>>> >>>>>>>>>> Ken >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Tue, Jul 5, 2011 at 1:20 PM, Jason Porter >>>>>>>>>> <<http://lightguard.jp><http://lightguard.jp> >>>>>>>>>> lightguard.jp@ <http://gmail.com> <http://gmail.com>gmail.com>wrote: >>>>>>>>>> >>>>>>>>>>> How goes things with i18n and the new Arquillian? >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Jason Porter >>>>>>>>>>> <http://lightguard-jp.blogspot.com><http://lightguard-jp.blogspot.com> >>>>>>>>>>> http://lightguard-jp.blogspot.com >>>>>>>>>>> <http://twitter.com/lightguardjp><http://twitter.com/lightguardjp> >>>>>>>>>>> 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: <http://keyserver.net><http://keyserver.net> >>>>>>>>>>> keyserver.net, <http://pgp.mit.edu> <http://pgp.mit.edu> >>>>>>>>>>> pgp.mit.edu >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Jason Porter >>>>>>>>> <http://lightguard-jp.blogspot.com><http://lightguard-jp.blogspot.com> >>>>>>>>> http://lightguard-jp.blogspot.com >>>>>>>>> <http://twitter.com/lightguardjp><http://twitter.com/lightguardjp> >>>>>>>>> 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: <http://keyserver.net><http://keyserver.net> >>>>>>>>> keyserver.net, <http://pgp.mit.edu> <http://pgp.mit.edu> >>>>>>>>> pgp.mit.edu >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Jason Porter >>>>>>> <http://lightguard-jp.blogspot.com><http://lightguard-jp.blogspot.com> >>>>>>> http://lightguard-jp.blogspot.com >>>>>>> <http://twitter.com/lightguardjp> <http://twitter.com/lightguardjp> >>>>>>> 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: <http://keyserver.net> <http://keyserver.net> >>>>>>> keyserver.net, <http://pgp.mit.edu> <http://pgp.mit.edu>pgp.mit.edu >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> Jason Porter >>>> <http://lightguard-jp.blogspot.com>http://lightguard-jp.blogspot.com >>>> <http://twitter.com/lightguardjp>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: <http://keyserver.net>keyserver.net, >>>> <http://pgp.mit.edu>pgp.mit.edu >>>> >>> >>> >>> _______________________________________________ >>> 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
