Guys and girls, In the interest of moving things forward, I'm going to shortly start working on the beta 2 release. There are still some issues that we're working through with the multi-container testsuite configuration, however with some help I've been able to resurrect the existing tests in Solder to run in the latest version of Arquillian and I'm confident that I can get the tests in the other modules passing successfully without too much trouble. I would still like us to press on with the test suite work, however I don't want it to hold up the release schedule. Since the Beta1 release there have been a couple of important changes, which I'll quickly summarise here: 1) seam-parent is now at the top of the food chain and no longer inherits its configuration from weld-parent. This change is good for a couple of reasons, first of all the disassociation from the Weld project will help to reinforce that Seam is CDI implementation-independent. Secondly it gives us total control over configuration for the Maven plugins that we use, allowing us to update the plugin versions (which I've already done, to the latest version of each plugin) and fine tune the plugin configuration parameters for Seam. 2) I've decided against moving the logging feature out of Solder and into its own module for now, as I discovered that it was too tightly coupled to Solder to "de-tangle" it easily. I have however refactored the logging API classes into their own package, org.jboss.seam.logging which I think will be more intuitive for our users. I believe that the Solder reference documentation still needs to be updated in response to the changes made for SOLDER-102 (http://issues.jboss.org/browse/SOLDER-102) - Ken, could you please confirm? If so, would you be willing to update the reference docs to reflect the logging changes? I am aiming for the Beta2 release this coming weekend, which means with our 20+ modules now I need to get started pretty soon. If anyone has any spare cycles and is able to help out with this, it would be greatly appreciated. Each module needs to have its tests fixed, logging refactored to use the new logging API package, and its distribution thoroughly checked for correctness/completeness. If you'd like to volunteer for a module or two, please catch me on IRC and we can work it out there. Thanks, Shane _______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev

Great, thanks John. FYI, the new version for seam-parent will be 13 (I have yet to release it but will get to it early tomorrow). Also, the latest assembly plugin requires that you specify an id for the assembly. Simply adding the following snippet to dist/src/main/assembly/assembly.xml should fix it: <id>distribution</id> Shane On 22/08/11 20:44, John D. Ament wrote: > I have cycles this week. At a minimum, I'll take care of JCR and > JMS. If anyone else has any modules they need help with let me know. > > John > > On Mon, Aug 22, 2011 at 5:48 AM, Shane Bryzak <sbryzak(a)redhat.com > <mailto:sbryzak@redhat.com>> wrote: > > Guys and girls, > > In the interest of moving things forward, I'm going to shortly start > working on the beta 2 release. There are still some issues that > we're > working through with the multi-container testsuite configuration, > however with some help I've been able to resurrect the existing > tests in > Solder to run in the latest version of Arquillian and I'm > confident that > I can get the tests in the other modules passing successfully without > too much trouble. I would still like us to press on with the > test suite > work, however I don't want it to hold up the release schedule. > > Since the Beta1 release there have been a couple of important > changes, > which I'll quickly summarise here: > > 1) seam-parent is now at the top of the food chain and no longer > inherits its configuration from weld-parent. This change is good > for a > couple of reasons, first of all the disassociation from the Weld > project > will help to reinforce that Seam is CDI implementation-independent. > Secondly it gives us total control over configuration for the Maven > plugins that we use, allowing us to update the plugin versions (which > I've already done, to the latest version of each plugin) and fine > tune > the plugin configuration parameters for Seam. > > 2) I've decided against moving the logging feature out of Solder and > into its own module for now, as I discovered that it was too tightly > coupled to Solder to "de-tangle" it easily. I have however > refactored > the logging API classes into their own package, > org.jboss.seam.logging > which I think will be more intuitive for our users. I believe > that the > Solder reference documentation still needs to be updated in > response to > the changes made for SOLDER-102 > (http://issues.jboss.org/browse/SOLDER-102) - Ken, could you please > confirm? If so, would you be willing to update the reference docs to > reflect the logging changes? > > I am aiming for the Beta2 release this coming weekend, which > means with > our 20+ modules now I need to get started pretty soon. If anyone has > any spare cycles and is able to help out with this, it would be > greatly > appreciated. Each module needs to have its tests fixed, logging > refactored to use the new logging API package, and its distribution > thoroughly checked for correctness/completeness. If you'd like to > volunteer for a module or two, please catch me on IRC and we can > work it > out there. > > Thanks, > Shane > _______________________________________________ > 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 https://lists.jboss.org/mailman/listinfo/seam-dev

