The container boms should be pulled in. Anything else would be be a bit of a headache to maintain and make generic enough for everyone to use.<br><br><div class="gmail_quote">On Mon, Aug 8, 2011 at 17:28, Shane Bryzak <span dir="ltr">&lt;<a href="mailto:sbryzak@redhat.com">sbryzak@redhat.com</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    Ken, I&#39;d like this to be adopted as the standard for all modules. 
    Which common dependencies do you think we should put in seam-parent
    to make it easier for them?  <br><div><div></div><div class="h5">
    <br>
    On 30/07/11 12:16, Ken Finnigan wrote:
    </div></div><blockquote type="cite"><div><div></div><div class="h5">All,<br>
      <br>
      I&#39;ve committed the work on the Arquillian testsuite infrastructure
      on the i18n module which can be found here: <a href="https://github.com/seam/international/tree/develop/testsuite" target="_blank">https://github.com/seam/international/tree/develop/testsuite</a><br>
      <br>
      Here are some notes on how it&#39;s structured and what needs to be
      done:<br>
      <br>
      <ul>
        <li>API and Impl modules still retain unit tests that don&#39;t
          require container testing</li>
        <li>testsuite/common includes Deployment and Library helpers and
          anything that would be common to multiple types of testsuites,
          such as internals, smoke, etc</li>
        <ul>
          <li>The helpers from this module could potentially be pulled
            up into a common module for all, but that may introduce
            complexity in trying to use it in each module so may be best
            to leave it there for the moment and see how it goes</li>
        </ul>
        <li>testsuite/container-boms contains the container definition
          for weld ee embedded and AS7.  Others can be found at <a href="https://github.com/mojavelinux/arquillian-showcase/tree/master/container-boms" target="_blank">https://github.com/mojavelinux/arquillian-showcase/tree/master/container-boms</a></li>


        <ul>
          <li>One of the first things that needs to happen is these
            container-boms need to be created in a seam parent module of
            some kind such that each module can utilize them without
            having to replicate the content directly</li>
        </ul>
        <li>testsuite/internals/base contains the test classes that used
          to be within impl.  For i18n I was able to leave the entirety
          of the test classes in the bases module and simply explode it
          into the target/test-classes directory of the
          testsuite/internals/${container} modules as part of the
          integration-test phase.</li>
        <ul>
          <li>To make it easier to then explode the jar built from this
            module into sub modules, the test classes and resources
            actually need to be in src/main.  As we don&#39;t plan using the
            jar built from this for anything other than testing it&#39;s not
            an issue.<br>
          </li>
        </ul>
        <li>container tests are only activated on the integration-test
          phase and skipped on the basic test phase</li>
        <li><a href="https://github.com/seam/international/blob/develop/testsuite/README.md" target="_blank">https://github.com/seam/international/blob/develop/testsuite/README.md</a>
          outlines all the proposed types of suites that testsuite can
          contain.  I believe an initial first step should be to move
          the existing container tests, or create some, for the
          internals module.  Over time we can then look to flesh out the
          testsuite with additional types such as smoke, cluster, api,
          etc</li>
        <li>One area that I haven&#39;t looked at yet is code coverage given
          that the tests are further spread than previously.  I&#39;m hoping
          that it will be relatively easy to amalgamate all the coverage
          data to produce a single report.</li>
      </ul>
      Any questions about this please let me know.<br>
      <br>
      Ken<br>
      <br>
      <fieldset></fieldset>
      <br>
      </div></div><div class="im"><pre>_______________________________________________
seam-dev mailing list
<a href="mailto:seam-dev@lists.jboss.org" target="_blank">seam-dev@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/seam-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/seam-dev</a>
</pre>
    </div></blockquote>
    <br>
  </div>

<br>_______________________________________________<br>
seam-dev mailing list<br>
<a href="mailto:seam-dev@lists.jboss.org">seam-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/seam-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/seam-dev</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Jason Porter<br><a href="http://lightguard-jp.blogspot.com" target="_blank">http://lightguard-jp.blogspot.com</a><br><a href="http://twitter.com/lightguardjp" target="_blank">http://twitter.com/lightguardjp</a><br>

<br>Software Engineer<br>Open Source Advocate<br>Author of Seam Catch - Next Generation Java Exception Handling<br><br>PGP key id: 926CCFF5<br>PGP key available at: <a href="http://keyserver.net" target="_blank">keyserver.net</a>, <a href="http://pgp.mit.edu" target="_blank">pgp.mit.edu</a><br>