Hey guys, I'm going to start the wheels rolling on the beta release, though first I need to know if all modules are ready to go. If your module is in the following list, can you please let me know if it's ready for inclusion in the Seam beta: Seam Catch Seam International Seam JMS Seam REST Seam Servlet If you're still waiting for a Solder release, then the good news is you have a little more time as we won't be packaging the beta until the current Glassfish issues with Solder are resolved. Either way, can you please let me know the current status of your module. Thanks, Shane _______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev

Hi Shane, Seam International is waiting on a Solder release, and some other items that I'm currently working on. There are some API changes coming, so would be great to get them in before the first Beta, but if that can't happen is everyone ok with me making the changes between Beta releases? Thanks Ken On Fri, Jan 21, 2011 at 5:42 AM, Shane Bryzak <sbryzak(a)redhat.com <mailto:sbryzak@redhat.com>> wrote: Hey guys, I'm going to start the wheels rolling on the beta release, though first I need to know if all modules are ready to go. If your module is in the following list, can you please let me know if it's ready for inclusion in the Seam beta: Seam Catch Seam International Seam JMS Seam REST Seam Servlet If you're still waiting for a Solder release, then the good news is you have a little more time as we won't be packaging the beta until the current Glassfish issues with Solder are resolved. Either way, can you please let me know the current status of your module. 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

On Fri, Jan 21, 2011 at 15:50, Shane Bryzak <sbryzak(a)redhat.com&gt; wrote: > Realistically you probably have a couple more days before we sort out the > Solder issues with Glassfish, I need to catch up with Dan first and find out > what the current status is. If you could get the API changes done before > then, then great, otherwise we'll have to make them between betas. > As you are aware, we have to sort out the Solder issues on GlassFish. We want to solve this problem in the most efficient manner as possible, which we believe is by using Arquillian to get the Solder test suite to run on GlassFish (allowing us to work inside the IDE and debugger). We will target GlassFish 3.1-b37 or better. Once it passes, that will be our indication it works (plus some subsequent manual testing just to be sure). However, the remote GlassFish adapter for Arquillian based on JSR-88 was extremely fragile and when we leaned on it, it fell apart. So Jason Porter came through in a major way and implemented a new remote GlassFish adapter for Arquilian based on the admin REST API in GlassFish 3.1. I verified last night that it works and I pushed out a snapshot. What this means is that we can now comfortably debug the Arquillian tests, likely getting us there a heck of a lot faster. Here are the steps that need to be performed: 1. Add the arquillian-glassfish-remote-3.1:1.0.0-SNAPSHOT profile to the Solder pom.xml 2. Move all sources from api/ into impl/ (we will more gradually move sources to the api/ module once tests are passing on GlassFish) 3. Work through the failing tests and figure out which ones are failing and get them fixed 4. Merge Ken's logging changes (I think biting this bullet is important for the first Beta1) (anything I may be missing) I'll do #1 shortly and hopefully #2 before the end of the day (or I'll delegate it). #3 is work for the weekend or early next week. #4 should be quick once we solve the GlassFish issue. -Dan -- Dan Allen Principal Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://mojavelinux.com http://mojavelinux.com/seaminaction http://www.google.com/profiles/dan.j.allen

