[seam-dev] Seam 2.1 branch

[Pete Muir]

On 20 Apr 2009, at 22:19, Dan Allen wrote:

> On Sun, Apr 19, 2009 at 11:13 PM, Shane Bryzak  
> <shane.bryzak at jboss.com> wrote:
> Ok, so now we have the following structure:
>
> /seam
>   /docs
>       /trunk
>   /examples
>       /trunk
>           /booking
>   /modules
>       /trunk
>           /captcha
>           /debug
>           /drools
>           /excel
>           /framework
>           /international
>           /interop
>           /ioc
>           /jms
>
>           /mail
>           /pdf
>           /remoting
>           /resteasy
>           /rss
>           /security
>           /ui
>           /version-matrix
>           /wicket
>   /sandbox
>       /trunk
>   /seam-gen
>       /trunk
>
> First off, yeah! I can already feel the agility coming on.
>
> Where's the parent? For instance, if I were to check out all trunks,  
> can I run just one maven command to get all the JARs? If there isn't  
> an answer yet, that's fine.

Modules can have a parent, as can examples etc.

We'll also need a script (ant or maven assembly) to build a dist.

>
>
>
> The original /seam/trunk still contains the bootstrap, build and  
> common directories plus readme's etc, but will eventually be going  
> away.  I've removed most of the content from all the modules  
> directories and all examples so that we can start with a fresh slate  
> for Seam 3.
>
> Good. I have never seen a migration effort complete that didn't  
> start with a semi-clean to fully-clean state. You just never get rid  
> of the cruft unless you bring code back in gradually.
>
> The work that we do for the new booking example and security module  
> will set the standard for further examples and modules as we port  
> them from the 2_1 branch.  It's currently undecided as to where the  
> Seam 2 -> 3 bridge code will go, probably in its own module or  
> separate top-level directory.
>
> I really see this as a module. It's no different than our current  
> spring (and now guice) integration in that sense. We could have an  
> "ioc" common module and then have modules that build on that. But in  
> general it is IoC (or really DI) related.

IOC was a bad name for that module originally, lets not repeat that  
mistake.

>
>
>
> Dan - I've given seam-gen it's own top level directory, and copied  
> both the seam-gen source itself and its resource files there - could  
> you please restructure this as you see best.
>
> I'm not sure I want seam-gen in the trunk yet. seam-gen needs a  
> complete overhaul, which is the intent of seam-gen encore. So  
> eventually it will go there, but we aren't starting on it yet (I'm  
> banking on GSoC). Let's put it this way...when code shows up there,  
> it is going to be seam-gen encore code which will be nothing like  
> the current seam-gen.
>
> I'd like to focus on helping with the booking example and the  
> examples structure. I'm sure as I get going I'll get my head into  
> the whole build.
>
> -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.

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