Arquillian Testsuite structure for Modules
by Ken Finnigan
All,
I've committed the work on the Arquillian testsuite infrastructure on the
i18n module which can be found here:
https://github.com/seam/international/tree/develop/testsuite
Here are some notes on how it's structured and what needs to be done:
- API and Impl modules still retain unit tests that don't require
container testing
- testsuite/common includes Deployment and Library helpers and anything
that would be common to multiple types of testsuites, such as internals,
smoke, etc
- The helpers from this module could potentially be pulled up into a
common module for all, but that may introduce complexity in
trying to use it
in each module so may be best to leave it there for the moment
and see how
it goes
- testsuite/container-boms contains the container definition for weld ee
embedded and AS7. Others can be found at
https://github.com/mojavelinux/arquillian-showcase/tree/master/container-...
- One of the first things that needs to happen is these container-boms
need to be created in a seam parent module of some kind such that each
module can utilize them without having to replicate the content directly
- testsuite/internals/base contains the test classes that used to be
within impl. For i18n I was able to leave the entirety of the test classes
in the bases module and simply explode it into the target/test-classes
directory of the testsuite/internals/${container} modules as part of the
integration-test phase.
- To make it easier to then explode the jar built from this module
into sub modules, the test classes and resources actually need to be in
src/main. As we don't plan using the jar built from this for
anything other
than testing it's not an issue.
- container tests are only activated on the integration-test phase and
skipped on the basic test phase
- https://github.com/seam/international/blob/develop/testsuite/README.mdout...
all the proposed types of suites that testsuite can contain. I
believe an initial first step should be to move the existing container
tests, or create some, for the internals module. Over time we can then look
to flesh out the testsuite with additional types such as smoke, cluster,
api, etc
- One area that I haven't looked at yet is code coverage given that the
tests are further spread than previously. I'm hoping that it will be
relatively easy to amalgamate all the coverage data to produce a single
report.
Any questions about this please let me know.
Ken
12 years, 8 months
Re: [seam-dev] Arquillian Testsuite structure for Modules
by George Gastaldi
Check the reports pom. I fixed that by adding a dependencymanagement section
Em 20/08/2011, às 20:38, Shane Bryzak <sbryzak(a)redhat.com> escreveu:
It was my fault, there was a hard-coded arquillian dependency (for an older
version of Arquillian) in the Solder impl.
On 21/08/11 09:28, John D. Ament wrote:
Do you have shrinkwrap descriptor api and impl in your reps somewhere?
John (sent from my DroidX)
On Aug 20, 2011 7:20 PM, "Shane Bryzak" <sbryzak(a)redhat.com> wrote:
> I'm just experimenting with this configuration now in Solder, however
> I'm getting the following exception when I run the tests - anyone seen
> this before?
>
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.244
> sec <<< FAILURE!
>
initializationError(org.jboss.seam.solder.test.resourceLoader.ResourceLoaderTest)
> Time elapsed: 0.004 sec <<< ERROR!
> java.lang.NoClassDefFoundError: org/jboss/shrinkwrap/descriptor/api/Node
> at java.lang.Class.getDeclaredConstructors0(Native Method)
> at java.lang.Class.privateGetDeclaredConstructors(Class.java:2389)
> at java.lang.Class.getConstructor0(Class.java:2699)
> at java.lang.Class.getConstructor(Class.java:1657)
> at
>
org.jboss.shrinkwrap.descriptor.impl.base.DescriptorImporterBase.from(DescriptorImporterBase.java:145)
> at
>
org.jboss.arquillian.impl.bootstrap.ConfigurationRegistrar.loadConfiguration(ConfigurationRegistrar.java:50)
>
> On 21/08/11 09:18, John D. Ament wrote:
>>
>> I am willing to convert seam JCR to this to see how it runs.
>>
>> John
>>
>> On Aug 20, 2011 7:17 PM, "George Gastaldi" <gegastaldi(a)gmail.com
>> <mailto:gegastaldi@gmail.com>> wrote:
>> > +1 to the multiple sources idea
>> >
>> > Em 20/08/2011, às 20:01, Shane Bryzak <sbryzak(a)redhat.com
>> <mailto:sbryzak@redhat.com>> escreveu:
>> >
>> > We could possibly do it by specifying additional source directories
>> for each
>> > profile.
>> >
>> >
>>
http://chadthedeveloper.blogspot.com/2008/02/maven2-multiple-source-direc...
>> >
>> > On 21/08/11 08:59, Jason Porter wrote:
>> >
>> > Can we add additional tests with this though for each container?
>> >
>> > Sent from my iPhone
>> >
>> > On Aug 20, 2011, at 16:35, Shane Bryzak <sbryzak(a)redhat.com
>> <mailto:sbryzak@redhat.com>> wrote:
>> >
>> > That might be one way we can do it - Ken, what do you think about
>> > structuring the test suite like this?
>> >
>> > https://gist.github.com/1155271
>> >
>> >
>> > On 21/08/11 08:27, Jason Porter wrote:
>> >
>> > Maybe something in surefire, or what aslak said on twitter may be
>> helpful.
>> >
>> > Sent from my iPhone
>> >
>> > On Aug 20, 2011, at 16:21, Shane Bryzak <sbryzak(a)redhat.com
>> <mailto:sbryzak@redhat.com>> wrote:
>> >
>> > I'm currently looking into it.
>> >
>> > On 21/08/11 08:04, Jason Porter wrote:
>> >
>> > Is it possible to add a source directory or test directory?
>> >
>> > Sent from my iPhone
>> >
>> > On Aug 20, 2011, at 15:36, Shane Bryzak <sbryzak(a)redhat.com
>> <mailto:sbryzak@redhat.com>> wrote:
>> >
>> > Unfortunately that doesn't work - the issue occurs when the artifacts
>> > being unpacked are in the same reactor. See
>> > http://jira.codehaus.org/browse/MDEP-98
>> >
>> > On 21/08/11 01:11, Ken Finnigan wrote:
>> >
>> > If I'm not mistaken, that error is resolved by installing the
artifacts.
>> >
>> > The problem is that it doesn't know how to unpack a directory, so
>> the jar
>> > with the test classes needs to be installed for it to work
>> >
>> > Ken
>> >
>> > Sent from my iPhone
>> >
>> > On Aug 20, 2011, at 11:02, Shane Bryzak <sbryzak(a)redhat.com
>> <mailto:sbryzak@redhat.com>> wrote:
>> >
>> > I've made some progress in this area, so far I've created a few of the
>> > container boms in seam-parent and also started converting the Solder
>> tests
>> > to use the new structure.
>> >
>> > I have run into one issue though - when running the tests I'm
>> encountering
>> > the error below. The reason it hasn't manifested in the International
>> > module is because there was a version mismatch between some of the test
>> > suite artifacts, however if you synchronize them all you get the
>> same error.
>> >
>> > [INFO] Reactor Summary:
>> > [INFO]
>> > [INFO] Seam International Test Suite: Aggregator ......... SUCCESS
>> [1.224s]
>> > [INFO] Seam Container BOMs Aggregator .................... SUCCESS
>> [0.025s]
>> > [INFO] Weld EE Embedded 1.1 Container .................... SUCCESS
>> [0.899s]
>> > [INFO] JBoss AS7 Managed Container ....................... SUCCESS
>> [2.722s]
>> > [INFO] Seam International Test Suite Common .............. SUCCESS
>> [0.376s]
>> > [INFO] Seam International Test Suite: Internals Integration Tests
>> SUCCESS
>> > [0.013s]
>> > [INFO] Seam International Test Suite: Internals Integration Tests Base
>> > SUCCESS [0.743s]
>> > [INFO] Seam International Test Suite: Internals Integration Tests
>> for JBoss
>> > AS FAILURE [2.529s]
>> > [INFO] Seam International Test Suite: Internals Integration Tests
>> for Weld
>> > EE Embedded SKIPPED
>> > [INFO]
>> >
------------------------------------------------------------------------
>> > [INFO] BUILD FAILURE
>> > [INFO]
>> >
------------------------------------------------------------------------
>> > [INFO] Total time: 9.393s
>> > [INFO] Finished at: Sun Aug 21 00:55:38 EST 2011
>> > [INFO] Final Memory: 25M/348M
>> > [INFO]
>> >
------------------------------------------------------------------------
>> > [ERROR] Failed to execute goal
>> > org.apache.maven.plugins:maven-dependency-plugin:2.1:unpack
>> > (unpack-base-tests) on project
>> > seam-international-testsuite-integration-internals-jbossas: Error
>> unpacking
>> > file:
>> >
>>
/home/shane/project/seam/international/testsuite/internals/base/target/classes
>> > to:
>> >
>>
/home/shane/project/seam/international/testsuite/internals/jbossas/target/test-classes
>> > [ERROR] org.codehaus.plexus.archiver.ArchiverException: The source
>> must not
>> > be a directory.
>> > [ERROR] -> [Help 1]
>> >
>> >
>> > I've spent a little time trying to find a workaround but it seems
>> that this
>> > has been a known bug in Maven for at least 4 years. If anyone wants
>> to take
>> > a look at this and try to figure out a workaround in the meantime
>> please be
>> > my guest.
>> >
>> > Shane
>> >
>> >
>> > On 30/07/11 12:16, Ken Finnigan wrote:
>> >
>> > All,
>> >
>> > I've committed the work on the Arquillian testsuite infrastructure
>> on the
>> > i18n module which can be found here:
>> > https://github.com/seam/international/tree/develop/testsuite
>> >
>> > Here are some notes on how it's structured and what needs to be done:
>> >
>> >
>> > - API and Impl modules still retain unit tests that don't require
>> > container testing
>> > - testsuite/common includes Deployment and Library helpers and anything
>> > that would be common to multiple types of testsuites, such as
internals,
>> > smoke, etc
>> > - The helpers from this module could potentially be pulled up into a
>> > common module for all, but that may introduce complexity in
>> > trying to use it
>> > in each module so may be best to leave it there for the moment
>> > and see how
>> > it goes
>> > - testsuite/container-boms contains the container definition for weld
ee
>> > embedded and AS7. Others can be found at
>> >
>>
https://github.com/mojavelinux/arquillian-showcase/tree/master/container-...
>> > - One of the first things that needs to happen is these container-boms
>> > need to be created in a seam parent module of some kind such that each
>> > module can utilize them without having to replicate the content
directly
>> > - testsuite/internals/base contains the test classes that used to be
>> > within impl. For i18n I was able to leave the entirety of the test
>> classes
>> > in the bases module and simply explode it into the target/test-classes
>> > directory of the testsuite/internals/${container} modules as part of
the
>> > integration-test phase.
>> > - To make it easier to then explode the jar built from this module
>> > into sub modules, the test classes and resources actually need to be in
>> > src/main. As we don't plan using the jar built from this for
>> > anything other
>> > than testing it's not an issue.
>> > - container tests are only activated on the integration-test phase
>> > and skipped on the basic test phase
>> > -
>>
https://github.com/seam/international/blob/develop/testsuite/README.mdout...
>> > all the proposed types of suites that testsuite can contain. I
>> > believe an initial first step should be to move the existing container
>> > tests, or create some, for the internals module. Over time we can
>> then look
>> > to flesh out the testsuite with additional types such as smoke,
cluster,
>> > api, etc
>> > - One area that I haven't looked at yet is code coverage given that the
>> > tests are further spread than previously. I'm hoping that it will be
>> > relatively easy to amalgamate all the coverage data to produce a single
>> > report.
>> >
>> > Any questions about this please let me know.
>> >
>> > Ken
>> >
>> >
>> > _______________________________________________
>> > seam-dev mailing
>> >
>> listseam-dev@lists.jboss.orghttps://
lists.jboss.org/mailman/listinfo/seam-dev
>> <http://lists.jboss.org/mailman/listinfo/seam-dev>
>> >
>> >
>> >
>> > _______________________________________________
>> > seam-dev mailing list
>> > seam-dev(a)lists.jboss.org <mailto:seam-dev@lists.jboss.org>
>> > https://lists.jboss.org/mailman/listinfo/seam-dev
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > seam-dev mailing list
>> > seam-dev(a)lists.jboss.org <mailto:seam-dev@lists.jboss.org>
>> > https://lists.jboss.org/mailman/listinfo/seam-dev
>
12 years, 8 months
Re: [seam-dev] Arquillian Testsuite structure for Modules
by George Gastaldi
+1 to the multiple sources idea
Em 20/08/2011, às 20:01, Shane Bryzak <sbryzak(a)redhat.com> escreveu:
We could possibly do it by specifying additional source directories for each
profile.
http://chadthedeveloper.blogspot.com/2008/02/maven2-multiple-source-direc...
On 21/08/11 08:59, Jason Porter wrote:
Can we add additional tests with this though for each container?
Sent from my iPhone
On Aug 20, 2011, at 16:35, Shane Bryzak <sbryzak(a)redhat.com> wrote:
That might be one way we can do it - Ken, what do you think about
structuring the test suite like this?
https://gist.github.com/1155271
On 21/08/11 08:27, Jason Porter wrote:
Maybe something in surefire, or what aslak said on twitter may be helpful.
Sent from my iPhone
On Aug 20, 2011, at 16:21, Shane Bryzak <sbryzak(a)redhat.com> wrote:
I'm currently looking into it.
On 21/08/11 08:04, Jason Porter wrote:
Is it possible to add a source directory or test directory?
Sent from my iPhone
On Aug 20, 2011, at 15:36, Shane Bryzak <sbryzak(a)redhat.com> wrote:
Unfortunately that doesn't work - the issue occurs when the artifacts
being unpacked are in the same reactor. See
http://jira.codehaus.org/browse/MDEP-98
On 21/08/11 01:11, Ken Finnigan wrote:
If I'm not mistaken, that error is resolved by installing the artifacts.
The problem is that it doesn't know how to unpack a directory, so the jar
with the test classes needs to be installed for it to work
Ken
Sent from my iPhone
On Aug 20, 2011, at 11:02, Shane Bryzak <sbryzak(a)redhat.com> wrote:
I've made some progress in this area, so far I've created a few of the
container boms in seam-parent and also started converting the Solder tests
to use the new structure.
I have run into one issue though - when running the tests I'm encountering
the error below. The reason it hasn't manifested in the International
module is because there was a version mismatch between some of the test
suite artifacts, however if you synchronize them all you get the same error.
[INFO] Reactor Summary:
[INFO]
[INFO] Seam International Test Suite: Aggregator ......... SUCCESS [1.224s]
[INFO] Seam Container BOMs Aggregator .................... SUCCESS [0.025s]
[INFO] Weld EE Embedded 1.1 Container .................... SUCCESS [0.899s]
[INFO] JBoss AS7 Managed Container ....................... SUCCESS [2.722s]
[INFO] Seam International Test Suite Common .............. SUCCESS [0.376s]
[INFO] Seam International Test Suite: Internals Integration Tests SUCCESS
[0.013s]
[INFO] Seam International Test Suite: Internals Integration Tests Base
SUCCESS [0.743s]
[INFO] Seam International Test Suite: Internals Integration Tests for JBoss
AS FAILURE [2.529s]
[INFO] Seam International Test Suite: Internals Integration Tests for Weld
EE Embedded SKIPPED
[INFO]
------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO]
------------------------------------------------------------------------
[INFO] Total time: 9.393s
[INFO] Finished at: Sun Aug 21 00:55:38 EST 2011
[INFO] Final Memory: 25M/348M
[INFO]
------------------------------------------------------------------------
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-dependency-plugin:2.1:unpack
(unpack-base-tests) on project
seam-international-testsuite-integration-internals-jbossas: Error unpacking
file:
/home/shane/project/seam/international/testsuite/internals/base/target/classes
to:
/home/shane/project/seam/international/testsuite/internals/jbossas/target/test-classes
[ERROR] org.codehaus.plexus.archiver.ArchiverException: The source must not
be a directory.
[ERROR] -> [Help 1]
I've spent a little time trying to find a workaround but it seems that this
has been a known bug in Maven for at least 4 years. If anyone wants to take
a look at this and try to figure out a workaround in the meantime please be
my guest.
Shane
On 30/07/11 12:16, Ken Finnigan wrote:
All,
I've committed the work on the Arquillian testsuite infrastructure on the
i18n module which can be found here:
https://github.com/seam/international/tree/develop/testsuite
Here are some notes on how it's structured and what needs to be done:
- API and Impl modules still retain unit tests that don't require
container testing
- testsuite/common includes Deployment and Library helpers and anything
that would be common to multiple types of testsuites, such as internals,
smoke, etc
- The helpers from this module could potentially be pulled up into a
common module for all, but that may introduce complexity in
trying to use it
in each module so may be best to leave it there for the moment
and see how
it goes
- testsuite/container-boms contains the container definition for weld ee
embedded and AS7. Others can be found at
https://github.com/mojavelinux/arquillian-showcase/tree/master/container-...
- One of the first things that needs to happen is these container-boms
need to be created in a seam parent module of some kind such that each
module can utilize them without having to replicate the content directly
- testsuite/internals/base contains the test classes that used to be
within impl. For i18n I was able to leave the entirety of the test classes
in the bases module and simply explode it into the target/test-classes
directory of the testsuite/internals/${container} modules as part of the
integration-test phase.
- To make it easier to then explode the jar built from this module
into sub modules, the test classes and resources actually need to be in
src/main. As we don't plan using the jar built from this for
anything other
than testing it's not an issue.
- container tests are only activated on the integration-test phase
and skipped on the basic test phase
- https://github.com/seam/international/blob/develop/testsuite/README.mdout...
all the proposed types of suites that testsuite can contain. I
believe an initial first step should be to move the existing container
tests, or create some, for the internals module. Over time we can then look
to flesh out the testsuite with additional types such as smoke, cluster,
api, etc
- One area that I haven't looked at yet is code coverage given that the
tests are further spread than previously. I'm hoping that it will be
relatively easy to amalgamate all the coverage data to produce a single
report.
Any questions about this please let me know.
Ken
_______________________________________________
seam-dev mailing
listseam-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/seam-dev
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
12 years, 8 months
Re: [seam-dev] Arquillian Testsuite structure for Modules
by Cody Lerum
Same issue I am seeing with mail.
On Aug 20, 2011, at 5:20 PM, Shane Bryzak <sbryzak(a)redhat.com> wrote:
I'm just experimenting with this configuration now in Solder, however I'm
getting the following exception when I run the tests - anyone seen this
before?
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.244 sec
<<< FAILURE!
initializationError(org.jboss.seam.solder.test.resourceLoader.ResourceLoaderTest)
Time elapsed: 0.004 sec <<< ERROR!
java.lang.NoClassDefFoundError: org/jboss/shrinkwrap/descriptor/api/Node
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Class.java:2389)
at java.lang.Class.getConstructor0(Class.java:2699)
at java.lang.Class.getConstructor(Class.java:1657)
at
org.jboss.shrinkwrap.descriptor.impl.base.DescriptorImporterBase.from(DescriptorImporterBase.java:145)
at
org.jboss.arquillian.impl.bootstrap.ConfigurationRegistrar.loadConfiguration(ConfigurationRegistrar.java:50)
On 21/08/11 09:18, John D. Ament wrote:
I am willing to convert seam JCR to this to see how it runs.
John
On Aug 20, 2011 7:17 PM, "George Gastaldi" <gegastaldi(a)gmail.com> wrote:
> +1 to the multiple sources idea
>
> Em 20/08/2011, às 20:01, Shane Bryzak <sbryzak(a)redhat.com> escreveu:
>
> We could possibly do it by specifying additional source directories for
each
> profile.
>
>
http://chadthedeveloper.blogspot.com/2008/02/maven2-multiple-source-direc...
>
> On 21/08/11 08:59, Jason Porter wrote:
>
> Can we add additional tests with this though for each container?
>
> Sent from my iPhone
>
> On Aug 20, 2011, at 16:35, Shane Bryzak <sbryzak(a)redhat.com> wrote:
>
> That might be one way we can do it - Ken, what do you think about
> structuring the test suite like this?
>
> https://gist.github.com/1155271
>
>
> On 21/08/11 08:27, Jason Porter wrote:
>
> Maybe something in surefire, or what aslak said on twitter may be helpful.
>
> Sent from my iPhone
>
> On Aug 20, 2011, at 16:21, Shane Bryzak <sbryzak(a)redhat.com> wrote:
>
> I'm currently looking into it.
>
> On 21/08/11 08:04, Jason Porter wrote:
>
> Is it possible to add a source directory or test directory?
>
> Sent from my iPhone
>
> On Aug 20, 2011, at 15:36, Shane Bryzak <sbryzak(a)redhat.com> wrote:
>
> Unfortunately that doesn't work - the issue occurs when the artifacts
> being unpacked are in the same reactor. See
> http://jira.codehaus.org/browse/MDEP-98
>
> On 21/08/11 01:11, Ken Finnigan wrote:
>
> If I'm not mistaken, that error is resolved by installing the artifacts.
>
> The problem is that it doesn't know how to unpack a directory, so the jar
> with the test classes needs to be installed for it to work
>
> Ken
>
> Sent from my iPhone
>
> On Aug 20, 2011, at 11:02, Shane Bryzak <sbryzak(a)redhat.com> wrote:
>
> I've made some progress in this area, so far I've created a few of the
> container boms in seam-parent and also started converting the Solder tests
> to use the new structure.
>
> I have run into one issue though - when running the tests I'm encountering
> the error below. The reason it hasn't manifested in the International
> module is because there was a version mismatch between some of the test
> suite artifacts, however if you synchronize them all you get the same
error.
>
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Seam International Test Suite: Aggregator ......... SUCCESS
[1.224s]
> [INFO] Seam Container BOMs Aggregator .................... SUCCESS
[0.025s]
> [INFO] Weld EE Embedded 1.1 Container .................... SUCCESS
[0.899s]
> [INFO] JBoss AS7 Managed Container ....................... SUCCESS
[2.722s]
> [INFO] Seam International Test Suite Common .............. SUCCESS
[0.376s]
> [INFO] Seam International Test Suite: Internals Integration Tests SUCCESS
> [0.013s]
> [INFO] Seam International Test Suite: Internals Integration Tests Base
> SUCCESS [0.743s]
> [INFO] Seam International Test Suite: Internals Integration Tests for
JBoss
> AS FAILURE [2.529s]
> [INFO] Seam International Test Suite: Internals Integration Tests for Weld
> EE Embedded SKIPPED
> [INFO]
> ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Total time: 9.393s
> [INFO] Finished at: Sun Aug 21 00:55:38 EST 2011
> [INFO] Final Memory: 25M/348M
> [INFO]
> ------------------------------------------------------------------------
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-dependency-plugin:2.1:unpack
> (unpack-base-tests) on project
> seam-international-testsuite-integration-internals-jbossas: Error
unpacking
> file:
>
/home/shane/project/seam/international/testsuite/internals/base/target/classes
> to:
>
/home/shane/project/seam/international/testsuite/internals/jbossas/target/test-classes
> [ERROR] org.codehaus.plexus.archiver.ArchiverException: The source must
not
> be a directory.
> [ERROR] -> [Help 1]
>
>
> I've spent a little time trying to find a workaround but it seems that
this
> has been a known bug in Maven for at least 4 years. If anyone wants to
take
> a look at this and try to figure out a workaround in the meantime please
be
> my guest.
>
> Shane
>
>
> On 30/07/11 12:16, Ken Finnigan wrote:
>
> All,
>
> I've committed the work on the Arquillian testsuite infrastructure on the
> i18n module which can be found here:
> https://github.com/seam/international/tree/develop/testsuite
>
> Here are some notes on how it's structured and what needs to be done:
>
>
> - API and Impl modules still retain unit tests that don't require
> container testing
> - testsuite/common includes Deployment and Library helpers and anything
> that would be common to multiple types of testsuites, such as internals,
> smoke, etc
> - The helpers from this module could potentially be pulled up into a
> common module for all, but that may introduce complexity in
> trying to use it
> in each module so may be best to leave it there for the moment
> and see how
> it goes
> - testsuite/container-boms contains the container definition for weld ee
> embedded and AS7. Others can be found at
>
https://github.com/mojavelinux/arquillian-showcase/tree/master/container-...
> - One of the first things that needs to happen is these container-boms
> need to be created in a seam parent module of some kind such that each
> module can utilize them without having to replicate the content directly
> - testsuite/internals/base contains the test classes that used to be
> within impl. For i18n I was able to leave the entirety of the test classes
> in the bases module and simply explode it into the target/test-classes
> directory of the testsuite/internals/${container} modules as part of the
> integration-test phase.
> - To make it easier to then explode the jar built from this module
> into sub modules, the test classes and resources actually need to be in
> src/main. As we don't plan using the jar built from this for
> anything other
> than testing it's not an issue.
> - container tests are only activated on the integration-test phase
> and skipped on the basic test phase
> -
https://github.com/seam/international/blob/develop/testsuite/README.mdout...
> all the proposed types of suites that testsuite can contain. I
> believe an initial first step should be to move the existing container
> tests, or create some, for the internals module. Over time we can then
look
> to flesh out the testsuite with additional types such as smoke, cluster,
> api, etc
> - One area that I haven't looked at yet is code coverage given that the
> tests are further spread than previously. I'm hoping that it will be
> relatively easy to amalgamate all the coverage data to produce a single
> report.
>
> Any questions about this please let me know.
>
> Ken
>
>
> _______________________________________________
> seam-dev mailing
> listseam-dev@lists.jboss.orghttps://
lists.jboss.org/mailman/listinfo/seam-dev
>
>
>
> _______________________________________________
> seam-dev mailing list
> seam-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-dev
>
>
>
>
> _______________________________________________
> seam-dev mailing list
> seam-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-dev
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
12 years, 8 months
Using jboss-logging in your AS7 app
by Shane Bryzak
Hey guys,
In case you don't know how to do this already, to set up your app to use
jboss-logging in AS7 you need to add the following line to the
META-INF/MANIFEST.MF file in your deployment:
Dependencies: org.jboss.logging,org.jboss.logmanager
The easiest way is to automate this as part of your Maven build by
adding the following snippet to your pom.xml. Here's an example:
<build>
<finalName>seam-university</finalName>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<configuration>
<failOnMissingWebXml>false</failOnMissingWebXml>
<archive>
<manifestEntries>
<Dependencies>org.slf4j.impl,org.jboss.logging,org.jboss.logmanager</Dependencies>
</manifestEntries>
</archive>
</configuration>
</plugin>
Stuart has also written a great article about class loading in AS7,
which you can find at
https://docs.jboss.org/author/display/AS7/Class+Loading+in+AS7 - I
recommend that all Seam devs read it.
Thanks to Stuart for the above tip, and for the article. Module leads,
can you please update your examples if they use jboss-logging (most
examples, if not all will most likely use it indirectly through solder).
Shane
12 years, 8 months
seam-parent overhaul
by Shane Bryzak
I've done some work to seam-parent already, removing weld-parent from
the hierarchy, updating all the plugin versions and some general
cleanup. I have a bunch of questions though, if anyone can answer any
of these it will save me a lot of time:
1) Do we require both junit and testng?
2) Do we use mockito?
3) We have a number of Weld dependencies: weld-api, weld-core, weld-se,
weld-se-core, weld-servlet - where/how are these being used?
4) org.apache.openjpa:openjpa-all - what uses this?
5) org.hsqldb:hsqldb - do we use this?
6) org.subethamail:subethasmtp - where is this used?
7) com.sun.jersey:jersey-bundle and
com.sun.jersey.contribs:jersey-multipart - what are these/where are they
used?
8) Container-related:
org.jboss.jbossas:jboss-server-manager
org.jboss.jbossas:jboss-as-client
org.mortbay.jetty:jetty
org.mortbay.jetty:jsp-2.1-jetty
org.mortbay.jetty:jetty-naming
org.mortbay.jetty:jetty-plus
org.eclipse.jetty:jetty-webapp
org.eclipse.jetty:jetty-plus
org.glassfish.deployment:deployment-client
- Are these dependencies here purely for testing purposes?
9) There are two emma plugins - org.codehaus.mojo:emma-maven-plugin and
org.sonatype.maven.plugin:emma4it-maven-plugin, do we need both?
(actually, i think one is used for instrumentation, and one for
reporting - can someone pls confirm this?)
12 years, 8 months
Fwd: Seam Mail review
by Cody Lerum
The layout is something I am definitely on board with changing. It
just kind of sprawled over time after getting opinions on layout from
others. There the bulk of everything is the seam mail "core" and then
there is an impl for each of the template engines supported.
It is probably possible to just have a api and impl as the specific
template impls (FreeMarkerTemplate, VelocityTemplate, RenderTemplate)
should only throw a NoClassDefFoundError if someone tries to use them
and doesn't include the engine in their pom...which could be
documented in the ref docs.
Thoughts?
On Sun, Aug 14, 2011 at 5:06 PM, Shane Bryzak <sbryzak(a)redhat.com> wrote:
> Hi Cody,
>
> I've just spent some time going over Seam Mail and preparing it for the
> release, however I've discovered a number of items that I think still need
> some work before it can go out:
>
> 1) Seam mail core - I think that the core module should be removed and this
> should just become seam-mail-api, and (possibly, I'll get back to this
> shortly) seam-mail (the implementation). This would bring the module into
> conformity with other modules that follow a similar structure of one api,
> multiple implementations.
>
> 2) Evaluate whether the sub-module currently called seam-module-core-impl is
> necessary. It seems to me that this contains classes that the user might
> use directly, in which case they should go into the API module. If they are
> classes that don't actually belong in the API, then maybe a submodule called
> seam-mail-common might make more sense if they are implementation classes
> common to both the Velocity and Freemarker implementations.
>
> 3) The implementations need a minor restructure - the impl directory in both
> the Freemarker and Velocity implementations is redundant, these submodules
> can go directly in their respective sub-dirs. Also, the artifacts should be
> renamed to seam-mail-freemarker and seam-mail-velocity.
>
> 4) The seam-render sub-module. What is this for exactly? It only contains
> one class, RenderTemplate - can this go into the impl or seam-mail-common
> perhaps?
>
> 5) The distribution is broken. Running mvn clean install -Drelease produces
> a distribution archive that seems to be missing a whole bunch of stuff,
> including the actual project artifacts.
>
> If anyone is able to help Cody out with these items it would be greatly
> appreciated, as I know he little spare time to spend on the mail module at
> the moment. Likewise, I have my hands tied up with the release right now so
> if we're going to get the mail module into the 3.1.0.Beta1 release then
> we'll need a kind volunteer to help out with it.
>
> Thanks,
> Shane
>
12 years, 9 months
Seam 2 -> Seam 3 Migration Strategy
by Lincoln Baxter, III
Hi Guys,
I'd like to start implementing a Seam 2 -> Seam 3 plugin for Forge, so that
we can give people *Something* to get started with this process. My vision
at this point is to specify a list of tasks for the plugin to perform, E.g.
- Updating the POM to include new dependencies
- Replacing Seam 2 annotations with Seam 3 annotations
- Getting basic configuration files set up
- Doing some static code analysis in order to print a list of tasks that
need to be done by hand (sort of a "what do I have left?")
In order to accomplish this, having *never* used Seam 2, I need a few
things:
1. A list of APIs and which Seam 3 feature replaces it - this includes
annotations, static classes, and injected interfaces/classes.
2. A test project with all of these features (or at least a lot of them.)
As soon as I have these things, I will get started, and anyone who wants to
help out and work on this as well is more than welcome to join me!
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
12 years, 9 months
Seam Mail review
by Shane Bryzak
Hi Cody,
I've just spent some time going over Seam Mail and preparing it for the
release, however I've discovered a number of items that I think still
need some work before it can go out:
1) Seam mail core - I think that the core module should be removed and
this should just become seam-mail-api, and (possibly, I'll get back to
this shortly) seam-mail (the implementation). This would bring the
module into conformity with other modules that follow a similar
structure of one api, multiple implementations.
2) Evaluate whether the sub-module currently called
seam-module-core-impl is necessary. It seems to me that this contains
classes that the user might use directly, in which case they should go
into the API module. If they are classes that don't actually belong in
the API, then maybe a submodule called seam-mail-common might make more
sense if they are implementation classes common to both the Velocity and
Freemarker implementations.
3) The implementations need a minor restructure - the impl directory in
both the Freemarker and Velocity implementations is redundant, these
submodules can go directly in their respective sub-dirs. Also, the
artifacts should be renamed to seam-mail-freemarker and seam-mail-velocity.
4) The seam-render sub-module. What is this for exactly? It only
contains one class, RenderTemplate - can this go into the impl or
seam-mail-common perhaps?
5) The distribution is broken. Running mvn clean install -Drelease
produces a distribution archive that seems to be missing a whole bunch
of stuff, including the actual project artifacts.
If anyone is able to help Cody out with these items it would be greatly
appreciated, as I know he little spare time to spend on the mail module
at the moment. Likewise, I have my hands tied up with the release right
now so if we're going to get the mail module into the 3.1.0.Beta1
release then we'll need a kind volunteer to help out with it.
Thanks,
Shane
12 years, 9 months