On Fri, Jan 21, 2011 at 17:07, Dan Allen <dan.j.allen(a)gmail.com <mailto:dan.j.allen@gmail.com>> wrote: I've done #1. In order to pass any test successfully on GlassFish atm, you need to use the seam-solder combined JAR. That's necessary until I complete #2. Here's a list of the test failures to give you an idea of where we are: Tests in error: testDefaultBean(org.jboss.seam.solder.test.defaultbean.DefaultBeanTest) testDefaultProducerMethod(org.jboss.seam.solder.test.defaultbean.DefaultBeanTest) testDefaultProducerUsesCorrectDelegate(org.jboss.seam.solder.test.defaultbean.DefaultBeanTest) testDefaultProducerFields(org.jboss.seam.solder.test.defaultbean.DefaultBeanTest) testDefaultBeanObserverMethods(org.jboss.seam.solder.test.defaultbean.DefaultBeanTest) testGeneric(org.jboss.seam.solder.test.bean.generic.method.GenericBeanTest) testGeneric(org.jboss.seam.solder.test.bean.generic.method.ProducersOnGenericBeanTest) testProducerSuperclass(org.jboss.seam.solder.test.bean.generic.method.ProducersOnGenericBeanTest) testGeneric(org.jboss.seam.solder.test.bean.generic.method.GenericProductTest) testDisposerCalled(org.jboss.seam.solder.test.bean.generic.method.GenericProductTest) testGeneric(org.jboss.seam.solder.test.bean.generic.method.QualifierOnlyGenericBeanTest) testGeneric(org.jboss.seam.solder.test.bean.generic.field.GenericBeanTest) testScope(org.jboss.seam.solder.test.bean.generic.field.GenericBeanTest) testGenericUnwrap(org.jboss.seam.solder.test.bean.generic.field.GenericBeanUnwrapTest) testGeneric(org.jboss.seam.solder.test.bean.generic.field.ObserversOnGenericBeanTest) testGeneric(org.jboss.seam.solder.test.bean.generic.field.ProducersOnGenericBeanTest) testGeneric(org.jboss.seam.solder.test.bean.generic.field.GenericProductTest) testElResolver(org.jboss.seam.solder.test.el.ElTest) testCustomElResolver(org.jboss.seam.solder.test.el.ElTest) testUnwrapsInjectionPoint(org.jboss.seam.solder.test.unwraps.UnwrapsTest) testUnwraps(org.jboss.seam.solder.test.unwraps.UnwrapsTest) org.jboss.seam.solder.test.serviceHandler.ServiceHandlerTest org.jboss.seam.solder.test.serviceHandler.ServiceHandlerTest org.jboss.seam.solder.test.bean.generic.alternative.GenericBeanAlternativeTest org.jboss.seam.solder.test.bean.generic.alternative.GenericBeanAlternativeTest Tests run: 94, Failures: 0, Errors: 25, Skipped: 0 If you want to start testing, you need to change Deployments.java as follows until #2 is done. public class Deployments { private static final String LOCAL_MAVEN_REPO = System.getProperty("maven.repo.local") != null ? System.getProperty("maven.repo.local") : (System.getProperty("user.home") + File.separatorChar + ".m2" + File.separatorChar + "repository"); public static WebArchive baseDeployment() { return ShrinkWrap.create(WebArchive.class, "test.war") .addLibraries( new File(LOCAL_MAVEN_REPO + File.separator + "org.jboss.seam.solder".replace(".", File.separator) + File.separator + "seam-solder" + File.separator + "3.0.0-SNAPSHOT" + File.separator + "seam-solder-3.0.0-SNAPSHOT.jar"), MavenArtifactResolver.resolve("org.jboss.logging", "jboss-logging")) .addWebResource(EmptyAsset.INSTANCE, "beans.xml"); } } Of course, you have to install the combined jar first ;) -Dan -- Dan Allen Principal Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://mojavelinux.com http://mojavelinux.com/seaminaction http://www.google.com/profiles/dan.j.allen

I'm working on this (#2), should be done shortly. Stay tuned. -Dan On Sat, Jan 22, 2011 at 04:38, Shane Bryzak <sbryzak(a)redhat.com&gt; wrote: > Would it be helpful if I worked on moving the api classes to impl? > > > On 22/01/11 08:08, Dan Allen wrote: > > On Fri, Jan 21, 2011 at 17:07, Dan Allen <dan.j.allen(a)gmail.com&gt; wrote: > >> I've done #1. >> >> In order to pass any test successfully on GlassFish atm, you need to >> use the seam-solder combined JAR. That's necessary until I complete #2. >> >> Here's a list of the test failures to give you an idea of where we are: >> >> Tests in error: >> testDefaultBean(org.jboss.seam.solder.test.defaultbean.DefaultBeanTest) >> >> testDefaultProducerMethod(org.jboss.seam.solder.test.defaultbean.DefaultBeanTest) >> >> testDefaultProducerUsesCorrectDelegate(org.jboss.seam.solder.test.defaultbean.DefaultBeanTest) >> >> testDefaultProducerFields(org.jboss.seam.solder.test.defaultbean.DefaultBeanTest) >> >> testDefaultBeanObserverMethods(org.jboss.seam.solder.test.defaultbean.DefaultBeanTest) >> >> testGeneric(org.jboss.seam.solder.test.bean.generic.method.GenericBeanTest) >> >> testGeneric(org.jboss.seam.solder.test.bean.generic.method.ProducersOnGenericBeanTest) >> >> testProducerSuperclass(org.jboss.seam.solder.test.bean.generic.method.ProducersOnGenericBeanTest) >> >> testGeneric(org.jboss.seam.solder.test.bean.generic.method.GenericProductTest) >> >> testDisposerCalled(org.jboss.seam.solder.test.bean.generic.method.GenericProductTest) >> >> testGeneric(org.jboss.seam.solder.test.bean.generic.method.QualifierOnlyGenericBeanTest) >> >> testGeneric(org.jboss.seam.solder.test.bean.generic.field.GenericBeanTest) >> >> testScope(org.jboss.seam.solder.test.bean.generic.field.GenericBeanTest) >> >> testGenericUnwrap(org.jboss.seam.solder.test.bean.generic.field.GenericBeanUnwrapTest) >> >> testGeneric(org.jboss.seam.solder.test.bean.generic.field.ObserversOnGenericBeanTest) >> >> testGeneric(org.jboss.seam.solder.test.bean.generic.field.ProducersOnGenericBeanTest) >> >> testGeneric(org.jboss.seam.solder.test.bean.generic.field.GenericProductTest) >> testElResolver(org.jboss.seam.solder.test.el.ElTest) >> testCustomElResolver(org.jboss.seam.solder.test.el.ElTest) >> >> testUnwrapsInjectionPoint(org.jboss.seam.solder.test.unwraps.UnwrapsTest) >> testUnwraps(org.jboss.seam.solder.test.unwraps.UnwrapsTest) >> org.jboss.seam.solder.test.serviceHandler.ServiceHandlerTest >> org.jboss.seam.solder.test.serviceHandler.ServiceHandlerTest >> org.jboss.seam.solder.test.bean.generic.alternative.GenericBeanAlternativeTest >> >> org.jboss.seam.solder.test.bean.generic.alternative.GenericBeanAlternativeTest >> >> Tests run: 94, Failures: 0, Errors: 25, Skipped: 0 >> >> If you want to start testing, you need to change Deployments.java as >> follows until #2 is done. >> >> public class Deployments >> { >> private static final String LOCAL_MAVEN_REPO = >> System.getProperty("maven.repo.local") != null ? >> System.getProperty("maven.repo.local") : >> (System.getProperty("user.home") + File.separatorChar + >> ".m2" + File.separatorChar + "repository"); >> >> public static WebArchive baseDeployment() >> { >> return ShrinkWrap.create(WebArchive.class, "test.war") >> .addLibraries( >> new File(LOCAL_MAVEN_REPO + File.separator + >> "org.jboss.seam.solder".replace(".", File.separator) + >> File.separator + "seam-solder" + File.separator + >> "3.0.0-SNAPSHOT" + File.separator + "seam-solder-3.0.0-SNAPSHOT.jar"), >> MavenArtifactResolver.resolve("org.jboss.logging", >> "jboss-logging")) >> .addWebResource(EmptyAsset.INSTANCE, "beans.xml"); >> } >> } >> > > Of course, you have to install the combined jar first ;) > > -Dan > > -- > Dan Allen > Principal Software Engineer, Red Hat | Author of Seam in Action > Registered Linux User #231597 > > http://mojavelinux.com > http://mojavelinux.com/seaminaction > http://www.google.com/profiles/dan.j.allen > > > -- Dan Allen Principal Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://mojavelinux.com http://mojavelinux.com/seaminaction http://www.google.com/profiles/dan.j.allen

Seam REST is almost ready to go. The only issue to fix is GlassFish compatibility, which depends on Solder. On 01/21/2011 11:42 AM, Shane Bryzak wrote: > Hey guys, > > I'm going to start the wheels rolling on the beta release, though first > I need to know if all modules are ready to go. If your module is in the > following list, can you please let me know if it's ready for inclusion > in the Seam beta: > > Seam Catch > Seam International > Seam JMS > Seam REST > Seam Servlet > > If you're still waiting for a Solder release, then the good news is you > have a little more time as we won't be packaging the beta until the > current Glassfish issues with Solder are resolved. Either way, can you > please let me know the current status of your module. > > Thanks, > Shane > _______________________________________________ > seam-dev mailing list > seam-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/seam-dev

Seam REST is almost ready to go. The only issue to fix is GlassFish compatibility, which depends on Solder. On 01/21/2011 11:42 AM, Shane Bryzak wrote: > Hey guys, > > I'm going to start the wheels rolling on the beta release, though first > I need to know if all modules are ready to go. If your module is in the > following list, can you please let me know if it's ready for inclusion > in the Seam beta: > > Seam Catch > Seam International > Seam JMS > Seam REST > Seam Servlet > > If you're still waiting for a Solder release, then the good news is you > have a little more time as we won't be packaging the beta until the > current Glassfish issues with Solder are resolved. Either way, can you > please let me know the current status of your module. > > Thanks, > Shane > _______________________________________________ > 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 REST 3.0.0.Beta1 released On 01/24/2011 10:45 AM, Jozef Hartinger wrote: > Seam REST is almost ready to go. The only issue to fix is GlassFish > compatibility, which depends on Solder. > > On 01/21/2011 11:42 AM, Shane Bryzak wrote: >> Hey guys, >> >> I'm going to start the wheels rolling on the beta release, though first >> I need to know if all modules are ready to go. If your module is in >> the >> following list, can you please let me know if it's ready for inclusion >> in the Seam beta: >> >> Seam Catch >> Seam International >> Seam JMS >> Seam REST >> Seam Servlet >> >> If you're still waiting for a Solder release, then the good news is you >> have a little more time as we won't be packaging the beta until the >> current Glassfish issues with Solder are resolved. Either way, can you >> please let me know the current status of your module. >> >> Thanks, >> Shane >> _______________________________________________ >> 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

I've released 3.0.0.Beta3 with this fix, however most modules are only using Beta2 and have already entered beta themselves. Our next consolidated Seam 3 release will be Beta 2 in a couple of weeks, so we'll make sure to update all modules to use the new Solder before then. Shane On 29/01/11 05:57, Lincoln Baxter, III wrote: Solder needs another Beta release IMO - https://issues.jboss.org/browse/SOLDER-69 is a BIG performance boost. On Fri, Jan 28, 2011 at 2:45 PM, Jozef Hartinger <jharting(a)redhat.com&gt;wrote: > Seam REST 3.0.0.Beta1 released > > On 01/24/2011 10:45 AM, Jozef Hartinger wrote: > > Seam REST is almost ready to go. The only issue to fix is GlassFish > > compatibility, which depends on Solder. > > > > On 01/21/2011 11:42 AM, Shane Bryzak wrote: > >> Hey guys, > >> > >> I'm going to start the wheels rolling on the beta release, though first > >> I need to know if all modules are ready to go. If your module is in > the > >> following list, can you please let me know if it's ready for inclusion > >> in the Seam beta: > >> > >> Seam Catch > >> Seam International > >> Seam JMS > >> Seam REST > >> Seam Servlet > >> > >> If you're still waiting for a Solder release, then the good news is you > >> have a little more time as we won't be packaging the beta until the > >> current Glassfish issues with Solder are resolved. Either way, can you > >> please let me know the current status of your module. > >> > >> Thanks, > >> Shane > >> _______________________________________________ > >> 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 > -- Lincoln Baxter, III http://ocpsoft.com http://scrumshark.com "Keep it Simple"

Good idea! Or something like either: <version>[3.0.0.Beta2,3.0.1)</version> or <version>[3.0.0.Beta2,3.1)</version> That way breaking changes if bound to a version increment, would then require modules to re-release. Brian On 01/28/2011 03:25 PM, Lincoln Baxter, III wrote: > Have we considered using version range specifiers via the maven > artifact syntax? > > If modules used something like: > > <version>[3.0.0.Beta2,)</version> > > It would allow more flexibility as we go along / upgrade individual > modules. This way we wouldn't need to re-release *everything* when we > re-release *one* thing. WDYT? I'm sure there are consequences, but > others may have ideas too. > > ~Lincoln _______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev

On Fri, Jan 28, 2011 at 16:36, Jordan Ganoff <jganoff(a)gmail.com&gt; wrote: > Except releases would then no longer be 100% reproducible. Probably comes > down to a matter of policy. This is a very big reason why not to use ranges for versions, of course it's all pretty much thrown out the window at runtime because which jar happens to be loaded first (and maven will use the most current if anything references a more current version) wins. I'm with Jordan on this one, I say no version ranges for sake of sanity in trying to reproduce builds.

Except releases would then no longer be 100% reproducible. Probably comes down to a matter of policy. -Jordan On Jan 28, 2011 6:33 PM, "Brian Leathem" <bleathem(a)gmail.com&gt; wrote: > Good idea! > > Or something like either: > <version>[3.0.0.Beta2,3.0.1)</version> > or > <version>[3.0.0.Beta2,3.1)</version> > > That way breaking changes if bound to a version increment, would then > require modules to re-release. > > Brian > > On 01/28/2011 03:25 PM, Lincoln Baxter, III wrote: >> Have we considered using version range specifiers via the maven >> artifact syntax? >> >> If modules used something like: >> >> <version>[3.0.0.Beta2,)</version> >> >> It would allow more flexibility as we go along / upgrade individual >> modules. This way we wouldn't need to re-release *everything* when we >> re-release *one* thing. WDYT? I'm sure there are consequences, but >> others may have ideas too. >> >> ~Lincoln > > _______________________________________________ > 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