Discussing modules, we definitely need a few more than are currently listed. Here are several I think we need: faces (which would have page actions, faces messages, and perhaps engulf the current ui too) pageflow (I think this should not be considered an extension of bpm anymore since it is really standalone)

The first example (booking) will be using JSF 2.0. I'm going to express this as a dependency per example right now because I'm thinking we still want Seam 3 to work with JSF 1.2 (or should we?). I'll also assume that the app server has JSF 2.0. We might want a build somewhere that can install JSF 2 into JBoss AS just like Web Beans has. Of course, we are waiting on a deployer from my understanding.

I'd like to start a new thread to discuss the Seam 3 foundation (since this is no longer about the Seam 2.1 branch). So far, we have four main SVN divisions: examples modules docs sandbox I raised the question whether we should divide up modules into official, sandbox, and thirdparty. Shane said that likely we don't need that fine-grained of a division.

However, I'm still concerned that sandbox is too vague (the name reminds me of Tomahawk sandbox which is just a mess, IMO). Plus, examples might need a sandbox. So perhaps we can have modules modules-sandbox examples examples-sandbox

Moving on, we are going to use a Maven structure for everything and which closely resembles Web Beans. In fact, they should remain very close in appearance for consistency. Here's the inheritance for each Seam module: webbeans/version-matrix (Pete, is this right?) modules/version-matrix

modules/parent modules/%modulename% That would simply be expressed as: <parent> <artifactId>seam-parent</artifactId> <groupId>org.jboss.seam</groupId> <version>3.0.0-SNAPSHOT</version> </parent> <modelVersion>4.0.0</modelVersion> <groupId>org.jboss.seam</groupId> <artifactId>seam-%modulename%</artifactId> <packaging>jar</packaging> <version>3.0.0-SNAPSHOT</version> <name>Seam %modulename%</name> Of course, a module could be a parent to other modules, such as document perhaps. Examples have a different inheritance hierarchy webbeans/version-matrix (correct?) modules/version-matrix examples/parent examples/%examplename%

The first example (booking) will be using JSF 2.0. I'm going to express this as a dependency per example right now because I'm thinking we still want Seam 3 to work with JSF 1.2 (or should we?).

I'll also assume that the app server has JSF 2.0. We might want a build somewhere that can install JSF 2 into JBoss AS just like Web Beans has. Of course, we are waiting on a deployer from my understanding.

I'll also use the Web Beans logging extension in the examples. I'll coordinate closely with Shane to get the Seam security module running in the booking. Shane, feel free to make changes/additions in booking. I'll keep SVN up to date. Discussing modules, we definitely need a few more than are currently listed. Here are several I think we need: faces (which would have page actions, faces messages, and perhaps engulf the current ui too)

pageflow (I think this should not be considered an extension of bpm anymore since it is really standalone)

That's all I've got at the moment. Feel free to correct me anywhere. These are brainstorms. -Dan -- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action http://mojavelinux.com http://mojavelinux.com/seaminaction http://in.relation.to/Bloggers/Dan NOTE: While I make a strong effort to keep up with my email on a daily basis, personal or other work matters can sometimes keep me away from my email. If you contact me, but don't hear back for more than a week, it is very likely that I am excessively backlogged or the message was caught in the spam filters. Please don't hesitate to resend a message if you feel that it did not reach my attention. _______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev

> faces (which would have page actions, faces messages, and perhaps > engulf the current ui too) Sounds good. We should impl page actions on top of JSF2 events I think. FacesMessages aren't needed as they are now stored in the flashscope by default. Pete - We had talked about having the ui component being separate from seam core and not depend on it. This would allow application to who are not using seam to take advantage of the ui component. This came up a while back in a discussion about the RichFaces validation components and moving them to seam-ui. Would this current approach satisfy that?

On Tue, Apr 21, 2009 at 4:20 PM, Pete Muir <pmuir(a)redhat.com&gt; wrote: On 21 Apr 2009, at 22:17, Jay Balunas wrote: >>>> faces (which would have page actions, faces messages, and >>>> perhaps engulf the current ui too) >>> Sounds good. We should impl page actions on top of JSF2 events I >>> think. FacesMessages aren't needed as they are now stored in the >>> flashscope by default. >> Pete - We had talked about having the ui component being separate >> from seam core and not depend on it. This would allow application >> to who are not using seam to take advantage of the ui component. >> This came up a while back in a discussion about the RichFaces >> validation components and moving them to seam-ui. > >> Would this current approach satisfy that? > Yes. As I keep saying "there is no Seam core" in Seam 3 - all > modules will *just* depend on any JSR-299 impl :-) But you are > actually asking "Can the faces module degrade gracefully such that > what can be used in a plain JSF2 environment - no 299 - works" I > think? I misspoke regarding seam-core :-( I really mean depending on any other seam classes in other modules ( including 299). If we are going to migrate some RichFaces components to seam-ui. I just want to make sure we don't end up requiring users to include X # of seam modules, and/or 299. iirc - I think we were discussing some of the bean validation code. We should discuss other components as well.

-- Pete Muir http://www.seamframework.org http://in.relation.to/Bloggers/Pete -- blog: http://in.relation.to/Bloggers/Jay

Ok, well we can add extra rules to this module: * no non-optional dependencies on other jars (must be self contained) * bean validation must have no deps outside BV api I think it would be sensible to add a short contract.txt to each module to include these requirements. Shane, could you add these?

On 21 Apr 2009, at 22:44, Dan Allen wrote: >> Ok, well we can add extra rules to this module: >> >> * no non-optional dependencies on other jars (must be self contained) >> * bean validation must have no deps outside BV api >> >> I think it would be sensible to add a short contract.txt to each module >> to include these requirements. Shane, could you add these? >> > > Technically that is the purpose of the maven enforcer plugin. With > patience, it can be configured to fail the build when certain dependencies > show up (or are outside of a pattern list). > You need more than that - you need to execute an test for each piece of functionality that has such a contract and ensure it runs with only it's deps in the classpath. The enforcer plugin is more about enforcing a rule on a dependency management, not on how people write code AFAIK.

> Ok, well we can add extra rules to this module: > > * no non-optional dependencies on other jars (must be self contained) > * bean validation must have no deps outside BV api > > I think it would be sensible to add a short contract.txt to each module to > include these requirements. Shane, could you add these? > > Technically that is the purpose of the maven enforcer plugin. With > patience, it can be configured to fail the build when certain dependencies > show up (or are outside of a pattern list). > > You need more than that - you need to execute an test for each piece of > functionality that has such a contract and ensure it runs with only it's > deps in the classpath. The enforcer plugin is more about enforcing a rule on > a dependency management, not on how people write code AFAIK. > > True, I was thinking more in terms of an alternative to contract.txt, > which just makes me cringe. We should enforce the requirement declaratively > (and tie it into the build), then write tests if necessary that validate it > further. > Yes, definitely there should be tests to enforce this, but you need to specify what the contract is somewhere, so that when someone comes along to write the code, they understand the requirements.

On 21 Apr 2009, at 17:05, Dan Allen wrote: I'd like to start a new thread to discuss the Seam 3 foundation (since > this is no longer about the Seam 2.1 branch). > > So far, we have four main SVN divisions: > > examples > modules > docs > sandbox > > I raised the question whether we should divide up modules into official, > sandbox, and thirdparty. Shane said that likely we don't need that > fine-grained of a division. > I don't really like this at all - official is not very community orientated.

> The first example (booking) will be using JSF 2.0. I'm going to express > this as a dependency per example right now because I'm thinking we still > want Seam 3 to work with JSF 1.2 (or should we?). > I personally think we should require JSF2, we aren't porting all the stuff we added to the JSF2 spec over... I'll also assume that the app server has JSF 2.0. We might want a build > somewhere that can install JSF 2 into JBoss AS just like Web Beans has. Of > course, we are waiting on a deployer from my understanding. > You can do it today, just replace the libraries in deploy/jbossweb.deploy/jsf-libs - writing an ant script to do this is a good idea.

Good news, I restructured the booking example into a 3 module reactor project (ejb, war, ear) to build out an EAR deployable...and it actually deploys. So far, you can use the hotel search. PLEASE feel free to suggest refactorings. I'm just getting into the Web Beans programming model here. The booking project lays down a standard for Seam 3 examples. I will of course port ideas back and forth between Seam and Web Beans as we learn more about Maven and how we want to set things up. One of the minor, but nice advances I made is that I was able to use Maven project properties to minimize the repeated elements in each pom.xml. Just check it out to see what I am talking about. Even cooler news was that I figured out how to build out an EAR for JBoss AS complete with the data source embedded within it. This simplifies the deployment, since you don't have to hang the -ds.xml file out adjacent to the deployable and it allows Maven to do all the work without any hacks. I even discovered that the jboss maven plugin does a pretty decent job of deploying to JBoss. It doesn't do an exploded archive yet, but for examples most people focus more on just a one-time deployment. I haven't plunged into Cargo yet. I might dabble in it later. I ran into one hangup that caused me to lose a couple of hours. If you use the typical loader-repository setting in jboss-app.xml, it breaks injection in Web Beans. I don't really understand why, or why the loader-repository is really needed anymore, so I just made a note in the pom.xml not to use it. Long story short, you can deploy booking. But you will need to have Web Beans and JSF 2 SVN deployed to JBoss AS 5. That's all for now ;) -Dan -- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action http://mojavelinux.com http://mojavelinux.com/seaminaction http://in.relation.to/Bloggers/Dan NOTE: While I make a strong effort to keep up with my email on a daily basis, personal or other work matters can sometimes keep me away from my email. If you contact me, but don't hear back for more than a week, it is very likely that I am excessively backlogged or the message was caught in the spam filters. Please don't hesitate to resend a message if you feel that it did not reach my attention.

> I ran into one hangup that caused me to lose a couple of hours. If you use > the typical loader-repository setting in jboss-app.xml, it breaks injection > in Web Beans. > Can you report this as a bug in WBINT please? It shouldn't break

Now for my next question. How do we test the examples? Are we to port/use SeamTest or something you have cooked up in Web Beans? I have no problem studying, I just don't want to waste time so perhaps you can just point me in the right direction.

-Dan On Tue, Apr 21, 2009 at 10:59 PM, Dan Allen <dan.j.allen(a)gmail.com&gt; wrote: Good news, I restructured the booking example into a 3 module reactor project (ejb, war, ear) to build out an EAR deployable...and it actually deploys. So far, you can use the hotel search. PLEASE feel free to suggest refactorings. I'm just getting into the Web Beans programming model here. The booking project lays down a standard for Seam 3 examples. I will of course port ideas back and forth between Seam and Web Beans as we learn more about Maven and how we want to set things up. One of the minor, but nice advances I made is that I was able to use Maven project properties to minimize the repeated elements in each pom.xml. Just check it out to see what I am talking about. Even cooler news was that I figured out how to build out an EAR for JBoss AS complete with the data source embedded within it. This simplifies the deployment, since you don't have to hang the -ds.xml file out adjacent to the deployable and it allows Maven to do all the work without any hacks. I even discovered that the jboss maven plugin does a pretty decent job of deploying to JBoss. It doesn't do an exploded archive yet, but for examples most people focus more on just a one-time deployment. I haven't plunged into Cargo yet. I might dabble in it later. I ran into one hangup that caused me to lose a couple of hours. If you use the typical loader-repository setting in jboss-app.xml, it breaks injection in Web Beans. I don't really understand why, or why the loader-repository is really needed anymore, so I just made a note in the pom.xml not to use it. Long story short, you can deploy booking. But you will need to have Web Beans and JSF 2 SVN deployed to JBoss AS 5. That's all for now ;) -Dan -- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action http://mojavelinux.com http://mojavelinux.com/seaminaction http://in.relation.to/Bloggers/Dan NOTE: While I make a strong effort to keep up with my email on a daily basis, personal or other work matters can sometimes keep me away from my email. If you contact me, but don't hear back for more than a week, it is very likely that I am excessively backlogged or the message was caught in the spam filters. Please don't hesitate to resend a message if you feel that it did not reach my attention. -- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action http://mojavelinux.com http://mojavelinux.com/seaminaction http://in.relation.to/Bloggers/Dan NOTE: While I make a strong effort to keep up with my email on a daily basis, personal or other work matters can sometimes keep me away from my email. If you contact me, but don't hear back for more than a week, it is very likely that I am excessively backlogged or the message was caught in the spam filters. Please don't hesitate to resend a message if you feel that it did not reach my attention.

I just checked in the scaffolding for the servlet-booking example, a WAR which will target Tomcat and Jetty (and perhaps even JBoss AS once I get the profiles setup). In the process, I believe I solved the issue of binding the JCDI Manager to JNDI in Jetty. What's really strange though is that once I get the Manager, it doesn't find any beans on my classpath. But that might have to do with... Jetty is still in a crippled state. First, JSF 2 does not appear fully on Jetty. If I use the @ManagedBean annotation, the bean cannot be found. If I used the @Named annotation, same thing. Both examples work unchanged on Tomcat. So I'm not sure yet. Going to contact the Mojarra team. The scaffolding works beautifully on Tomcat. I'm going to working both the booking and servlet-booking projects as I fill out the functionality. -Dan -- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action http://mojavelinux.com http://mojavelinux.com/seaminaction http://in.relation.to/Bloggers/Dan NOTE: While I make a strong effort to keep up with my email on a daily basis, personal or other work matters can sometimes keep me away from my email. If you contact me, but don't hear back for more than a week, it is very likely that I am excessively backlogged or the message was caught in the spam filters. Please don't hesitate to resend a message if you feel that it did not reach my attention.

On Thu, Apr 23, 2009 at 5:03 PM, Dan Allen <dan.j.allen(a)gmail.com&gt; wrote: > Now, for more functionality and tests ;) Oh, just that? ;) Great work Dan...and very cool that it works mavenized in-place in Jetty, which is my preferred execution environment :)

After a late night, I'm happy to announce that I have all of the following deployments working for examples. packaged EAR to JBoss AS using jboss plugin (booking) exploded EAR to JBoss AS using antrun plugin (booking) packaged WAR to Tomcat using tomcat plugin (servlet-booking) exploded WAR to Tomcat using tomcat plugin (servlet-booking) in place WAR w/ embedded Jetty using jetty plugin (servlet-booking) in place WAR w/ embedded Tomcat using tomcat plugin (servlet-booking) Everything is done with native Maven 2 except for the exploded EAR to JBoss AS. I made the antrun configuration as elegant as possible to support that use case, and I think it works out nicely. Instructions are in the readme.txt. The instructions are still missing some details, but I should have all gaps filled in soon. Now, for more functionality and tests ;) -Dan On Wed, Apr 22, 2009 at 7:01 PM, Dan Allen <dan.j.allen(a)gmail.com <mailto:dan.j.allen@gmail.com>> wrote: I just checked in the scaffolding for the servlet-booking example, a WAR which will target Tomcat and Jetty (and perhaps even JBoss AS once I get the profiles setup). In the process, I believe I solved the issue of binding the JCDI Manager to JNDI in Jetty. What's really strange though is that once I get the Manager, it doesn't find any beans on my classpath. But that might have to do with... Jetty is still in a crippled state. First, JSF 2 does not appear fully on Jetty. If I use the @ManagedBean annotation, the bean cannot be found. If I used the @Named annotation, same thing. Both examples work unchanged on Tomcat. So I'm not sure yet. Going to contact the Mojarra team. The scaffolding works beautifully on Tomcat. I'm going to working both the booking and servlet-booking projects as I fill out the functionality. -Dan -- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action http://mojavelinux.com http://mojavelinux.com/seaminaction http://in.relation.to/Bloggers/Dan NOTE: While I make a strong effort to keep up with my email on a daily basis, personal or other work matters can sometimes keep me away from my email. If you contact me, but don't hear back for more than a week, it is very likely that I am excessively backlogged or the message was caught in the spam filters. Please don't hesitate to resend a message if you feel that it did not reach my attention. -- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action http://mojavelinux.com http://mojavelinux.com/seaminaction http://in.relation.to/Bloggers/Dan NOTE: While I make a strong effort to keep up with my email on a daily basis, personal or other work matters can sometimes keep me away from my email. If you contact me, but don't hear back for more than a week, it is very likely that I am excessively backlogged or the message was caught in the spam filters. Please don't hesitate to resend a message if you feel that it did not reach my attention. ------------------------------------------------------------------------ _______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev

After a late night, I'm happy to announce that I have all of the following deployments working for examples. packaged EAR to JBoss AS using jboss plugin (booking) exploded EAR to JBoss AS using antrun plugin (booking) packaged WAR to Tomcat using tomcat plugin (servlet-booking) exploded WAR to Tomcat using tomcat plugin (servlet-booking) in place WAR w/ embedded Jetty using jetty plugin (servlet-booking) in place WAR w/ embedded Tomcat using tomcat plugin (servlet-booking) Everything is done with native Maven 2 except for the exploded EAR to JBoss AS. I made the antrun configuration as elegant as possible to support that use case, and I think it works out nicely. Instructions are in the readme.txt. The instructions are still missing some details, but I should have all gaps filled in soon. Now, for more functionality and tests ;) -Dan On Wed, Apr 22, 2009 at 7:01 PM, Dan Allen <dan.j.allen(a)gmail.com&gt; wrote: > I just checked in the scaffolding for the servlet-booking example, a WAR > which will target Tomcat and Jetty (and perhaps even JBoss AS once I get the > profiles setup). In the process, I believe I solved the issue of binding the > JCDI Manager to JNDI in Jetty. What's really strange though is that once I > get the Manager, it doesn't find any beans on my classpath. But that might > have to do with... > > Jetty is still in a crippled state. First, JSF 2 does not appear fully on > Jetty. If I use the @ManagedBean annotation, the bean cannot be found. If I > used the @Named annotation, same thing. Both examples work unchanged on > Tomcat. So I'm not sure yet. Going to contact the Mojarra team. > > The scaffolding works beautifully on Tomcat. I'm going to working both the > booking and servlet-booking projects as I fill out the functionality. > > > -Dan > > -- > Dan Allen > Senior Software Engineer, Red Hat | Author of Seam in Action > > http://mojavelinux.com > http://mojavelinux.com/seaminaction > http://in.relation.to/Bloggers/Dan > > NOTE: While I make a strong effort to keep up with my email on a daily > basis, personal or other work matters can sometimes keep me away > from my email. If you contact me, but don't hear back for more than a > week, > it is very likely that I am excessively backlogged or the message was > caught in the spam filters. Please don't hesitate to resend a message if > you feel that it did not reach my attention. > -- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action http://mojavelinux.com http://mojavelinux.com/seaminaction http://in.relation.to/Bloggers/Dan NOTE: While I make a strong effort to keep up with my email on a daily basis, personal or other work matters can sometimes keep me away from my email. If you contact me, but don't hear back for more than a week, it is very likely that I am excessively backlogged or the message was caught in the spam filters. Please don't hesitate to resend a message if you feel that it did not reach my attention.