Hi Shane, I have managed to run (more or less, with 1 failure and 4 errors) the new Solder testsuite on AS7 (the jbossas-managed-7 profile) with the following changes: 1. removing the <forkMode>always</forkMode> from testsuite/internals/jbossas/pom.xml as it breaks the MavenArtifactResolver. The other option for this issue is to hack the MavenArtifactResolver to deal with the way surefirebooter works with forking, see the commented out parts in MavenArtifactResolver.java in https://github.com/maschmid/solder/compare/develop...testsuitecleanup 2. add the "Dependencies: org.jboss.logging,org.jboss.logmanager" to the seam-logger jar manifest, as no solder test archive gets deployed on AS7 without it. 3. Upgrade arquillian.version and arquillian.jboss7.version to 1.0.0.CR4, as I get java.lang.NoClassDefFoundError: org/jboss/arquillian/container/spi/client/protocol/metadata/JMXContext exception with CR1 for some strange reason. (org.jboss.seam.solder.test.el.ElTest and org.jboss.seam.solder.test.resourceLoader.ResourceLoaderTest are broken because the "targetContainerAdapterClass" hack doesn't work anymore. Cheers, Marek Schmidt On 08/22/2011 11:48 AM, Shane Bryzak wrote: > Guys and girls, > > In the interest of moving things forward, I'm going to shortly start > working on the beta 2 release. There are still some issues that we're > working through with the multi-container testsuite configuration, > however with some help I've been able to resurrect the existing tests in > Solder to run in the latest version of Arquillian and I'm confident that > I can get the tests in the other modules passing successfully without > too much trouble. I would still like us to press on with the test suite > work, however I don't want it to hold up the release schedule. > > Since the Beta1 release there have been a couple of important changes, > which I'll quickly summarise here: > > 1) seam-parent is now at the top of the food chain and no longer > inherits its configuration from weld-parent. This change is good for a > couple of reasons, first of all the disassociation from the Weld project > will help to reinforce that Seam is CDI implementation-independent. > Secondly it gives us total control over configuration for the Maven > plugins that we use, allowing us to update the plugin versions (which > I've already done, to the latest version of each plugin) and fine tune > the plugin configuration parameters for Seam. > > 2) I've decided against moving the logging feature out of Solder and > into its own module for now, as I discovered that it was too tightly > coupled to Solder to "de-tangle" it easily. I have however refactored > the logging API classes into their own package, org.jboss.seam.logging > which I think will be more intuitive for our users. I believe that the > Solder reference documentation still needs to be updated in response to > the changes made for SOLDER-102 > (http://issues.jboss.org/browse/SOLDER-102) - Ken, could you please > confirm? If so, would you be willing to update the reference docs to > reflect the logging changes? > > I am aiming for the Beta2 release this coming weekend, which means with > our 20+ modules now I need to get started pretty soon. If anyone has > any spare cycles and is able to help out with this, it would be greatly > appreciated. Each module needs to have its tests fixed, logging > refactored to use the new logging API package, and its distribution > thoroughly checked for correctness/completeness. If you'd like to > volunteer for a module or two, please catch me on IRC and we can work it > out there. > > Thanks, > Shane > _______________________________________________ > seam-dev mailing list > seam-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/seam-dev

On 23/08/2011, at 8:52 PM, Marek Schmidt wrote: > Hi Shane, > > I have managed to run (more or less, with 1 failure and 4 errors) the > new Solder testsuite on AS7 (the jbossas-managed-7 profile) > > with the following changes: > > 1. removing the <forkMode>always</forkMode> from > testsuite/internals/jbossas/pom.xml as it breaks the > MavenArtifactResolver. > > The other option for this issue is to hack the MavenArtifactResolver to > deal with the way surefirebooter works with forking, see the commented > out parts in MavenArtifactResolver.java in > > https://github.com/maschmid/solder/compare/develop…testsuitecleanup Arquillian / Shrinkwrap have a proper non-hacky artefact resolver now (called MavenDependencyResolver), I am not really sure how to use it though, you would have to ask Aslak or ALR.

Stuart > > 2. add the "Dependencies: org.jboss.logging,org.jboss.logmanager" to the > seam-logger jar manifest, as no solder test archive gets deployed on AS7 > without it. > > 3. Upgrade arquillian.version and arquillian.jboss7.version to > 1.0.0.CR4, as I get > > java.lang.NoClassDefFoundError: > org/jboss/arquillian/container/spi/client/protocol/metadata/JMXContext > > exception with CR1 for some strange reason. > > The transitive dependencies have probably changed. I think that class is in arquillian-container-spi. Stuart > > (org.jboss.seam.solder.test.el.ElTest and > org.jboss.seam.solder.test.resourceLoader.ResourceLoaderTest are broken > because the "targetContainerAdapterClass" hack doesn't work anymore. > > > Cheers, > > Marek Schmidt > > > On 08/22/2011 11:48 AM, Shane Bryzak wrote: >> Guys and girls, >> >> In the interest of moving things forward, I'm going to shortly start >> working on the beta 2 release. There are still some issues that we're >> working through with the multi-container testsuite configuration, >> however with some help I've been able to resurrect the existing tests in >> Solder to run in the latest version of Arquillian and I'm confident that >> I can get the tests in the other modules passing successfully without >> too much trouble. I would still like us to press on with the test suite >> work, however I don't want it to hold up the release schedule. >> >> Since the Beta1 release there have been a couple of important changes, >> which I'll quickly summarise here: >> >> 1) seam-parent is now at the top of the food chain and no longer >> inherits its configuration from weld-parent. This change is good for a >> couple of reasons, first of all the disassociation from the Weld project >> will help to reinforce that Seam is CDI implementation-independent. >> Secondly it gives us total control over configuration for the Maven >> plugins that we use, allowing us to update the plugin versions (which >> I've already done, to the latest version of each plugin) and fine tune >> the plugin configuration parameters for Seam. >> >> 2) I've decided against moving the logging feature out of Solder and >> into its own module for now, as I discovered that it was too tightly >> coupled to Solder to "de-tangle" it easily. I have however refactored >> the logging API classes into their own package, org.jboss.seam.logging >> which I think will be more intuitive for our users. I believe that the >> Solder reference documentation still needs to be updated in response to >> the changes made for SOLDER-102 >> (http://issues.jboss.org/browse/SOLDER-102) - Ken, could you please >> confirm? If so, would you be willing to update the reference docs to >> reflect the logging changes? >> >> I am aiming for the Beta2 release this coming weekend, which means with >> our 20+ modules now I need to get started pretty soon. If anyone has >> any spare cycles and is able to help out with this, it would be greatly >> appreciated. Each module needs to have its tests fixed, logging >> refactored to use the new logging API package, and its distribution >> thoroughly checked for correctness/completeness. If you'd like to >> volunteer for a module or two, please catch me on IRC and we can work it >> out there. >> >> Thanks, >> Shane >> _______________________________________________ >> 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