Seam 2
  1. Seam 2
  2. JBSEAM-2371

Integration testing Seam components with Maven

    Details

    • Type: Task Task
    • Status: Closed Closed (View Workflow)
    • Priority: Critical Critical
    • Resolution: Done
    • Affects Version/s: 2.0.0.GA
    • Fix Version/s: 2.3.0.ALPHA
    • Component/s: Build, Test Harness
    • Labels:
      None
    • Environment:
      Maven 2.0.7
    • Similar Issues:
      Show 10 results 

      Description

      Various users have reported integration testing with Seam is not working in 'Mavenized' projects.

      1. jg-seamtest-1.0.tgz
        11 kB
        Jason Grant
      2. tech-stack-1.0.1.pom
        18 kB
        Hemant Saxena

        Issue Links

          Activity

          Hide
          sushmu
          added a comment -

          The main problem is the library mismatch and classpath issues. A working maven example with the seam distribution would greatly help. Thanks.

          Show
          sushmu
          added a comment - The main problem is the library mismatch and classpath issues. A working maven example with the seam distribution would greatly help. Thanks.
          Hide
          Siarhei Dudzin
          added a comment -

          Please, use the following attachment (used for JBoss Tools): http://jira.jboss.org/jira/secure/attachment/12316955/test-project-JBIDE-1322.zip

          Show
          Siarhei Dudzin
          added a comment - Please, use the following attachment (used for JBoss Tools): http://jira.jboss.org/jira/secure/attachment/12316955/test-project-JBIDE-1322.zip
          Hide
          Siarhei Dudzin
          added a comment -

          Just a quick update. I have maven 2.0.8 now with JAVA_HOME pointing to JDK 1.5 and the most basic integration test seem to work (seam environment gets initialized and I managed to call #

          {authenticator.authenticate}

          (logger and identity are successfully injected). Not sure why it works yet (I really haven't done anything except that I upgraded to maven 2.0.8 quite some time ago) as the dependency tree doesn't seem sufficient enough.

          I'll try to 'normalize' the project so that the parent pom doesn't use seam as parent project but uses it as a dependency (a more 'enterprise-friendly' way).

          Show
          Siarhei Dudzin
          added a comment - Just a quick update. I have maven 2.0.8 now with JAVA_HOME pointing to JDK 1.5 and the most basic integration test seem to work (seam environment gets initialized and I managed to call # {authenticator.authenticate} (logger and identity are successfully injected). Not sure why it works yet (I really haven't done anything except that I upgraded to maven 2.0.8 quite some time ago) as the dependency tree doesn't seem sufficient enough. I'll try to 'normalize' the project so that the parent pom doesn't use seam as parent project but uses it as a dependency (a more 'enterprise-friendly' way).
          Hide
          Siarhei Dudzin
          added a comment -

          Btw, it seems that integration tests partly seem to work with maven 2.0.8 (also jdk 1.5) only if I remove jboss embedded from test classpath!

          Show
          Siarhei Dudzin
          added a comment - Btw, it seems that integration tests partly seem to work with maven 2.0.8 (also jdk 1.5) only if I remove jboss embedded from test classpath!
          Hide
          Pete Muir
          added a comment -

          Excellent!

          Show
          Pete Muir
          added a comment - Excellent!
          Hide
          Anne Chou
          added a comment -

          Removing the jboss embedded jars from the test classpath causes problems if deploying an EJB for testing. Using Maven 2.0.8 with surefire plugin 2.4 and TestNG 5.6 fails to find the DataSource at this line of the SeamTest code:

          EntityManagerFactory emf = Persistence.createEntityManagerFactory("test_database");

          even though the persistence unit "test_database" is properly defined in persistence.xml and points to the DefaultDS. (Default bootstrap files deploy\hsqldb-ds.xml, embedded-jboss-beans.xml, etc. are all in the test classpath)

          Show
          Anne Chou
          added a comment - Removing the jboss embedded jars from the test classpath causes problems if deploying an EJB for testing. Using Maven 2.0.8 with surefire plugin 2.4 and TestNG 5.6 fails to find the DataSource at this line of the SeamTest code: EntityManagerFactory emf = Persistence.createEntityManagerFactory("test_database"); even though the persistence unit "test_database" is properly defined in persistence.xml and points to the DefaultDS. (Default bootstrap files deploy\hsqldb-ds.xml, embedded-jboss-beans.xml, etc. are all in the test classpath)
          Hide
          Siarhei Dudzin
          added a comment -

          It wouldn't work becuase you use jndi reference in persistence.xml (and since there is no jboss embeded there is no JNDI provider). It works if you have a direct jdbc url in your persistence.xml, which is working as intended (considering you don't run jboss embedded).
          My tests use Persistence.createEntityManagerFactory with no problems this way.

          Show
          Siarhei Dudzin
          added a comment - It wouldn't work becuase you use jndi reference in persistence.xml (and since there is no jboss embeded there is no JNDI provider). It works if you have a direct jdbc url in your persistence.xml, which is working as intended (considering you don't run jboss embedded). My tests use Persistence.createEntityManagerFactory with no problems this way.
          Hide
          Anne Chou
          added a comment -

          That makes sense. But, just to clarify my last comment, removing the embedded jar from my test classpath caused exceptions because EJB3 is expecting the embedded container in order to deploy correctly. The DataSource error (above) occurs when running with the jboss-embedded-all.jar included in the test classpath.

          Show
          Anne Chou
          added a comment - That makes sense. But, just to clarify my last comment, removing the embedded jar from my test classpath caused exceptions because EJB3 is expecting the embedded container in order to deploy correctly. The DataSource error (above) occurs when running with the jboss-embedded-all.jar included in the test classpath.
          Hide
          Siarhei Dudzin
          added a comment -

          Agree, that's why I said 'most basic integration test'

          Show
          Siarhei Dudzin
          added a comment - Agree, that's why I said 'most basic integration test'
          Hide
          Siarhei Dudzin
          added a comment -

          Pete, doballve ( http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4128025#4128025 ) has done great work and put a mavenized testable booking example on JBoss Wiki: http://wiki.jboss.org/wiki/attach?page=JBossSeam%2FBookingExample-2.0.1.GA-mavenized.zip

          It's not perfect yet but at least jboss embedded seem to start. Apparently the solution uses maven ant tun plugin to custom-build a single classpath as a workaround of for jboss embedded.
          I can also see there is quite some classpath resolution efforts are done, but I think JBSEAM-2006 addresses it?
          Do you know whether the situation with jboss embedded will be resolved/addressed?

          Now if we could make it work without antrun plugin it would be and run under jboss tools/wtp it would be almost complete!

          Show
          Siarhei Dudzin
          added a comment - Pete, doballve ( http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4128025#4128025 ) has done great work and put a mavenized testable booking example on JBoss Wiki: http://wiki.jboss.org/wiki/attach?page=JBossSeam%2FBookingExample-2.0.1.GA-mavenized.zip It's not perfect yet but at least jboss embedded seem to start. Apparently the solution uses maven ant tun plugin to custom-build a single classpath as a workaround of for jboss embedded. I can also see there is quite some classpath resolution efforts are done, but I think JBSEAM-2006 addresses it? Do you know whether the situation with jboss embedded will be resolved/addressed? Now if we could make it work without antrun plugin it would be and run under jboss tools/wtp it would be almost complete!
          Hide
          Siarhei Dudzin
          added a comment -

          Besides the JBoss Embedded problem, this issue also depends (this concerns mostly IDE support as SureFire plugin manages to put JBoss Embedded *-all jars in the right place) on resolutions of the following issues:

          http://jira.codehaus.org/browse/MNG-1412 - once this fixed the classpath will be much more predictable

          http://jira.codehaus.org/browse/MECLIPSE-294 introduced alphabetical sorting order for eclipse classpath (maven-eclipse-plugin allows to generate eclipse projects based on project pom.xml). To address MECLIPSE-294 when maven 2.0.9 comes out I've created http://jira.codehaus.org/browse/MECLIPSE-388 which should rollback MECLIPSE-294 to default dependencies ordering (which should be ok because maven 2.0.9 will have MNG-1412).

          Until then if you want to run integration tests in eclipse for projects created from maven you would need to manually re-order JBoss Embedded libraries and put all the '*-all' jars in the first place (or give them ugly names so that the alphabetical order puts them in the first place).

          Show
          Siarhei Dudzin
          added a comment - Besides the JBoss Embedded problem, this issue also depends (this concerns mostly IDE support as SureFire plugin manages to put JBoss Embedded *-all jars in the right place) on resolutions of the following issues: http://jira.codehaus.org/browse/MNG-1412 - once this fixed the classpath will be much more predictable http://jira.codehaus.org/browse/MECLIPSE-294 introduced alphabetical sorting order for eclipse classpath (maven-eclipse-plugin allows to generate eclipse projects based on project pom.xml). To address MECLIPSE-294 when maven 2.0.9 comes out I've created http://jira.codehaus.org/browse/MECLIPSE-388 which should rollback MECLIPSE-294 to default dependencies ordering (which should be ok because maven 2.0.9 will have MNG-1412). Until then if you want to run integration tests in eclipse for projects created from maven you would need to manually re-order JBoss Embedded libraries and put all the '*-all' jars in the first place (or give them ugly names so that the alphabetical order puts them in the first place).
          Hide
          Pete Muir
          added a comment -

          There are a number of approaches here, and I need time to look at them all (including building embedded via maven rather than -all.jars).

          It will get started soon I hope (with luck before Easter).

          Show
          Pete Muir
          added a comment - There are a number of approaches here, and I need time to look at them all (including building embedded via maven rather than -all.jars). It will get started soon I hope (with luck before Easter).
          Hide
          Siarhei Dudzin
          added a comment -

          Actually a JBoss team (JBoss Build System) also identified classpath ordering issue (but probably for other reasons) at JBBUILD-417 which leads to http://jira.codehaus.org/browse/MNG-3197 which in turn duplicates MNG-1412 which I mentioned above.

          Show
          Siarhei Dudzin
          added a comment - Actually a JBoss team (JBoss Build System) also identified classpath ordering issue (but probably for other reasons) at JBBUILD-417 which leads to http://jira.codehaus.org/browse/MNG-3197 which in turn duplicates MNG-1412 which I mentioned above.
          Hide
          Siarhei Dudzin
          added a comment -

          Ok. Here is what I've come up with... Attached a multi module maven project (no ad-hoc ant scripts). The project consists of parent, ear, war and ejb modules.
          This is in fact a booking demo with a number of tests (see in the web module).

          What works:

          • Generating an EAR via maven and dropping it to JBoss deploy dir
          • Generating a WTP-2.0 eclipse project descriptors with "mvn eclipse:eclipse". No .project and .classpath files are in fact needed to get started! Everything comes from pom's (see note [1]).
          • Performing (component, integration) tests via maven (see notes[2])
          • Performing TestNG tests in eclipse with the TestNG eclipse plugin (see note [3])

          Notes (or what doesn't work):

          [1] JBossTools don't deploy it (WTP plugin as well as it's even older) due to the fact that in order to run integration tests web root dir should be in test resources (test classpath). This makes JBossTools think for some reason that test resources should never be a web root dir (even if I force warSourceDirectory) and thus doesn't explode them (no xhml files in the exploded dir). I still think a (ugly) workaround is possible however I would like to see this fixed on JBossTools side.

          [2] Because integration tests require WEB-INF etc, it makes (actually) sense to keep component and integration tests in the web module (as implemented) and only pure unit tests can go to the ejb module.

          [3] To perform TestNG test within eclipse the test classpath the test classpath in eclipse test configuration needs to be changed so that jboss-embedded-all, thirdparty-all and jboss-embedded-api come before the project. This is needed because if you generate eclipse project descriptors with maven-eclipse-plugin it generates classpath in alphabetic order (a classpath ordering bug which is fixed in maven 2.0.9). The fix for the maven-eclipse-plugin will come most likely in version 3.0 (http://jira.codehaus.org/browse/MECLIPSE-388).

          This is still messy but might be a start... If this is getting accepted a JIRA issue needs to be created for JBoss Tools regarding [1].

          Show
          Siarhei Dudzin
          added a comment - Ok. Here is what I've come up with... Attached a multi module maven project (no ad-hoc ant scripts). The project consists of parent, ear, war and ejb modules. This is in fact a booking demo with a number of tests (see in the web module). What works: Generating an EAR via maven and dropping it to JBoss deploy dir Generating a WTP-2.0 eclipse project descriptors with "mvn eclipse:eclipse". No .project and .classpath files are in fact needed to get started! Everything comes from pom's (see note [1] ). Performing (component, integration) tests via maven (see notes [2] ) Performing TestNG tests in eclipse with the TestNG eclipse plugin (see note [3] ) Notes (or what doesn't work): [1] JBossTools don't deploy it (WTP plugin as well as it's even older) due to the fact that in order to run integration tests web root dir should be in test resources (test classpath). This makes JBossTools think for some reason that test resources should never be a web root dir (even if I force warSourceDirectory) and thus doesn't explode them (no xhml files in the exploded dir). I still think a (ugly) workaround is possible however I would like to see this fixed on JBossTools side. [2] Because integration tests require WEB-INF etc, it makes (actually) sense to keep component and integration tests in the web module (as implemented) and only pure unit tests can go to the ejb module. [3] To perform TestNG test within eclipse the test classpath the test classpath in eclipse test configuration needs to be changed so that jboss-embedded-all, thirdparty-all and jboss-embedded-api come before the project. This is needed because if you generate eclipse project descriptors with maven-eclipse-plugin it generates classpath in alphabetic order (a classpath ordering bug which is fixed in maven 2.0.9). The fix for the maven-eclipse-plugin will come most likely in version 3.0 ( http://jira.codehaus.org/browse/MECLIPSE-388 ). This is still messy but might be a start... If this is getting accepted a JIRA issue needs to be created for JBoss Tools regarding [1] .
          Hide
          Hemant Saxena
          added a comment -

          I am able to successfully perform intregrated testing for seam components with jboss embedded container under my production mavenized project. Key to work is the separate inclusion of jboss-embedded dependency.
          Here are the details:

          We have parent POM and sub POMs structure in our project.

          In parent POM, include:
          ====================
          Step1:
          <!-- JBoss Seam Test -->
          <dependency>
          <groupId>org.testng</groupId>
          <artifactId>testng</artifactId>
          <version>5.7</version>
          <classifier>jdk15</classifier>
          </dependency>

          </dependencies>
          </dependencyManagement>

          Step2:
          <plugin>
          <groupId>org.apache.maven.plugins</groupId>
          <artifactId>maven-surefire-plugin</artifactId>
          <version>2.4.2</version>
          </plugin>
          </plugins>
          </pluginManagement>

          In the ejb/POM:
          ============
          Step1:
          <!-- TestNG -->
          <dependency>
          <groupId>org.testng</groupId>
          <artifactId>testng</artifactId>
          <scope>test</scope>
          <classifier>jdk15</classifier>
          </dependency>

          <dependency>
          <groupId>javax.el</groupId>
          <artifactId>el-api</artifactId>
          <scope>test</scope>
          </dependency>

          <!-- JBoss EJB3 Microcontainer for testing -->

          <dependency>
          <groupId>org.jboss.embedded</groupId>
          <artifactId>jboss-embedded-all</artifactId>
          <version>beta3</version>
          <scope>test</scope>
          </dependency>
          <dependency>
          <groupId>org.jboss.embedded</groupId>
          <artifactId>jboss-embedded-all</artifactId>
          <version>beta3</version>
          <exclusions>
          <exclusion>
          <groupId>org.jboss.embedded</groupId>
          <artifactId>jboss-embedded</artifactId>
          </exclusion>

          <exclusion>
          <groupId>org.jboss.microcontainer</groupId>
          <artifactId>jboss-deployers-client-spi</artifactId>
          </exclusion>
          <exclusion>
          <groupId>org.jboss.microcontainer</groupId>
          <artifactId>jboss-deployers-core-spi</artifactId>
          </exclusion>
          </exclusions>
          <scope>test</scope>
          </dependency>
          <dependency>
          <groupId>org.jboss.embedded</groupId>
          <artifactId>hibernate-all</artifactId>
          <version>beta3</version>
          <scope>test</scope>
          </dependency>
          <dependency>
          <groupId>org.jboss.embedded</groupId>
          <artifactId>thirdparty-all</artifactId>
          <version>beta3</version>
          <scope>test</scope>
          </dependency>
          <dependency>
          <groupId>org.jboss.embedded</groupId>
          <artifactId>jboss-embedded</artifactId>
          <version>beta3</version>
          <scope>test</scope>
          <exclusions>
          <exclusion>
          <groupId>org.jboss.microcontainer</groupId>
          <artifactId>jboss-deployers-client-spi</artifactId>
          </exclusion>

          </exclusions>
          </dependency>

          step2:

          <plugins>
          <plugin>
          <artifactId>maven-dependency-plugin</artifactId>
          <executions>

          <execution>
          <configuration>
          <artifactItems>
          <artifactItem>
          <groupId>org.jboss.embedded</groupId>
          <artifactId>jboss-embedded-bootstrap</artifactId>
          <type>zip</type>
          <version>beta3</version>
          </artifactItem>
          </artifactItems>
          <outputDirectory>$

          {project.build.testOutputDirectory}</outputDirectory>
          </configuration>
          <id>download-embedded-jboss-bootstrap</id>
          <phase>process-test-resources</phase>
          <goals>
          <goal>unpack</goal>
          </goals>
          </execution>
          <execution>
          <configuration>
          <artifactItems>
          <artifactItem>
          <groupId>javax.xml.bind</groupId>
          <artifactId>jaxb-api</artifactId>
          <version>2.1</version>
          </artifactItem>
          </artifactItems>
          <outputDirectory>${project.build.testOutputDirectory}

          /endorsed</outputDirectory>
          </configuration>
          <id>download-jaxb-api</id>
          <phase>process-test-resources</phase>
          <goals>
          <goal>copy</goal>
          </goals>
          </execution>
          </executions>

          Step 3:
          </plugin>

          <plugin>
          <groupId>org.apache.maven.plugins</groupId>
          <artifactId>maven-surefire-plugin</artifactId>
          <configuration>
          <suiteXmlFiles>
          <suiteXmlFile>src/test/java/com/autotrader/adsinvmgr/testng.xml</suiteXmlFile>
          </suiteXmlFiles>
          <additionalClasspathElements>
          <additionalClasspathElement>$

          {project.build.testOutputDirectory}/bootstrap</additionalClasspathElement>
          </additionalClasspathElements>
          <childDelegation>true</childDelegation>
          <useSystemClassLoader>true</useSystemClassLoader>
          <argLine>-Djava.endorsed.dirs=${project.build.testOutputDirectory}

          /endorsed -Dsun.lang.ClassLoader.allowArraySyntax=true</argLine>
          </configuration>
          </plugin>

          You dont need to do argLine inclusion if you are using jdk5. It only requires for jdk6. Then start writing your test cases under (src/test/java) as defined in Seam Docs ( extending SeamTest).

          PS:
          when surefire plugin execute testng, it has the following output folders defined for classpath:

          • ejb/target/classes
          • ejb/target/test-classes

          so files/folders like meta-inf/persistence.xml, seam.properties comes from ejb/classes. We dont need to add them seperately.

          Please feel free to contact me for template project or for any further questions.

          Show
          Hemant Saxena
          added a comment - I am able to successfully perform intregrated testing for seam components with jboss embedded container under my production mavenized project. Key to work is the separate inclusion of jboss-embedded dependency. Here are the details: We have parent POM and sub POMs structure in our project. In parent POM, include: ==================== Step1: <!-- JBoss Seam Test --> <dependency> <groupId>org.testng</groupId> <artifactId>testng</artifactId> <version>5.7</version> <classifier>jdk15</classifier> </dependency> </dependencies> </dependencyManagement> Step2: <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-surefire-plugin</artifactId> <version>2.4.2</version> </plugin> </plugins> </pluginManagement> In the ejb/POM: ============ Step1: <!-- TestNG --> <dependency> <groupId>org.testng</groupId> <artifactId>testng</artifactId> <scope>test</scope> <classifier>jdk15</classifier> </dependency> <dependency> <groupId>javax.el</groupId> <artifactId>el-api</artifactId> <scope>test</scope> </dependency> <!-- JBoss EJB3 Microcontainer for testing --> <dependency> <groupId>org.jboss.embedded</groupId> <artifactId>jboss-embedded-all</artifactId> <version>beta3</version> <scope>test</scope> </dependency> <dependency> <groupId>org.jboss.embedded</groupId> <artifactId>jboss-embedded-all</artifactId> <version>beta3</version> <exclusions> <exclusion> <groupId>org.jboss.embedded</groupId> <artifactId>jboss-embedded</artifactId> </exclusion> <exclusion> <groupId>org.jboss.microcontainer</groupId> <artifactId>jboss-deployers-client-spi</artifactId> </exclusion> <exclusion> <groupId>org.jboss.microcontainer</groupId> <artifactId>jboss-deployers-core-spi</artifactId> </exclusion> </exclusions> <scope>test</scope> </dependency> <dependency> <groupId>org.jboss.embedded</groupId> <artifactId>hibernate-all</artifactId> <version>beta3</version> <scope>test</scope> </dependency> <dependency> <groupId>org.jboss.embedded</groupId> <artifactId>thirdparty-all</artifactId> <version>beta3</version> <scope>test</scope> </dependency> <dependency> <groupId>org.jboss.embedded</groupId> <artifactId>jboss-embedded</artifactId> <version>beta3</version> <scope>test</scope> <exclusions> <exclusion> <groupId>org.jboss.microcontainer</groupId> <artifactId>jboss-deployers-client-spi</artifactId> </exclusion> </exclusions> </dependency> step2: <plugins> <plugin> <artifactId>maven-dependency-plugin</artifactId> <executions> <execution> <configuration> <artifactItems> <artifactItem> <groupId>org.jboss.embedded</groupId> <artifactId>jboss-embedded-bootstrap</artifactId> <type>zip</type> <version>beta3</version> </artifactItem> </artifactItems> <outputDirectory>$ {project.build.testOutputDirectory}</outputDirectory> </configuration> <id>download-embedded-jboss-bootstrap</id> <phase>process-test-resources</phase> <goals> <goal>unpack</goal> </goals> </execution> <execution> <configuration> <artifactItems> <artifactItem> <groupId>javax.xml.bind</groupId> <artifactId>jaxb-api</artifactId> <version>2.1</version> </artifactItem> </artifactItems> <outputDirectory>${project.build.testOutputDirectory} /endorsed</outputDirectory> </configuration> <id>download-jaxb-api</id> <phase>process-test-resources</phase> <goals> <goal>copy</goal> </goals> </execution> </executions> Step 3: </plugin> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-surefire-plugin</artifactId> <configuration> <suiteXmlFiles> <suiteXmlFile>src/test/java/com/autotrader/adsinvmgr/testng.xml</suiteXmlFile> </suiteXmlFiles> <additionalClasspathElements> <additionalClasspathElement>$ {project.build.testOutputDirectory}/bootstrap</additionalClasspathElement> </additionalClasspathElements> <childDelegation>true</childDelegation> <useSystemClassLoader>true</useSystemClassLoader> <argLine>-Djava.endorsed.dirs=${project.build.testOutputDirectory} /endorsed -Dsun.lang.ClassLoader.allowArraySyntax=true</argLine> </configuration> </plugin> You dont need to do argLine inclusion if you are using jdk5. It only requires for jdk6. Then start writing your test cases under (src/test/java) as defined in Seam Docs ( extending SeamTest). PS: when surefire plugin execute testng, it has the following output folders defined for classpath: ejb/target/classes ejb/target/test-classes so files/folders like meta-inf/persistence.xml, seam.properties comes from ejb/classes. We dont need to add them seperately. Please feel free to contact me for template project or for any further questions.
          Hide
          Siarhei Dudzin
          added a comment -

          Nice trick with jboss-embedded-bootstrap, too bad it will unpack it each time you build (will make builds kinda slower) - still it is (arguably) better than to have it manually 'unpacked' (although might be done by archetype plugin). I think what we need is a jboss embedded that 'just works' from a jar with Seam.

          I don't see where your web module plays part? Do your integration tests make use of components.xml and any part of integration tests that make use of navigation or security (because for that you need stuff from WEB-INF)?

          Did you actually have a look at the attachment? There is a 'complete' solution (even works with eclipse testng plugin) with exception of WTP support.

          I haven't heard an opinion from Pete yet, so it's hard to say whether they want to go this way (may be they have something else in mind).

          Show
          Siarhei Dudzin
          added a comment - Nice trick with jboss-embedded-bootstrap, too bad it will unpack it each time you build (will make builds kinda slower) - still it is (arguably) better than to have it manually 'unpacked' (although might be done by archetype plugin). I think what we need is a jboss embedded that 'just works' from a jar with Seam. I don't see where your web module plays part? Do your integration tests make use of components.xml and any part of integration tests that make use of navigation or security (because for that you need stuff from WEB-INF)? Did you actually have a look at the attachment? There is a 'complete' solution (even works with eclipse testng plugin) with exception of WTP support. I haven't heard an opinion from Pete yet, so it's hard to say whether they want to go this way (may be they have something else in mind).
          Hide
          Hemant Saxena
          added a comment -

          This is the snapshot of the working code which demonstrate mavenized project for seam, richfaces, reporting, surefire, testng, seam microcontainer and jboss embedded. This is loaded for reference on how to layout your poms.

          Show
          Hemant Saxena
          added a comment - This is the snapshot of the working code which demonstrate mavenized project for seam, richfaces, reporting, surefire, testng, seam microcontainer and jboss embedded. This is loaded for reference on how to layout your poms.
          Hide
          Pete Muir
          added a comment -

          This is target for 2.1.0.BETA1 (GA quality maven support).

          I haven't fully evaluated the options yet.

          Show
          Pete Muir
          added a comment - This is target for 2.1.0.BETA1 (GA quality maven support). I haven't fully evaluated the options yet.
          Hide
          Hemant Saxena
          added a comment -

          Attached is the reference snapshot of the our mavenized project.

          • It neatly describe the dependency artifact for seam, richfaces combo; and other required conf files
          • It neatly describe the dependency requires to invoke surefire --> which invoke testng – which invoke SeamTest --> which bootstrap jboss embeddable container (this will provide JTA, JNDI and other stuff) and the seam microcontainer (this initialize seam components).

          What I understand that we (including me) were able to bootstrap seam microcontainer but wasnt able to bootstrap jboss embedded container along because of the dependencies issues. And thats the reason why JNDI env wasnt available and we werent able to deploy -ds.xml files which lead to non-instantiating EntityManager through Components.xml. The solution I gave in the earlier comment just exactly solve the dependency issues which lead to successful bootstrap of jboss embeddable container and seam was able to inject entitymanager into its components. I tried some basic navigation stuff and security stuff and it works.

          if you need more stuff to be loaded like navigation, jbpm and all , you need to get it copied to <project>/test-classes path inorder to get it picked up by seam microcontainer.
          Please refer to template project on how things has been laid out.
          I have not included the eclipse project files because that you can easily generate those by following command:
          $maven eclipse:eclipse
          or (using wtpversion version)
          $mvn -Dwtpversion=1.5 eclipse:eclipse

          Show
          Hemant Saxena
          added a comment - Attached is the reference snapshot of the our mavenized project. It neatly describe the dependency artifact for seam, richfaces combo; and other required conf files It neatly describe the dependency requires to invoke surefire --> which invoke testng – which invoke SeamTest --> which bootstrap jboss embeddable container (this will provide JTA, JNDI and other stuff) and the seam microcontainer (this initialize seam components). What I understand that we (including me) were able to bootstrap seam microcontainer but wasnt able to bootstrap jboss embedded container along because of the dependencies issues. And thats the reason why JNDI env wasnt available and we werent able to deploy -ds.xml files which lead to non-instantiating EntityManager through Components.xml. The solution I gave in the earlier comment just exactly solve the dependency issues which lead to successful bootstrap of jboss embeddable container and seam was able to inject entitymanager into its components. I tried some basic navigation stuff and security stuff and it works. if you need more stuff to be loaded like navigation, jbpm and all , you need to get it copied to <project>/test-classes path inorder to get it picked up by seam microcontainer. Please refer to template project on how things has been laid out. I have not included the eclipse project files because that you can easily generate those by following command: $maven eclipse:eclipse or (using wtpversion version) $mvn -Dwtpversion=1.5 eclipse:eclipse
          Hide
          Siarhei Dudzin
          added a comment -

          Actually, the problem with jboss embedded was solved back in February by doballve (http://www.jboss.com/index.html?module=bb&op=viewtopic&t=126786&postdays=0&postorder=asc&start=20). After that the solution is refactored a bit to get rid of ant scripts.

          When I began working on the problem I also started with running tests exclusively from ejb module. After digging some Seam code it appeared it requires xml descriptors from WEB-INF, so the choice was either to duplicate stuff from web module (and being able to run all tests from ejb module) or to move integration and component (but not necessarily unit) tests to web module.

          Since I really prefer DRY I've chosen the latter. As a consequence there is a difficulty to use cobertura plugin (because the integration tests run in different phase and even in different module) and there is problem with JBoss tools (hopefully it's small).
          It might seem your proposal wont necessarily have those problems at a cost of duplicating some xml descriptors (components.xml isn't that big of a deal but navigation might be, especially fine grained one)

          But the more options/version we have before the real work starts the better

          I might actually use your solution to be able to use integration testing that doesn't involve navigation or security without all the drawbacks, so thanks for that!

          I am also quite familiar with the maven-eclipse-plugin, did you try JBoss Tools + WTP 2.0 (I mean exploded deployment here) with your solution (I expect it should work)?

          Show
          Siarhei Dudzin
          added a comment - Actually, the problem with jboss embedded was solved back in February by doballve ( http://www.jboss.com/index.html?module=bb&op=viewtopic&t=126786&postdays=0&postorder=asc&start=20 ). After that the solution is refactored a bit to get rid of ant scripts. When I began working on the problem I also started with running tests exclusively from ejb module. After digging some Seam code it appeared it requires xml descriptors from WEB-INF, so the choice was either to duplicate stuff from web module (and being able to run all tests from ejb module) or to move integration and component (but not necessarily unit) tests to web module. Since I really prefer DRY I've chosen the latter. As a consequence there is a difficulty to use cobertura plugin (because the integration tests run in different phase and even in different module) and there is problem with JBoss tools (hopefully it's small). It might seem your proposal wont necessarily have those problems at a cost of duplicating some xml descriptors (components.xml isn't that big of a deal but navigation might be, especially fine grained one) But the more options/version we have before the real work starts the better I might actually use your solution to be able to use integration testing that doesn't involve navigation or security without all the drawbacks, so thanks for that! I am also quite familiar with the maven-eclipse-plugin, did you try JBoss Tools + WTP 2.0 (I mean exploded deployment here) with your solution (I expect it should work)?
          Hide
          Jason Grant
          added a comment -

          Just as a courtesy to those that follow, I'm not sure whether attachment #1 was ever tested. I'm working through it, and it is clearly not operational in the form submitted. So far, I've found the following:

          1) The parent to the top-level pom was not shipped. Once can be made from the content of org.jboss.seam:root:pom:2.1.0.A1
          2) The xxx group names are internally, inconsistent and require a fix.
          3) The deploy module referenced from the top pom is not present. I am hoping that it is not required.
          4) A seam.version property must be set.
          5) I removed the coupling to oracle.ojbc14
          6) Java does not compile due to absent import for SearchQueryCriterion

          I am still progressing with this, however these are the anomolies found so far.

          An operational submission would be most appreciated.

          Show
          Jason Grant
          added a comment - Just as a courtesy to those that follow, I'm not sure whether attachment #1 was ever tested. I'm working through it, and it is clearly not operational in the form submitted. So far, I've found the following: 1) The parent to the top-level pom was not shipped. Once can be made from the content of org.jboss.seam:root:pom:2.1.0.A1 2) The xxx group names are internally, inconsistent and require a fix. 3) The deploy module referenced from the top pom is not present. I am hoping that it is not required. 4) A seam.version property must be set. 5) I removed the coupling to oracle.ojbc14 6) Java does not compile due to absent import for SearchQueryCriterion I am still progressing with this, however these are the anomolies found so far. An operational submission would be most appreciated.
          Hide
          Jason Grant
          added a comment -

          Actually, the EJBs have been stripped from the zip too, so the tests refer to non-existent Java components.

          Thus, it's not an operational project.

          Show
          Jason Grant
          added a comment - Actually, the EJBs have been stripped from the zip too, so the tests refer to non-existent Java components. Thus, it's not an operational project.
          Hide
          Jason Grant
          added a comment -

          I've also tested attachment #2, even though some of the dependency versions seem old now.

          If I understand comment

          http://jira.jboss.org/jira/browse/JBSEAM-2371#action_12406363

          Comment [2] suggests that TestNG tests should be working via 'mvn test' in the web pom.

          Doesn't work for me. I get the exception below. Hopefully, this is due to a misunderstanding on my part.

          Running TestSuite
          org.apache.maven.surefire.booter.SurefireExecutionException: [Ljavax/el/ELResolver;; nested exception is java.lang.NoClassDefFoundError: [Ljavax/el/ELResolver;
          java.lang.NoClassDefFoundError: [Ljavax/el/ELResolver;
          at java.lang.Class.getDeclaredMethods0(Native Method)
          at java.lang.Class.privateGetDeclaredMethods(Class.java:2427)
          at java.lang.Class.getDeclaredMethods(Class.java:1791)
          at org.testng.internal.annotations.AnnotationHelper.findMethodsWithAnnotation(AnnotationHelper.java:197)
          at org.testng.internal.TestNGMethodFinder.getTestMethods(TestNGMethodFinder.java:47)
          at org.testng.TestClass.initMethods(TestClass.java:132)
          at org.testng.TestClass.init(TestClass.java:96)
          at org.testng.TestClass.<init>(TestClass.java:61)
          at org.testng.TestRunner.initMethods(TestRunner.java:288)
          at org.testng.TestRunner.init(TestRunner.java:212)
          at org.testng.TestRunner.init(TestRunner.java:184)
          at org.testng.TestRunner.<init>(TestRunner.java:121)
          at org.testng.SuiteRunner$DefaultTestRunnerFactory.newTestRunner(SuiteRunner.java:376)
          at org.testng.SuiteRunner.privateRun(SuiteRunner.java:196)
          at org.testng.SuiteRunner.run(SuiteRunner.java:145)
          at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:901)
          at org.testng.TestNG.runSuitesLocally(TestNG.java:863)
          at org.testng.TestNG.run(TestNG.java:613)
          at org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:62)
          at org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:136)
          at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
          at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
          at java.lang.reflect.Method.invoke(Method.java:597)
          at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:338)
          at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:997)
          Caused by: java.lang.ClassNotFoundException: javax.el.ELResolver
          at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
          at java.security.AccessController.doPrivileged(Native Method)
          at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
          at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
          at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276)
          at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
          at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)

          Show
          Jason Grant
          added a comment - I've also tested attachment #2, even though some of the dependency versions seem old now. If I understand comment http://jira.jboss.org/jira/browse/JBSEAM-2371#action_12406363 Comment [2] suggests that TestNG tests should be working via 'mvn test' in the web pom. Doesn't work for me. I get the exception below. Hopefully, this is due to a misunderstanding on my part. Running TestSuite org.apache.maven.surefire.booter.SurefireExecutionException: [Ljavax/el/ELResolver;; nested exception is java.lang.NoClassDefFoundError: [Ljavax/el/ELResolver; java.lang.NoClassDefFoundError: [Ljavax/el/ELResolver; at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Class.java:2427) at java.lang.Class.getDeclaredMethods(Class.java:1791) at org.testng.internal.annotations.AnnotationHelper.findMethodsWithAnnotation(AnnotationHelper.java:197) at org.testng.internal.TestNGMethodFinder.getTestMethods(TestNGMethodFinder.java:47) at org.testng.TestClass.initMethods(TestClass.java:132) at org.testng.TestClass.init(TestClass.java:96) at org.testng.TestClass.<init>(TestClass.java:61) at org.testng.TestRunner.initMethods(TestRunner.java:288) at org.testng.TestRunner.init(TestRunner.java:212) at org.testng.TestRunner.init(TestRunner.java:184) at org.testng.TestRunner.<init>(TestRunner.java:121) at org.testng.SuiteRunner$DefaultTestRunnerFactory.newTestRunner(SuiteRunner.java:376) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:196) at org.testng.SuiteRunner.run(SuiteRunner.java:145) at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:901) at org.testng.TestNG.runSuitesLocally(TestNG.java:863) at org.testng.TestNG.run(TestNG.java:613) at org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:62) at org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:136) at org.apache.maven.surefire.Surefire.run(Surefire.java:177) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:338) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:997) Caused by: java.lang.ClassNotFoundException: javax.el.ELResolver at java.net.URLClassLoader$1.run(URLClassLoader.java:200) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
          Hide
          Siarhei Dudzin
          added a comment -

          I can only speak for attachment #2 (testproject-master-JBSEAM-2371.zip).
          First, I need to know what maven version you use. And second - did you try to run mvn install from top level (or at least from ejb module level)? If you tried to run tests straight from web module and it doesn't have the ejb module installed in local repo yet (that's that dependency between web and ejb modules) it would be logical if web module can't resolve all depednencies.

          If you notice web module doesn't have java sources at all, and resolving all dependent project is done via reactor (thus by running from top level) or manually building dependent projects (thus first build ejb, then war).

          Hope that helps.

          Show
          Siarhei Dudzin
          added a comment - I can only speak for attachment #2 (testproject-master- JBSEAM-2371 .zip). First, I need to know what maven version you use. And second - did you try to run mvn install from top level (or at least from ejb module level)? If you tried to run tests straight from web module and it doesn't have the ejb module installed in local repo yet (that's that dependency between web and ejb modules) it would be logical if web module can't resolve all depednencies. If you notice web module doesn't have java sources at all, and resolving all dependent project is done via reactor (thus by running from top level) or manually building dependent projects (thus first build ejb, then war). Hope that helps.
          Hide
          Jason Grant
          added a comment -

          I am using maven 2.0.9 but will happily drop back to a prior edition if that will help. I get the same result under both Java 5 and 6.

          Yes, I certainly started with installs in the top dir, but had the same result. If I run 'mvn test' in the ejb dir, I get a successful build and test.

          Are there perhaps additional setup or configuration steps that are required? For example, I'm assuming no tomcat is required here, right? Also, I've just noticed the following properties in the bootstrap/conf dir, and cannot see them being set either in poms or via maven filters, etc.:

          jboss.embedded.bootstrap.resource.path
          jboss.server.data.dir
          jboss.bind.address
          jboss.home.dir

          To rule this out as a source of issues, I replaced them with absolute references to the correct local locations (i.e. within bootstrap dir), but the same exception (above) is produced.

          Show
          Jason Grant
          added a comment - I am using maven 2.0.9 but will happily drop back to a prior edition if that will help. I get the same result under both Java 5 and 6. Yes, I certainly started with installs in the top dir, but had the same result. If I run 'mvn test' in the ejb dir, I get a successful build and test. Are there perhaps additional setup or configuration steps that are required? For example, I'm assuming no tomcat is required here, right? Also, I've just noticed the following properties in the bootstrap/conf dir, and cannot see them being set either in poms or via maven filters, etc.: jboss.embedded.bootstrap.resource.path jboss.server.data.dir jboss.bind.address jboss.home.dir To rule this out as a source of issues, I replaced them with absolute references to the correct local locations (i.e. within bootstrap dir), but the same exception (above) is produced.
          Hide
          Hemant Saxena
          added a comment -

          hey Jason,

          I am sorry that you had the hard time to run it.

          maven-seam-microcontainer-testng-template.zip is the snapshot version of my working production code base .Due to code proprietary I strip off real name with xxx placeholder. The template was kept for the quick reference on how to align your pom to get this working. It wasn't intended to be the working one. I could have done that but I was pressed with timeline of my own project itself.

          towards your comments:

          1) The parent to the top-level pom was not shipped. Once can be made from the content of org.jboss.seam:root:pom:2.1.0.A1
          [comments]: yes you are correct, the zip is missing parent POM. I will again strip off proprietary stuff and put it as the attachment.

          2) The xxx group names are internally, inconsistent and require a fix.
          [comments]: as i said this done coz of proprieary code, you may remove jar or java which doesn;t make sense to you

          3) The deploy module referenced from the top pom is not present. I am hoping that it is not required.
          [comments]: Oooops this is copy mistake. You dont need deploy module there. We have this as the seperate assembly module.

          4) A seam.version property must be set.
          [comments]: you will find this in parent pom.

          5) I removed the coupling to oracle.ojbc14
          [comments]: thats okay.

          6) Java does not compile due to absent import for SearchQueryCriterion
          [comments]: remove any non compiling java because it is the snashot code and may have dependency on other things.

          And as soon as I get time, I will definitely place a operational copy of the template.

          Let me know if you have any other questions.

          Show
          Hemant Saxena
          added a comment - hey Jason, I am sorry that you had the hard time to run it. maven-seam-microcontainer-testng-template.zip is the snapshot version of my working production code base .Due to code proprietary I strip off real name with xxx placeholder. The template was kept for the quick reference on how to align your pom to get this working. It wasn't intended to be the working one. I could have done that but I was pressed with timeline of my own project itself. towards your comments: 1) The parent to the top-level pom was not shipped. Once can be made from the content of org.jboss.seam:root:pom:2.1.0.A1 [comments] : yes you are correct, the zip is missing parent POM. I will again strip off proprietary stuff and put it as the attachment. 2) The xxx group names are internally, inconsistent and require a fix. [comments] : as i said this done coz of proprieary code, you may remove jar or java which doesn;t make sense to you 3) The deploy module referenced from the top pom is not present. I am hoping that it is not required. [comments] : Oooops this is copy mistake. You dont need deploy module there. We have this as the seperate assembly module. 4) A seam.version property must be set. [comments] : you will find this in parent pom. 5) I removed the coupling to oracle.ojbc14 [comments] : thats okay. 6) Java does not compile due to absent import for SearchQueryCriterion [comments] : remove any non compiling java because it is the snashot code and may have dependency on other things. And as soon as I get time, I will definitely place a operational copy of the template. Let me know if you have any other questions.
          Hide
          Hemant Saxena
          added a comment -

          this is the parent pom for maven-seam-microcontainer-testng-template.zip.

          Show
          Hemant Saxena
          added a comment - this is the parent pom for maven-seam-microcontainer-testng-template.zip.
          Hide
          Siarhei Dudzin
          added a comment -

          Jason, it works with maven 2.0.8 and Java 6 (probably will work with Java 1.5 as well). I just downloaded the attachment, unzipped it and ran mvn clean install from the top level.

          My guess is that classpath ordering fix that was introduced in maven 2.0.9 actually breaks the build. I think it's a (test) classpath ordering problem of the project (not a bug in maven). Maven prior to 2.0.9 had test classpath ordering problems and many projects got broken when they switched to 2.0.9 because they actually were relying on the wrong classpath order (may be even without knowing it).

          Show
          Siarhei Dudzin
          added a comment - Jason, it works with maven 2.0.8 and Java 6 (probably will work with Java 1.5 as well). I just downloaded the attachment, unzipped it and ran mvn clean install from the top level. My guess is that classpath ordering fix that was introduced in maven 2.0.9 actually breaks the build. I think it's a (test) classpath ordering problem of the project (not a bug in maven). Maven prior to 2.0.9 had test classpath ordering problems and many projects got broken when they switched to 2.0.9 because they actually were relying on the wrong classpath order (may be even without knowing it).
          Hide
          Jason Grant
          added a comment -

          I've tried all combinations of Maven 2.0.8/2.0.9 and Java 1.5/1.6 but always the same exception during 'mvn install'

          Running TestSuite
          org.apache.maven.surefire.booter.SurefireExecutionException: [Ljavax/el/ELResolver;; nested exception is java.lang.NoClassDefFoundError: [Ljavax/el/ELResolver;
          java.lang.NoClassDefFoundError: [Ljavax/el/ELResolver;

          Still investigating...

          Show
          Jason Grant
          added a comment - I've tried all combinations of Maven 2.0.8/2.0.9 and Java 1.5/1.6 but always the same exception during 'mvn install' Running TestSuite org.apache.maven.surefire.booter.SurefireExecutionException: [Ljavax/el/ELResolver;; nested exception is java.lang.NoClassDefFoundError: [Ljavax/el/ELResolver; java.lang.NoClassDefFoundError: [Ljavax/el/ELResolver; Still investigating...
          Hide
          Jason Grant
          added a comment -

          Hmm, javax.el.ELResolver is in el-api.jar. This jar is not part of the surefire test classpath, as shown below.

          I'm currently wondering if a dependency has been incorrectly specified as 'provided' (however this would also break the test for other people too??)

          [DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-surefire-plugin:2.4.1:test' -->
          [DEBUG] (f) argLine = -Xmx256m
          [DEBUG] (f) basedir = /home/jasong/seam-experiments/seamtest2/testproject-master/testproject-web
          [DEBUG] (f) childDelegation = false
          [DEBUG] (f) classesDirectory = /home/jasong/seam-experiments/seamtest2/testproject-master/testproject-web/target/classes
          [DEBUG] (f) classpathElements = [/home/jasong/seam-experiments/seamtest2/testproject-master/testproject-web/target/test-classes, /home/jasong/seam-experiments/seamtest2/testproject-master/testproject-web/target/classes, /home/jasong/.m2/repository/org/richfaces/ui/richfaces-ui/3.1.3.GA/richfaces-ui-3.1.3.GA.jar, /home/jasong/.m2/repository/javax/persistence/persistence-api/1.0/persistence-api-1.0.jar, /home/jasong/.m2/repository/javax/servlet/servlet-api/2.5/servlet-api-2.5.jar, /home/jasong/.m2/repository/org/testng/testng/5.1/testng-5.1-jdk15.jar, /home/jasong/.m2/repository/junit/junit/4.4/junit-4.4.jar, /home/jasong/.m2/repository/org/jboss/seam/jboss-seam-ui/2.0.1.GA/jboss-seam-ui-2.0.1.GA.jar, /home/jasong/.m2/repository/org/jboss/seam/jboss-seam/2.0.1.GA/jboss-seam-2.0.1.GA.jar, /home/jasong/.m2/repository/jboss/javassist/3.3.ga/javassist-3.3.ga.jar, /home/jasong/.m2/repository/dom4j/dom4j/1.6.1-jboss/dom4j-1.6.1-jboss.jar, /home/jasong/.m2/repository/org/jboss/el/jboss-el/2.0.1.GA/jboss-el-2.0.1.GA.jar, /home/jasong/.m2/repository/commons-beanutils/commons-beanutils/1.7.0/commons-beanutils-1.7.0.jar, /home/jasong/.m2/repository/org/jboss/seam/embedded/thirdparty-all/beta3/thirdparty-all-beta3.jar, /home/jasong/.m2/repository/javax/faces/jsf-api/1.2_04-p02/jsf-api-1.2_04-p02.jar, /home/jasong/.m2/repository/org/jboss/seam/jboss-seam-debug/2.0.1.GA/jboss-seam-debug-2.0.1.GA.jar, /home/jasong/.m2/repository/com/sun/facelets/jsf-facelets/1.1.14/jsf-facelets-1.1.14.jar, /home/jasong/.m2/repository/org/hibernate/hibernate-validator/3.0.0.GA/hibernate-validator-3.0.0.GA.jar, /home/jasong/.m2/repository/log4j/log4j/1.2.14/log4j-1.2.14.jar, /home/jasong/.m2/repository/javax/faces/jsf-impl/1.2_04-p02/jsf-impl-1.2_04-p02.jar, /home/jasong/.m2/repository/org/jboss/seam/embedded/jboss-embedded-api/beta3/jboss-embedded-api-beta3.jar, /home/jasong/.m2/repository/org/jboss/microcontainer/jboss-deployers-client-spi/2.0.0.Beta6/jboss-deployers-client-spi-2.0.0.Beta6.jar, /home/jasong/.m2/repository/org/jboss/microcontainer/jboss-deployers-core-spi/2.0.0.Beta6/jboss-deployers-core-spi-2.0.0.Beta6.jar, /home/jasong/.m2/repository/org/hibernate/hibernate-annotations/3.3.0.ga/hibernate-annotations-3.3.0.ga.jar, /home/jasong/.m2/repository/org/hibernate/hibernate/3.2.4.sp1/hibernate-3.2.4.sp1.jar, /home/jasong/.m2/repository/javax/transaction/jta/1.0.1B/jta-1.0.1B.jar, /home/jasong/.m2/repository/asm/asm-attrs/1.5.3/asm-attrs-1.5.3.jar, /home/jasong/.m2/repository/antlr/antlr/2.7.6/antlr-2.7.6.jar, /home/jasong/.m2/repository/cglib/cglib/2.1_3/cglib-2.1_3.jar, /home/jasong/.m2/repository/asm/asm/1.5.3/asm-1.5.3.jar, /home/jasong/.m2/repository/commons-logging/commons-logging/1.1/commons-logging-1.1.jar, /home/jasong/.m2/repository/logkit/logkit/1.0.1/logkit-1.0.1.jar, /home/jasong/.m2/repository/avalon-framework/avalon-framework/4.1.3/avalon-framework-4.1.3.jar, /home/jasong/.m2/repository/org/jboss/seam/embedded/jboss-embedded-all/beta3/jboss-embedded-all-beta3.jar, /home/jasong/.m2/repository/org/hibernate/hibernate-entitymanager/3.3.1.ga/hibernate-entitymanager-3.3.1.ga.jar, /home/jasong/.m2/repository/org/hibernate/hibernate-commons-annotations/3.0.0.ga/hibernate-commons-annotations-3.0.0.ga.jar, /home/jasong/.m2/repository/jboss/jboss-common-core/2.0.4.GA/jboss-common-core-2.0.4.GA.jar, /home/jasong/.m2/repository/testproject/group/testproject/testproject-ejb/1.0-SNAPSHOT/testproject-ejb-1.0-SNAPSHOT.jar, /home/jasong/.m2/repository/org/jibx/jibx-extras/1.1.5/jibx-extras-1.1.5.jar, /home/jasong/.m2/repository/org/jibx/jibx-run/1.1.5/jibx-run-1.1.5.jar, /home/jasong/.m2/repository/org/codehaus/woodstox/wstx-asl/3.2.1/wstx-asl-3.2.1.jar, /home/jasong/.m2/repository/stax/stax-api/1.0.1/stax-api-1.0.1.jar]

          Show
          Jason Grant
          added a comment - Hmm, javax.el.ELResolver is in el-api.jar. This jar is not part of the surefire test classpath, as shown below. I'm currently wondering if a dependency has been incorrectly specified as 'provided' (however this would also break the test for other people too??) [DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-surefire-plugin:2.4.1:test' --> [DEBUG] (f) argLine = -Xmx256m [DEBUG] (f) basedir = /home/jasong/seam-experiments/seamtest2/testproject-master/testproject-web [DEBUG] (f) childDelegation = false [DEBUG] (f) classesDirectory = /home/jasong/seam-experiments/seamtest2/testproject-master/testproject-web/target/classes [DEBUG] (f) classpathElements = [/home/jasong/seam-experiments/seamtest2/testproject-master/testproject-web/target/test-classes, /home/jasong/seam-experiments/seamtest2/testproject-master/testproject-web/target/classes, /home/jasong/.m2/repository/org/richfaces/ui/richfaces-ui/3.1.3.GA/richfaces-ui-3.1.3.GA.jar, /home/jasong/.m2/repository/javax/persistence/persistence-api/1.0/persistence-api-1.0.jar, /home/jasong/.m2/repository/javax/servlet/servlet-api/2.5/servlet-api-2.5.jar, /home/jasong/.m2/repository/org/testng/testng/5.1/testng-5.1-jdk15.jar, /home/jasong/.m2/repository/junit/junit/4.4/junit-4.4.jar, /home/jasong/.m2/repository/org/jboss/seam/jboss-seam-ui/2.0.1.GA/jboss-seam-ui-2.0.1.GA.jar, /home/jasong/.m2/repository/org/jboss/seam/jboss-seam/2.0.1.GA/jboss-seam-2.0.1.GA.jar, /home/jasong/.m2/repository/jboss/javassist/3.3.ga/javassist-3.3.ga.jar, /home/jasong/.m2/repository/dom4j/dom4j/1.6.1-jboss/dom4j-1.6.1-jboss.jar, /home/jasong/.m2/repository/org/jboss/el/jboss-el/2.0.1.GA/jboss-el-2.0.1.GA.jar, /home/jasong/.m2/repository/commons-beanutils/commons-beanutils/1.7.0/commons-beanutils-1.7.0.jar, /home/jasong/.m2/repository/org/jboss/seam/embedded/thirdparty-all/beta3/thirdparty-all-beta3.jar, /home/jasong/.m2/repository/javax/faces/jsf-api/1.2_04-p02/jsf-api-1.2_04-p02.jar, /home/jasong/.m2/repository/org/jboss/seam/jboss-seam-debug/2.0.1.GA/jboss-seam-debug-2.0.1.GA.jar, /home/jasong/.m2/repository/com/sun/facelets/jsf-facelets/1.1.14/jsf-facelets-1.1.14.jar, /home/jasong/.m2/repository/org/hibernate/hibernate-validator/3.0.0.GA/hibernate-validator-3.0.0.GA.jar, /home/jasong/.m2/repository/log4j/log4j/1.2.14/log4j-1.2.14.jar, /home/jasong/.m2/repository/javax/faces/jsf-impl/1.2_04-p02/jsf-impl-1.2_04-p02.jar, /home/jasong/.m2/repository/org/jboss/seam/embedded/jboss-embedded-api/beta3/jboss-embedded-api-beta3.jar, /home/jasong/.m2/repository/org/jboss/microcontainer/jboss-deployers-client-spi/2.0.0.Beta6/jboss-deployers-client-spi-2.0.0.Beta6.jar, /home/jasong/.m2/repository/org/jboss/microcontainer/jboss-deployers-core-spi/2.0.0.Beta6/jboss-deployers-core-spi-2.0.0.Beta6.jar, /home/jasong/.m2/repository/org/hibernate/hibernate-annotations/3.3.0.ga/hibernate-annotations-3.3.0.ga.jar, /home/jasong/.m2/repository/org/hibernate/hibernate/3.2.4.sp1/hibernate-3.2.4.sp1.jar, /home/jasong/.m2/repository/javax/transaction/jta/1.0.1B/jta-1.0.1B.jar, /home/jasong/.m2/repository/asm/asm-attrs/1.5.3/asm-attrs-1.5.3.jar, /home/jasong/.m2/repository/antlr/antlr/2.7.6/antlr-2.7.6.jar, /home/jasong/.m2/repository/cglib/cglib/2.1_3/cglib-2.1_3.jar, /home/jasong/.m2/repository/asm/asm/1.5.3/asm-1.5.3.jar, /home/jasong/.m2/repository/commons-logging/commons-logging/1.1/commons-logging-1.1.jar, /home/jasong/.m2/repository/logkit/logkit/1.0.1/logkit-1.0.1.jar, /home/jasong/.m2/repository/avalon-framework/avalon-framework/4.1.3/avalon-framework-4.1.3.jar, /home/jasong/.m2/repository/org/jboss/seam/embedded/jboss-embedded-all/beta3/jboss-embedded-all-beta3.jar, /home/jasong/.m2/repository/org/hibernate/hibernate-entitymanager/3.3.1.ga/hibernate-entitymanager-3.3.1.ga.jar, /home/jasong/.m2/repository/org/hibernate/hibernate-commons-annotations/3.0.0.ga/hibernate-commons-annotations-3.0.0.ga.jar, /home/jasong/.m2/repository/jboss/jboss-common-core/2.0.4.GA/jboss-common-core-2.0.4.GA.jar, /home/jasong/.m2/repository/testproject/group/testproject/testproject-ejb/1.0-SNAPSHOT/testproject-ejb-1.0-SNAPSHOT.jar, /home/jasong/.m2/repository/org/jibx/jibx-extras/1.1.5/jibx-extras-1.1.5.jar, /home/jasong/.m2/repository/org/jibx/jibx-run/1.1.5/jibx-run-1.1.5.jar, /home/jasong/.m2/repository/org/codehaus/woodstox/wstx-asl/3.2.1/wstx-asl-3.2.1.jar, /home/jasong/.m2/repository/stax/stax-api/1.0.1/stax-api-1.0.1.jar]
          Hide
          Jason Grant
          added a comment -

          In fact, I think the other pertinent thing about the extract above is that the embedded-all jar is the towards the end of the classpath despite it being listed first in the parent pom. As mentioned by Siarhei Dudzin maven 2.0.9 constructs the classpath differently, however the *-all.jar dependencies still appear towards the end of the classpath.

          I am trying to understand why this is the case.

          Show
          Jason Grant
          added a comment - In fact, I think the other pertinent thing about the extract above is that the embedded-all jar is the towards the end of the classpath despite it being listed first in the parent pom. As mentioned by Siarhei Dudzin maven 2.0.9 constructs the classpath differently, however the *-all.jar dependencies still appear towards the end of the classpath. I am trying to understand why this is the case.
          Hide
          Jason Grant
          added a comment -

          I now have it working for me. Main fix was to include el-api.jar as a dependency in the web pom. I am unclear on how this was working for others.

          I also include the embedded dependencies at the top of the web pom. From what I've read, it is important that these occur first in the classpath. Without this, the surefire classpath in the web pom (as shown above) places the embedded jars towards the end of the classpath. The classpath creation algorithm is described here:

          http://jira.codehaus.org/browse/MNG-1412

          Hope this helps others.

          J.

          ----------------------------------
          My additions to testproject-web/pom.xml:
          ----------------------------------

          <dependencies>
          <!-- JG added for classpath -->
          <dependency>
          <groupId>org.jboss.seam.embedded</groupId>
          <artifactId>jboss-embedded-all</artifactId>
          <scope>test</scope>
          </dependency>
          <dependency>
          <groupId>org.jboss.seam.embedded</groupId>
          <artifactId>thirdparty-all</artifactId>
          <scope>test</scope>
          </dependency>
          <dependency>
          <groupId>org.jboss.seam.embedded</groupId>
          <artifactId>jboss-embedded-api</artifactId>
          <scope>test</scope>
          </dependency>

          <!-- JG added for classpath -->
          <dependency>
          <groupId>javax.el</groupId>
          <artifactId>el-api</artifactId>
          <scope>test</scope>
          </dependency>

          ...

          Show
          Jason Grant
          added a comment - I now have it working for me. Main fix was to include el-api.jar as a dependency in the web pom. I am unclear on how this was working for others. I also include the embedded dependencies at the top of the web pom. From what I've read, it is important that these occur first in the classpath. Without this, the surefire classpath in the web pom (as shown above) places the embedded jars towards the end of the classpath. The classpath creation algorithm is described here: http://jira.codehaus.org/browse/MNG-1412 Hope this helps others. J. ---------------------------------- My additions to testproject-web/pom.xml: ---------------------------------- <dependencies> <!-- JG added for classpath --> <dependency> <groupId>org.jboss.seam.embedded</groupId> <artifactId>jboss-embedded-all</artifactId> <scope>test</scope> </dependency> <dependency> <groupId>org.jboss.seam.embedded</groupId> <artifactId>thirdparty-all</artifactId> <scope>test</scope> </dependency> <dependency> <groupId>org.jboss.seam.embedded</groupId> <artifactId>jboss-embedded-api</artifactId> <scope>test</scope> </dependency> <!-- JG added for classpath --> <dependency> <groupId>javax.el</groupId> <artifactId>el-api</artifactId> <scope>test</scope> </dependency> ...
          Hide
          Siarhei Dudzin
          added a comment -

          Jason, El-api is in provided scope, it is also in provided scope in jboss-seam-2.0.1.GA.pom. Provided scope is used within test phase (http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope) and even propagated through transitive dependencies. So the scope is not the problem.

          I've cleaned up my local repository, made sure I have java 5 as runtime (java -version).
          After that I did 'mvn clean install' on top level. All tests passed!
          After that all artifacts supposed to be in my local repo, so just to make sure I've ran 'mvn test' from the web module and it passed! I simply can not break the build!
          I checked testproject-master/testproject-web/target/surefire-reports/TEST-TestSuite.xml and property surefire.test.class.path does contain el-api-1.0.jar which in turn does have the ELResolver.
          In this file I also see that all the jar's are sorted properly.

          This is what I get if I run 'mvn dependency:tree -Dverbose -Dincludes=javax.el' from the web module:
          [dependency:tree]
          testproject.group.testproject:testproject-web:war:1.0-SNAPSHOT
          - org.jboss.seam:jboss-seam:jar:2.0.1.GA:provided (scope not updated to compile)
          - org.jboss.el:jboss-el:jar:2.0.1.GA:provided
          - javax.el:el-api:jar:1.0:provided
          It clearly shows how javax.el is resolved for the project.

          So it does seem to be your local problem.

          Although putting el-api in test scope fixes your problem, it's not the real problem! Because provided dependencies are used in test phase and they are also propagated as transient you should have had el-api in your test classpath.

          There are a number of possible reasons why you might have the problem:

          • you modified a pom and the dependency tree is now different
          • you have another project in your local repo with the same groupId/artifactId which somehow conflicts with any of the artifacts
          • you have custom settings.xml which define different repositories which might give you an artifact with different transitive dependencies

          There might be more but these are that popped up in my mind as I counted to 3

          p.s. may be it is a good idea to post such kind of problems on forum? This JIRA issue is getting very long and maven tests aren't even officially supported yet!

          Show
          Siarhei Dudzin
          added a comment - Jason, El-api is in provided scope, it is also in provided scope in jboss-seam-2.0.1.GA.pom. Provided scope is used within test phase ( http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope ) and even propagated through transitive dependencies. So the scope is not the problem. I've cleaned up my local repository, made sure I have java 5 as runtime (java -version). After that I did 'mvn clean install' on top level. All tests passed! After that all artifacts supposed to be in my local repo, so just to make sure I've ran 'mvn test' from the web module and it passed! I simply can not break the build! I checked testproject-master/testproject-web/target/surefire-reports/TEST-TestSuite.xml and property surefire.test.class.path does contain el-api-1.0.jar which in turn does have the ELResolver. In this file I also see that all the jar's are sorted properly. This is what I get if I run 'mvn dependency:tree -Dverbose -Dincludes=javax.el' from the web module: [dependency:tree] testproject.group.testproject:testproject-web:war:1.0-SNAPSHOT - org.jboss.seam:jboss-seam:jar:2.0.1.GA:provided (scope not updated to compile) - org.jboss.el:jboss-el:jar:2.0.1.GA:provided - javax.el:el-api:jar:1.0:provided It clearly shows how javax.el is resolved for the project. So it does seem to be your local problem. Although putting el-api in test scope fixes your problem, it's not the real problem! Because provided dependencies are used in test phase and they are also propagated as transient you should have had el-api in your test classpath. There are a number of possible reasons why you might have the problem: you modified a pom and the dependency tree is now different you have another project in your local repo with the same groupId/artifactId which somehow conflicts with any of the artifacts you have custom settings.xml which define different repositories which might give you an artifact with different transitive dependencies There might be more but these are that popped up in my mind as I counted to 3 p.s. may be it is a good idea to post such kind of problems on forum? This JIRA issue is getting very long and maven tests aren't even officially supported yet!
          Hide
          Jason Grant
          added a comment -

          Thankyou for invesitgating this issue, and making suggestions. I will take further discussion to the forum, if you wish.

          In particular, I have used Hemant's approach to get the SeamTests working for the booking sample under Java 1.6 and Seam 2.1.0A1, and will publish it after some final cleanup.

          Show
          Jason Grant
          added a comment - Thankyou for invesitgating this issue, and making suggestions. I will take further discussion to the forum, if you wish. In particular, I have used Hemant's approach to get the SeamTests working for the booking sample under Java 1.6 and Seam 2.1.0A1, and will publish it after some final cleanup.
          Hide
          Jason Grant
          added a comment -

          I'm attaching jg-seamtest-1.0.tgz. It represents a self-contained demo of how to use SeamTest with Java 6, maven 2.0.9, Seam 2.1.0A1, and TestNG 5.8. I've done this by adapting Hemant's archive as follows:

          • The parent pom simply imports org.jboss.seam:root to get all seam dependency versions. This is a maven 2.0.9 feature, and permits use of libraries like seam whilst inheriting from something else.
          • The source code for EJBs and TestNG tests was taken from the Seam booking demo.
          • There is only one ejb module. In the test/resources dir, resides minimal webapp config that is purely used for testing in the embedded container.
          • I've stripped out all unnecessary content (e.g. reporting); I simply wanted to establish the minimum required to do a SeamTest.

          I will post to the forum also, since this may be of wider interest.

          Show
          Jason Grant
          added a comment - I'm attaching jg-seamtest-1.0.tgz. It represents a self-contained demo of how to use SeamTest with Java 6, maven 2.0.9, Seam 2.1.0A1, and TestNG 5.8. I've done this by adapting Hemant's archive as follows: The parent pom simply imports org.jboss.seam:root to get all seam dependency versions. This is a maven 2.0.9 feature, and permits use of libraries like seam whilst inheriting from something else. The source code for EJBs and TestNG tests was taken from the Seam booking demo. There is only one ejb module. In the test/resources dir, resides minimal webapp config that is purely used for testing in the embedded container. I've stripped out all unnecessary content (e.g. reporting); I simply wanted to establish the minimum required to do a SeamTest. I will post to the forum also, since this may be of wider interest.
          Hide
          ajordens
          added a comment -

          Decided to come back to this as I was going to attempt to upgrade to Java6 and Maven 2.0.9.

          Is your archive complete? I would have expected to just uncompress it and do a mvn test? Before I dig into any details, I just want to make sure that's the expectation.

          It looked to be referencing a jboss-embedded-bootstrap artifact that I couldn't find documented anywhere.

          Show
          ajordens
          added a comment - Decided to come back to this as I was going to attempt to upgrade to Java6 and Maven 2.0.9. Is your archive complete? I would have expected to just uncompress it and do a mvn test? Before I dig into any details, I just want to make sure that's the expectation. It looked to be referencing a jboss-embedded-bootstrap artifact that I couldn't find documented anywhere.
          Hide
          Mariusz Smykula
          added a comment -

          What is jboss-embedded-bootstrap.zip? How to make this?

          Show
          Mariusz Smykula
          added a comment - What is jboss-embedded-bootstrap.zip? How to make this?
          Hide
          Jason Grant
          added a comment -

          If you want to adopt this technique, you'll need to create your own bootstrap archive from the dir of the same name under your seam installation, then import it into a convenient local repository. There is no need to use this approach - you could develop an alternatie technique to store/copy the bootstrap config files as suits your needs - e.g. use antrun to pull it from your seam install instead of unpacking a zip from your repo.

          Show
          Jason Grant
          added a comment - If you want to adopt this technique, you'll need to create your own bootstrap archive from the dir of the same name under your seam installation, then import it into a convenient local repository. There is no need to use this approach - you could develop an alternatie technique to store/copy the bootstrap config files as suits your needs - e.g. use antrun to pull it from your seam install instead of unpacking a zip from your repo.
          Hide
          Mariusz Smykula
          added a comment -

          Thanks for help, I have some problem with your demo project.

          
          

          *** CONTEXTS MISSING DEPENDENCIES: Name -> Dependency

          {Required State:Actual State}

          jboss.jdbc:datasource=pentabidsDatasource,service=metadata
          -> jboss.jdbc:service=metadata

          {Create:** NOT FOUND **}

          -> jboss.jdbc:service=metadata

          {Start:** NOT FOUND **}
              • CONTEXTS IN ERROR: Name -> Error
                jboss.jdbc:service=metadata -> ** NOT FOUND ** {/code}

          Btw, is this technique useful for testing in ear project with multiple linked ejb beans?

          Show
          Mariusz Smykula
          added a comment - Thanks for help, I have some problem with your demo project. *** CONTEXTS MISSING DEPENDENCIES: Name -> Dependency {Required State:Actual State} jboss.jdbc:datasource=pentabidsDatasource,service=metadata -> jboss.jdbc:service=metadata {Create:** NOT FOUND **} -> jboss.jdbc:service=metadata {Start:** NOT FOUND **} CONTEXTS IN ERROR: Name -> Error jboss.jdbc:service=metadata -> ** NOT FOUND ** {/code} Btw, is this technique useful for testing in ear project with multiple linked ejb beans?
          Hide
          Mariusz Smykula
          added a comment -

          Forgot about my previous question, I changed my project layout but I always have this result:

          [INFO] [compiler:testCompile]
          [INFO] Compiling 1 source file to C:\seam\project-ejb-main\target\test-classes
          [INFO] [surefire:test]
          [INFO] Surefire report directory: C:\seam\project-ejb-main\target\surefire-reports
          Usage: java [-options] class [args...]
          (to execute a class)
          or java [-options] -jar jarfile [args...]
          (to execute a jar file)

          where options include: ............

          I think my project look like your example, what could be wrong?

          Show
          Mariusz Smykula
          added a comment - Forgot about my previous question, I changed my project layout but I always have this result: [INFO] [compiler:testCompile] [INFO] Compiling 1 source file to C:\seam\project-ejb-main\target\test-classes [INFO] [surefire:test] [INFO] Surefire report directory: C:\seam\project-ejb-main\target\surefire-reports Usage: java [-options] class [args...] (to execute a class) or java [-options] -jar jarfile [args...] (to execute a jar file) where options include: ............ I think my project look like your example, what could be wrong?
          Hide
          Geoffrey De Smet
          added a comment -

          The seam download zip doesn't contain the embedded bootstrap jar.

          Here's the maven error when running "mvn test":
          Embedded error: Unable to download the artifact from any repository
          ...
          org.jboss.embedded:jboss-embedded-bootstrap:zip:beta3

          Where can I find this mystical jar (preferable with pom) and any chance it can be deployed to the jboss repo to make our live a bit easier?

          Show
          Geoffrey De Smet
          added a comment - The seam download zip doesn't contain the embedded bootstrap jar. Here's the maven error when running "mvn test": Embedded error: Unable to download the artifact from any repository ... org.jboss.embedded:jboss-embedded-bootstrap:zip:beta3 Where can I find this mystical jar (preferable with pom) and any chance it can be deployed to the jboss repo to make our live a bit easier?
          Hide
          Ben Groeneveld
          added a comment -

          Thanks for the great work! We've downloaded the testproject-master-JBSEAM-2371.zip, added the dependency patch Jason describes as <!-- JG added for classpath --> and this works well. Needed to up the version of TestNG to 5.8 because the @BeforeClass annotation fails otherwise. We need @BeforeClass because we use a modified SeamTest that loads only one Hibernate session factory for a group or suite. We have also added dbunit support which brings in dependency conflict for xerces, but that was resolved by adding it also to the dependencies Jason added. Note that these must appear first in order to debug with TestNG in eclipse. This is our first maven project and so far we have found a maven solution for each of our hurdles - nice.

          Show
          Ben Groeneveld
          added a comment - Thanks for the great work! We've downloaded the testproject-master- JBSEAM-2371 .zip, added the dependency patch Jason describes as <!-- JG added for classpath --> and this works well. Needed to up the version of TestNG to 5.8 because the @BeforeClass annotation fails otherwise. We need @BeforeClass because we use a modified SeamTest that loads only one Hibernate session factory for a group or suite. We have also added dbunit support which brings in dependency conflict for xerces, but that was resolved by adding it also to the dependencies Jason added. Note that these must appear first in order to debug with TestNG in eclipse. This is our first maven project and so far we have found a maven solution for each of our hurdles - nice.
          Hide
          Fred Bricon
          added a comment -

          Hi,

          FWIW, I've released seam-ear-archetype at http://code.google.com/p/open-archetypes/
          it will generate a nested multi module project, allowing you to run integration tests (i.e. using the embedded JBoss) both compatible with eclipse (m2eclipse 0.9.9 and testng plugin required) and maven.

          It's an early version, so it will assume you already created a mysql database having the same name as your main artifact, and it's targeted at running on JBoss 5. I'm currently testing JBoss Tools integration.

          regards,

          Fred Bricon

          Show
          Fred Bricon
          added a comment - Hi, FWIW, I've released seam-ear-archetype at http://code.google.com/p/open-archetypes/ it will generate a nested multi module project, allowing you to run integration tests (i.e. using the embedded JBoss) both compatible with eclipse (m2eclipse 0.9.9 and testng plugin required) and maven. It's an early version, so it will assume you already created a mysql database having the same name as your main artifact, and it's targeted at running on JBoss 5. I'm currently testing JBoss Tools integration. regards, Fred Bricon
          Hide
          Marek Novotny
          added a comment -

          this is core task for migration of Seam to Maven

          Show
          Marek Novotny
          added a comment - this is core task for migration of Seam to Maven
          Hide
          Marek Novotny
          added a comment -

          All examples except WIKI are using maven and integration testing with JBoss Embedded as in-memory container.

          Show
          Marek Novotny
          added a comment - All examples except WIKI are using maven and integration testing with JBoss Embedded as in-memory container.

            People

            • Assignee:
              Marek Novotny
              Reporter:
              Siarhei Dudzin
            • Votes:
              68 Vote for this issue
              Watchers:
              54 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: