[seam-dev] laying the tracks for Seam 3

Tue Apr 21 16:17:16 EDT 2009

On Tue, Apr 21, 2009 at 1:15 PM, Pete Muir <pmuir at 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.
>
>  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
>>
>
> probably a good point.

I think that RichFaces will be doing this type of break up as well for 4.0
(components instead of modules).

>
>
>
>>
>> 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
>>
>
> We probably need to decouple the version matrix better from the webbeans
> release lifecycle - just release it as 1,2,3 etc or something...\
>
> Otherwise, makes sense.
>
>
>
>> 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%
>>
>
> All looks good.
>
>
>>
>> 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'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)
>>
>
> 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?

>
>
>
>> pageflow (I think this should not be considered an extension of bpm
>> anymore since it is really standalone)
>>
>
> Ok. We need to look at making pageflow viewlayer-independent anyway.
>
>
>>
>> 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/seam-dev
>>
>
> --
> Pete Muir
> http://www.seamframework.org
> http://in.relation.to/Bloggers/Pete
>
>
> _______________________________________________
> seam-dev mailing list
> seam-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-dev
>

-- 
blog: http://in.relation.to/Bloggers/Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20090421/f89b92d0/attachment.html 