Naming sounds good :-) On 5 May 2009, at 15:34, Dan Allen wrote: I just checked in a new example to Seam 3, servlet-permalink. It is a very > simple blog with comments (you can't post a new entry yet). This example is > very important because it demonstrates the view parameters (i.e., page > parameters) that Red Hat (Pete and I) contributed to JSF 2 (hence the name > permalink). It of course uses JSR-299 beans as well, but no database. > > I am moving forward with the convention of prefixing WAR projects that > target a servlet environment with servlet-. Thus, I'm thinking about having > a cooresponding prefix for Java EE projects (EARs). I propose the prefix > jee-. So I may change booking to jee-booking. Thoughts? > > Of course, there may be other prefixes in the future like wicket-booking > and groovy-booking. I just want the example name to help poeple understand > what it is demonstrating. Just trying to find the best approach. > > -Dan > > On Thu, Apr 23, 2009 at 6:03 PM, Dan Allen <dan.j.allen(a)gmail.com&gt; wrote: > After a late night, I'm happy to announce that I have all of the following > deployments working for examples. > > packaged EAR to JBoss AS using jboss plugin (booking) > exploded EAR to JBoss AS using antrun plugin (booking) > packaged WAR to Tomcat using tomcat plugin (servlet-booking) > exploded WAR to Tomcat using tomcat plugin (servlet-booking) > in place WAR w/ embedded Jetty using jetty plugin (servlet-booking) > in place WAR w/ embedded Tomcat using tomcat plugin (servlet-booking) > > Everything is done with native Maven 2 except for the exploded EAR to > JBoss AS. I made the antrun configuration as elegant as possible to support > that use case, and I think it works out nicely. Instructions are in the > readme.txt. The instructions are still missing some details, but I should > have all gaps filled in soon. > > Now, for more functionality and tests ;) > > -Dan > > > On Wed, Apr 22, 2009 at 7:01 PM, Dan Allen <dan.j.allen(a)gmail.com&gt; wrote: > I just checked in the scaffolding for the servlet-booking example, a WAR > which will target Tomcat and Jetty (and perhaps even JBoss AS once I get the > profiles setup). In the process, I believe I solved the issue of binding the > JCDI Manager to JNDI in Jetty. What's really strange though is that once I > get the Manager, it doesn't find any beans on my classpath. But that might > have to do with... > > Jetty is still in a crippled state. First, JSF 2 does not appear fully on > Jetty. If I use the @ManagedBean annotation, the bean cannot be found. If I > used the @Named annotation, same thing. Both examples work unchanged on > Tomcat. So I'm not sure yet. Going to contact the Mojarra team. > > The scaffolding works beautifully on Tomcat. I'm going to working both the > booking and servlet-booking projects as I fill out the functionality. > > > -Dan > > -- > Dan Allen > Senior Software Engineer, Red Hat | Author of Seam in Action > > http://mojavelinux.com > http://mojavelinux.com/seaminaction > http://in.relation.to/Bloggers/Dan > > NOTE: While I make a strong effort to keep up with my email on a daily > basis, personal or other work matters can sometimes keep me away > from my email. If you contact me, but don't hear back for more than a > week, > it is very likely that I am excessively backlogged or the message was > caught in the spam filters. Please don't hesitate to resend a message if > you feel that it did not reach my attention. > > > > -- > Dan Allen > Senior Software Engineer, Red Hat | Author of Seam in Action > > http://mojavelinux.com > http://mojavelinux.com/seaminaction > http://in.relation.to/Bloggers/Dan > > NOTE: While I make a strong effort to keep up with my email on a daily > basis, personal or other work matters can sometimes keep me away > from my email. If you contact me, but don't hear back for more than a > week, > it is very likely that I am excessively backlogged or the message was > caught in the spam filters. Please don't hesitate to resend a message if > you feel that it did not reach my attention. > > > > -- > Dan Allen > Senior Software Engineer, Red Hat | Author of Seam in Action > > http://mojavelinux.com > http://mojavelinux.com/seaminaction > http://in.relation.to/Bloggers/Dan > > NOTE: While I make a strong effort to keep up with my email on a daily > basis, personal or other work matters can sometimes keep me away > from my email. If you contact me, but don't hear back for more than a > week, > it is very likely that I am excessively backlogged or the message was > caught in the spam filters. Please don't hesitate to resend a message if > you feel that it did not reach my attention. > -- Pete Muir http://www.seamframework.org http://in.relation.to/Bloggers/Pete

On Tue, Apr 21, 2009 at 1:15 PM, Pete Muir <pmuir(a)redhat.com <mailto:pmuir@redhat.com>> wrote: On 21 Apr 2009, at 17:05, Dan Allen wrote: I'd like to start a new thread to discuss the Seam 3 foundation (since this is no longer about the Seam 2.1 branch). So far, we have four main SVN divisions: examples modules docs sandbox I raised the question whether we should divide up modules into official, sandbox, and thirdparty. Shane said that likely we don't need that fine-grained of a division. I don't really like this at all - official is not very community orientated. Okay, that's not really what I meant. I was thinking more along the lines of production ready versus...well, a sandbox. But I think there is a general consensus on a two-way split. modules modules-sandbox Speaking of which, if we followed the web beans convention, the folder names would be: seam-modules seam-modules-sandbox seam-examples seam-examples-sandbox Should we add the seam- prefix? Or is it fine the way it is. I actually don't care, just pointing out that I noticed the difference.

The first example (booking) will be using JSF 2.0. I'm going to express this as a dependency per example right now because I'm thinking we still want Seam 3 to work with JSF 1.2 (or should we?). I personally think we should require JSF2, we aren't porting all the stuff we added to the JSF2 spec over... I'll also assume that the app server has JSF 2.0. We might want a build somewhere that can install JSF 2 into JBoss AS just like Web Beans has. Of course, we are waiting on a deployer from my understanding. You can do it today, just replace the libraries in deploy/jbossweb.deploy/jsf-libs - writing an ant script to do this is a good idea. I wrote a Maven script ;) modules/jsf-updater-tool I'll likely weave in the antrun plugin to get fancier, but it is simple enough right now that it gets the job done. -Dan -- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action http://mojavelinux.com http://mojavelinux.com/seaminaction http://in.relation.to/Bloggers/Dan NOTE: While I make a strong effort to keep up with my email on a daily basis, personal or other work matters can sometimes keep me away from my email. If you contact me, but don't hear back for more than a week, it is very likely that I am excessively backlogged or the message was caught in the spam filters. Please don't hesitate to resend a message if you feel that it did not reach my attention. ------------------------------------------------------------------------ _______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev

On Tue, Apr 21, 2009 at 1:15 PM, Pete Muir <pmuir(a)redhat.com&gt; wrote: On 21 Apr 2009, at 17:05, Dan Allen wrote: I'd like to start a new thread to discuss the Seam 3 foundation (since this is no longer about the Seam 2.1 branch). So far, we have four main SVN divisions: examples modules docs sandbox I raised the question whether we should divide up modules into official, sandbox, and thirdparty. Shane said that likely we don't need that fine-grained of a division. I don't really like this at all - official is not very community orientated. Okay, that's not really what I meant. I was thinking more along the lines of production ready versus...well, a sandbox. But I think there is a general consensus on a two-way split. modules modules-sandbox Speaking of which, if we followed the web beans convention, the folder names would be: seam-modules seam-modules-sandbox seam-examples seam-examples-sandbox Should we add the seam- prefix? Or is it fine the way it is. I actually don't care, just pointing out that I noticed the difference.

The first example (booking) will be using JSF 2.0. I'm going to express this as a dependency per example right now because I'm thinking we still want Seam 3 to work with JSF 1.2 (or should we?). I personally think we should require JSF2, we aren't porting all the stuff we added to the JSF2 spec over... I'll also assume that the app server has JSF 2.0. We might want a build somewhere that can install JSF 2 into JBoss AS just like Web Beans has. Of course, we are waiting on a deployer from my understanding. You can do it today, just replace the libraries in deploy/ jbossweb.deploy/jsf-libs - writing an ant script to do this is a good idea. I wrote a Maven script ;) modules/jsf-updater-tool I'll likely weave in the antrun plugin to get fancier, but it is simple enough right now that it gets the job done.

-Dan -- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action http://mojavelinux.com http://mojavelinux.com/seaminaction http://in.relation.to/Bloggers/Dan NOTE: While I make a strong effort to keep up with my email on a daily basis, personal or other work matters can sometimes keep me away from my email. If you contact me, but don't hear back for more than a week, it is very likely that I am excessively backlogged or the message was caught in the spam filters. Please don't hesitate to resend a message if you feel that it did not reach my attention.