All, Shortly (tomorrow evening my time) I'm going to branch Seam trunk into a Seam_2_1 branch, and start working on the directory structure for Seam 3 in trunk. After discussing with Pete, we've decided that we are going to go with a modular directory structure which will make it possible to do separate releases for individual Seam modules (as well as other advantages). The new directory structure will look somewhat like this: /seam/trunk /modules/trunk /excel /mail /pdf /remoting /resteasy /rss /security /sandbox/trunk /other sandbox modules go here, /and once stable they move to /modules /examples/trunk /existing seam examples go here /docs/trunk /common/trunk Could we please have all code checked in before this change - I'll probably begin around the following time, and require a short code freeze (hopefully just a few hours) while the restructuring is taking place. http://www.timeanddate.com/worldclock/fixedtime.html?month=4&day=19&a... <http://www.timeanddate.com/worldclock/fixedtime.html?month=4&day=19&a... Thanks, Shane _______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev

The majority of the restructure is now complete, and what was in Seam trunk has now been moved to the Seam_2_1 branch: https://svn.jboss.org/repos/seam/branches/community/Seam_2_1/ Any further development on Seam 2.1.x should be done in this branch, and only Seam 3.x development should now be happening in trunk. From here onward there is still a lot of work to get trunk to a stable form, which will be my top priority this week. In no particular order:

1. The build needs to be fixed. We will be moving to a maven-based build at least for modules and common. This gets number one priority.

2. Examples build needs to be fixed - Dan do you think you could work on this? 3. Docs build need to be fixed. As each module has now become its own standalone project, the documentation will need to be self- contained within each module. So for example, docs for the pdf feature should be contained under modules/trunk/pdf/docs. We still need a master documentation build for when we do a full Seam release, which will include the docs for all modules. We also need to notify the documentation team so that they can update their build system. Pete do you know who we should contact for this?

4. The Hudson build is currently broken, so for now we should disable it for trunk. We also need to set up new Hudson builds for the 2_1 branch. Pete, can you please delegate this task to the appropriate person?

5. We need to start porting the modules to JSR-299. Our goal here should be to have implementation-independent modules, so that it should be possible to drop in any of our modules into any JSR-299 implementation and have it work in that environment. Security will be first off the bat as it is required by the booking example. 6. The booking example needs to be ported to run on JSR-299 (very high priority).

7. We should possibly evaluate whether any of the other major features such as framework, bpm, rules, etc deserve to be in their own module.

That's the state of things at the moment, I'll try to post regular progress updates this week. I'll also post something to the forums to let the community know about the changes.

Shane Shane Bryzak wrote: > I'm now starting the restructuring work on Seam trunk, so the code > freeze is now in effect. I'll send another mail once it's done. > > Thanks, > Shane > > Shane Bryzak wrote: >> All, >> >> Shortly (tomorrow evening my time) I'm going to branch Seam trunk >> into a Seam_2_1 branch, and start working on the directory >> structure for Seam 3 in trunk. After discussing with Pete, we've >> decided that we are going to go with a modular directory structure >> which will make it possible to do separate releases for individual >> Seam modules (as well as other advantages). The new directory >> structure will look somewhat like this: >> >> /seam/trunk >> /modules/trunk >> /excel >> /mail >> /pdf >> /remoting >> /resteasy >> /rss >> /security >> /sandbox/trunk >> /other sandbox >> modules go here, >> /and once stable they >> move to /modules >> /examples/trunk >> /existing seam >> examples go here >> /docs/trunk >> /common/trunk >> >> Could we please have all code checked in before this change - I'll >> probably begin around the following time, and require a short code >> freeze (hopefully just a few hours) while the restructuring is >> taking place. >> >> http://www.timeanddate.com/worldclock/fixedtime.html?month=4&day=19&a... >> <http://www.timeanddate.com/worldclock/fixedtime.html?month=4&day=19&a... >> > >> >> 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

On 19 Apr 2009, at 12:48, Shane Bryzak wrote: > The majority of the restructure is now complete, and what was in Seam > trunk has now been moved to the Seam_2_1 branch: > > https://svn.jboss.org/repos/seam/branches/community/Seam_2_1/ > > Any further development on Seam 2.1.x should be done in this branch, > and only Seam 3.x development should now be happening in trunk. From > here onward there is still a lot of work to get trunk to a stable > form, which will be my top priority this week. In no particular order: Can we shift the new stuff up one level, having it in trunk/modules/trunk is weird ;-)

Let's leave all the legacy stuff (build, bootstrap, random scripts, eclipse project info) in trunk for now. Common should start empty and we can move code from the old seam core bit by bit. Personally, I would start all modules empty - it saves on having to apply updates to trunk and the 2.1 branch for now (until it is actually ported).

> > > 1. The build needs to be fixed. We will be moving to a maven-based > build at least for modules and common. This gets number one priority. We should use maven to build example artifacts too probably, and use ant for the deployment. > > 2. Examples build needs to be fixed - Dan do you think you could work > on this? > 3. Docs build need to be fixed. As each module has now become its > own standalone project, the documentation will need to be > self-contained within each module. So for example, docs for the pdf > feature should be contained under modules/trunk/pdf/docs. We still > need a master documentation build for when we do a full Seam release, > which will include the docs for all modules. We also need to notify > the documentation team so that they can update their build system. > Pete do you know who we should contact for this? How do you mean? What will break?

> > 4. The Hudson build is currently broken, so for now we should disable > it for trunk. We also need to set up new Hudson builds for the 2_1 > branch. Pete, can you please delegate this task to the appropriate > person? Ondrej, can you take care of this? > > 5. We need to start porting the modules to JSR-299. Our goal here > should be to have implementation-independent modules, so that it > should be possible to drop in any of our modules into any JSR-299 > implementation and have it work in that environment. Security will > be first off the bat as it is required by the booking example. > 6. The booking example needs to be ported to run on JSR-299 (very > high priority). and JSF2 > > 7. We should possibly evaluate whether any of the other major > features such as framework, bpm, rules, etc deserve to be in their > own module. bpm will be done for Web Beans. All major features should be in their own module. There is no Seam "core" anymore. > > > That's the state of things at the moment, I'll try to post regular > progress updates this week. I'll also post something to the forums > to let the community know about the changes. Thanks Shane! > > > Shane > > > Shane Bryzak wrote: >> I'm now starting the restructuring work on Seam trunk, so the code >> freeze is now in effect. I'll send another mail once it's done. >> >> Thanks, >> Shane >> >> Shane Bryzak wrote: >>> All, >>> >>> Shortly (tomorrow evening my time) I'm going to branch Seam trunk >>> into a Seam_2_1 branch, and start working on the directory >>> structure for Seam 3 in trunk. After discussing with Pete, we've >>> decided that we are going to go with a modular directory structure >>> which will make it possible to do separate releases for individual >>> Seam modules (as well as other advantages). The new directory >>> structure will look somewhat like this: >>> >>> /seam/trunk >>> /modules/trunk >>> /excel >>> /mail >>> /pdf >>> /remoting >>> /resteasy >>> /rss >>> /security >>> /sandbox/trunk >>> /other sandbox modules >>> go here, >>> /and once stable they >>> move to /modules >>> /examples/trunk >>> /existing seam >>> examples go here >>> /docs/trunk >>> /common/trunk >>> >>> Could we please have all code checked in before this change - I'll >>> probably begin around the following time, and require a short code >>> freeze (hopefully just a few hours) while the restructuring is >>> taking place. >>> >>> http://www.timeanddate.com/worldclock/fixedtime.html?month=4&day=19&a... <http://www.timeanddate.com/worldclock/fixedtime.html?month=4&day=19&a... >>> >>> >>> 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 -- Pete Muir http://www.seamframework.org http://in.relation.to/Bloggers/Pete

On 19 Apr 2009, at 21:56, Shane Bryzak wrote: > Pete Muir wrote: >> >> On 19 Apr 2009, at 12:48, Shane Bryzak wrote: >> >>> The majority of the restructure is now complete, and what was in >>> Seam trunk has now been moved to the Seam_2_1 branch: >>> >>> https://svn.jboss.org/repos/seam/branches/community/Seam_2_1/ >>> >>> Any further development on Seam 2.1.x should be done in this >>> branch, and only Seam 3.x development should now be happening in >>> trunk. From here onward there is still a lot of work to get trunk >>> to a stable form, which will be my top priority this week. In no >>> particular order: >> >> Can we shift the new stuff up one level, having it in >> trunk/modules/trunk is weird ;-) > So just trunk/modules ? No problem, though if we need to branch a > module, where will the branch go? https://svn.jboss.org/repos/seam/ - modules - trunk - branches - tags etc.

> >> >> Let's leave all the legacy stuff (build, bootstrap, random scripts, >> eclipse project info) in trunk for now. >> >> Common should start empty and we can move code from the old seam >> core bit by bit. >> >> Personally, I would start all modules empty - it saves on having to >> apply updates to trunk and the 2.1 branch for now (until it is >> actually ported). > What if we put the original module source in > /modules/<module>/src/legacy ? Why? It won't run in current form in Seam 3. We need to make Seam 2 layer that does work. Let's just keep the legacy code in the branch for now, and port it as needed.

> >> >>> >>> >>> 1. The build needs to be fixed. We will be moving to a maven-based >>> build at least for modules and common. This gets number one priority. >> >> We should use maven to build example artifacts too probably, and use >> ant for the deployment. >> >> >>> >>> 2. Examples build needs to be fixed - Dan do you think you could >>> work on this? >>> 3. Docs build need to be fixed. As each module has now become its >>> own standalone project, the documentation will need to be >>> self-contained within each module. So for example, docs for the >>> pdf feature should be contained under modules/trunk/pdf/docs. We >>> still need a master documentation build for when we do a full Seam >>> release, which will include the docs for all modules. We also need >>> to notify the documentation team so that they can update their >>> build system. Pete do you know who we should contact for this? >> >> How do you mean? What will break? > Well I believe their build system checks out the doc source from SVN > and generates the .po files etc. If our docs are split up into > separate modules, their build will need to be updated also. No, it still doesn't do that. Either Nicola or I normally do that.

> >> >>> >>> 4. The Hudson build is currently broken, so for now we should >>> disable it for trunk. We also need to set up new Hudson builds for >>> the 2_1 branch. Pete, can you please delegate this task to the >>> appropriate person? >> >> Ondrej, can you take care of this? >> >>> >>> 5. We need to start porting the modules to JSR-299. Our goal here >>> should be to have implementation-independent modules, so that it >>> should be possible to drop in any of our modules into any JSR-299 >>> implementation and have it work in that environment. Security will >>> be first off the bat as it is required by the booking example. >>> 6. The booking example needs to be ported to run on JSR-299 (very >>> high priority). >> >> and JSF2 >> >>> >>> 7. We should possibly evaluate whether any of the other major >>> features such as framework, bpm, rules, etc deserve to be in their >>> own module. >> >> bpm will be done for Web Beans. All major features should be in >> their own module. There is no Seam "core" anymore. >>> >>> >>> That's the state of things at the moment, I'll try to post regular >>> progress updates this week. I'll also post something to the forums >>> to let the community know about the changes. >> >> Thanks Shane! >> >>> >>> >>> Shane >>> >>> >>> Shane Bryzak wrote: >>>> I'm now starting the restructuring work on Seam trunk, so the code >>>> freeze is now in effect. I'll send another mail once it's done. >>>> >>>> Thanks, >>>> Shane >>>> >>>> Shane Bryzak wrote: >>>>> All, >>>>> >>>>> Shortly (tomorrow evening my time) I'm going to branch Seam trunk >>>>> into a Seam_2_1 branch, and start working on the directory >>>>> structure for Seam 3 in trunk. After discussing with Pete, we've >>>>> decided that we are going to go with a modular directory >>>>> structure which will make it possible to do separate releases for >>>>> individual Seam modules (as well as other advantages). The new >>>>> directory structure will look somewhat like this: >>>>> >>>>> /seam/trunk >>>>> /modules/trunk >>>>> /excel >>>>> /mail >>>>> /pdf >>>>> /remoting >>>>> /resteasy >>>>> /rss >>>>> /security >>>>> /sandbox/trunk >>>>> /other sandbox >>>>> modules go here, >>>>> /and once stable they >>>>> move to /modules >>>>> /examples/trunk >>>>> /existing seam >>>>> examples go here >>>>> /docs/trunk >>>>> /common/trunk >>>>> >>>>> Could we please have all code checked in before this change - >>>>> I'll probably begin around the following time, and require a >>>>> short code freeze (hopefully just a few hours) while the >>>>> restructuring is taking place. >>>>> >>>>> http://www.timeanddate.com/worldclock/fixedtime.html?month=4&day=19&a... <http://www.timeanddate.com/worldclock/fixedtime.html?month=4&day=19&a... >>>>> >>>>> >>>>> 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 >> >> -- >> Pete Muir >> http://www.seamframework.org >> http://in.relation.to/Bloggers/Pete >> > -- Pete Muir http://www.seamframework.org http://in.relation.to/Bloggers/Pete

On 19 Apr 2009, at 22:16, Shane Bryzak wrote: > Pete Muir wrote: >> >> On 19 Apr 2009, at 21:56, Shane Bryzak wrote: >> >>> Pete Muir wrote: >>>> >>>> On 19 Apr 2009, at 12:48, Shane Bryzak wrote: >>>> >>>>> The majority of the restructure is now complete, and what was in >>>>> Seam trunk has now been moved to the Seam_2_1 branch: >>>>> >>>>> https://svn.jboss.org/repos/seam/branches/community/Seam_2_1/ >>>>> >>>>> Any further development on Seam 2.1.x should be done in this >>>>> branch, and only Seam 3.x development should now be happening in >>>>> trunk. From here onward there is still a lot of work to get >>>>> trunk to a stable form, which will be my top priority this week. >>>>> In no particular order: >>>> >>>> Can we shift the new stuff up one level, having it in >>>> trunk/modules/trunk is weird ;-) >>> So just trunk/modules ? No problem, though if we need to branch a >>> module, where will the branch go? >> >> https://svn.jboss.org/repos/seam/ >> - modules >> - trunk >> - branches >> - tags >> >> etc. > > That looks good, and in that case sandbox should sit at the same > level. Should docs, common, seam-gen stay in seam/trunk? Both docs > and common currently have a trunk sub dir, which should probably be > removed. docs, and seam-gen should definitely move. Let's leave common for now as I don't really like it anyway. > > >> >>> >>>> >>>> Let's leave all the legacy stuff (build, bootstrap, random >>>> scripts, eclipse project info) in trunk for now. >>>> >>>> Common should start empty and we can move code from the old seam >>>> core bit by bit. >>>> >>>> Personally, I would start all modules empty - it saves on having >>>> to apply updates to trunk and the 2.1 branch for now (until it is >>>> actually ported). >>> What if we put the original module source in >>> /modules/<module>/src/legacy ? >> >> Why? It won't run in current form in Seam 3. We need to make Seam 2 >> layer that does work. Let's just keep the legacy code in the branch >> for now, and port it as needed. > > Ah ok.. we're going to have a lot of empty directories then ;) >> >>> >>>> >>>>> >>>>> >>>>> 1. The build needs to be fixed. We will be moving to a >>>>> maven-based build at least for modules and common. This gets >>>>> number one priority. >>>> >>>> We should use maven to build example artifacts too probably, and >>>> use ant for the deployment. >>>> >>>> >>>>> >>>>> 2. Examples build needs to be fixed - Dan do you think you could >>>>> work on this? >>>>> 3. Docs build need to be fixed. As each module has now become >>>>> its own standalone project, the documentation will need to be >>>>> self-contained within each module. So for example, docs for the >>>>> pdf feature should be contained under modules/trunk/pdf/docs. We >>>>> still need a master documentation build for when we do a full >>>>> Seam release, which will include the docs for all modules. We >>>>> also need to notify the documentation team so that they can >>>>> update their build system. Pete do you know who we should >>>>> contact for this? >>>> >>>> How do you mean? What will break? >>> Well I believe their build system checks out the doc source from >>> SVN and generates the .po files etc. If our docs are split up into >>> separate modules, their build will need to be updated also. >> >> No, it still doesn't do that. Either Nicola or I normally do that. > > Hmm, I seem to remember Samson talking about an automated build that > happened every Sunday. Perhaps they never got round to implementing > it for Seam. Exactly. > >> >>> >>>> >>>>> >>>>> 4. The Hudson build is currently broken, so for now we should >>>>> disable it for trunk. We also need to set up new Hudson builds >>>>> for the 2_1 branch. Pete, can you please delegate this task to >>>>> the appropriate person? >>>> >>>> Ondrej, can you take care of this? >>>> >>>>> >>>>> 5. We need to start porting the modules to JSR-299. Our goal >>>>> here should be to have implementation-independent modules, so >>>>> that it should be possible to drop in any of our modules into any >>>>> JSR-299 implementation and have it work in that environment. >>>>> Security will be first off the bat as it is required by the >>>>> booking example. >>>>> 6. The booking example needs to be ported to run on JSR-299 (very >>>>> high priority). >>>> >>>> and JSF2 >>>> >>>>> >>>>> 7. We should possibly evaluate whether any of the other major >>>>> features such as framework, bpm, rules, etc deserve to be in >>>>> their own module. >>>> >>>> bpm will be done for Web Beans. All major features should be in >>>> their own module. There is no Seam "core" anymore. >>>>> >>>>> >>>>> That's the state of things at the moment, I'll try to post >>>>> regular progress updates this week. I'll also post something to >>>>> the forums to let the community know about the changes. >>>> >>>> Thanks Shane! >>>> >>>>> >>>>> >>>>> Shane >>>>> >>>>> >>>>> Shane Bryzak wrote: >>>>>> I'm now starting the restructuring work on Seam trunk, so the >>>>>> code freeze is now in effect. I'll send another mail once it's >>>>>> done. >>>>>> >>>>>> Thanks, >>>>>> Shane >>>>>> >>>>>> Shane Bryzak wrote: >>>>>>> All, >>>>>>> >>>>>>> Shortly (tomorrow evening my time) I'm going to branch Seam >>>>>>> trunk into a Seam_2_1 branch, and start working on the >>>>>>> directory structure for Seam 3 in trunk. After discussing with >>>>>>> Pete, we've decided that we are going to go with a modular >>>>>>> directory structure which will make it possible to do separate >>>>>>> releases for individual Seam modules (as well as other >>>>>>> advantages). The new directory structure will look somewhat >>>>>>> like this: >>>>>>> >>>>>>> /seam/trunk >>>>>>> /modules/trunk >>>>>>> /excel >>>>>>> /mail >>>>>>> /pdf >>>>>>> /remoting >>>>>>> /resteasy >>>>>>> /rss >>>>>>> /security >>>>>>> /sandbox/trunk >>>>>>> /other sandbox >>>>>>> modules go here, >>>>>>> /and once stable >>>>>>> they move to /modules >>>>>>> /examples/trunk >>>>>>> /existing seam >>>>>>> examples go here >>>>>>> /docs/trunk >>>>>>> /common/trunk >>>>>>> >>>>>>> Could we please have all code checked in before this change - >>>>>>> I'll probably begin around the following time, and require a >>>>>>> short code freeze (hopefully just a few hours) while the >>>>>>> restructuring is taking place. >>>>>>> >>>>>>> http://www.timeanddate.com/worldclock/fixedtime.html?month=4&day=19&a... <http://www.timeanddate.com/worldclock/fixedtime.html?month=4&day=19&a... >>>>>>> >>>>>>> >>>>>>> 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 >>>> >>>> -- >>>> Pete Muir >>>> http://www.seamframework.org >>>> http://in.relation.to/Bloggers/Pete >>>> >>> >> >> -- >> Pete Muir >> http://www.seamframework.org >> http://in.relation.to/Bloggers/Pete >> > -- Pete Muir http://www.seamframework.org http://in.relation.to/Bloggers/Pete _______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev

On Sun, Apr 19, 2009 at 11:13 PM, Shane Bryzak <shane.bryzak(a)jboss.com&gt; 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.

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.

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.

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. What about DI, or is that too general? I guess the first question to answer is what is the nature of these integrations. The JBoss AS team has probably thought about this terminology so we should see what they have to say about the name. Obviously, each integration would be named after the framework, but if there were shared code what would it be called? Not a question we have to answer right away.

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

Should we qualify the term modules? Meaning instead of modules and sandbox we have something like modules sandbox-modules thirdparty-modules Modules (I'm open to a qualifier like official-modules) would be official modules in Seam...stuff that is going into EAP. sandbox would be modules we want to put into core, but they just aren't ready yet or may never be. thirdparty would be modules we are hosting for a community member but we don't want to maintain. For instance, perhaps the host the tapastry integration module or whatever. I'd be interested in doing that with examples too. examples sandbox-examples thirdparty-examples Thoughts? This should be easy to add without affecting what you have setup already. Any thoughts on this yet?

-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 píše v Ne 19. 04. 2009 v 19:19 +0100: > On 19 Apr 2009, at 12:48, Shane Bryzak wrote: > > >> The majority of the restructure is now complete, and what was in >> Seam trunk has now been moved to the Seam_2_1 branch: >> >> https://svn.jboss.org/repos/seam/branches/community/Seam_2_1/ >> >> Any further development on Seam 2.1.x should be done in this branch, >> and only Seam 3.x development should now be happening in trunk. >> From here onward there is still a lot of work to get trunk to a >> stable form, which will be my top priority this week. In no >> particular order: >> > Can we shift the new stuff up one level, having it in trunk/modules/ > trunk is weird ;-) > > Let's leave all the legacy stuff (build, bootstrap, random scripts, > eclipse project info) in trunk for now. > > Common should start empty and we can move code from the old seam core > bit by bit. > > Personally, I would start all modules empty - it saves on having to > apply updates to trunk and the 2.1 branch for now (until it is > actually ported). > > >> 1. The build needs to be fixed. We will be moving to a maven-based >> build at least for modules and common. This gets number one priority. >> > We should use maven to build example artifacts too probably, and use > ant for the deployment. > > > >> 2. Examples build needs to be fixed - Dan do you think you could >> work on this? >> 3. Docs build need to be fixed. As each module has now become its >> own standalone project, the documentation will need to be self- >> contained within each module. So for example, docs for the pdf >> feature should be contained under modules/trunk/pdf/docs. We still >> need a master documentation build for when we do a full Seam >> release, which will include the docs for all modules. We also need >> to notify the documentation team so that they can update their build >> system. Pete do you know who we should contact for this? >> > How do you mean? What will break? > > >> 4. The Hudson build is currently broken, so for now we should >> disable it for trunk. We also need to set up new Hudson builds for >> the 2_1 branch. Pete, can you please delegate this task to the >> appropriate person? >> > Ondrej, can you take care of this? > I can make current Hudson jobs (Seam-trunk-*) run on the 2_1 branch (E.g. renaming them to seam-2.1-*). But there is currently no capacity to create new jobs for the new trunk, because all Seam QE team is set on WFK testing, which has higher priority and still we are chasing deadlines. Could someone more familiar with the new svn structure do the Hudson change?

>> 5. We need to start porting the modules to JSR-299. Our goal here >> should be to have implementation-independent modules, so that it >> should be possible to drop in any of our modules into any JSR-299 >> implementation and have it work in that environment. Security will >> be first off the bat as it is required by the booking example. >> 6. The booking example needs to be ported to run on JSR-299 (very >> high priority). >> > and JSF2 > > >> 7. We should possibly evaluate whether any of the other major >> features such as framework, bpm, rules, etc deserve to be in their >> own module. >> > bpm will be done for Web Beans. All major features should be in their > own module. There is no Seam "core" anymore. > > >> That's the state of things at the moment, I'll try to post regular >> progress updates this week. I'll also post something to the forums >> to let the community know about the changes. >> > Thanks Shane! > > >> Shane >> >> >> Shane Bryzak wrote: >> >>> I'm now starting the restructuring work on Seam trunk, so the code >>> freeze is now in effect. I'll send another mail once it's done. >>> >>> Thanks, >>> Shane >>> >>> Shane Bryzak wrote: >>> >>>> All, >>>> >>>> Shortly (tomorrow evening my time) I'm going to branch Seam trunk >>>> into a Seam_2_1 branch, and start working on the directory >>>> structure for Seam 3 in trunk. After discussing with Pete, we've >>>> decided that we are going to go with a modular directory structure >>>> which will make it possible to do separate releases for individual >>>> Seam modules (as well as other advantages). The new directory >>>> structure will look somewhat like this: >>>> >>>> /seam/trunk >>>> /modules/trunk >>>> /excel >>>> /mail >>>> /pdf >>>> /remoting >>>> /resteasy >>>> /rss >>>> /security >>>> /sandbox/trunk >>>> /other sandbox >>>> modules go here, >>>> /and once stable they >>>> move to /modules >>>> /examples/trunk >>>> /existing seam >>>> examples go here >>>> /docs/trunk >>>> /common/trunk >>>> >>>> Could we please have all code checked in before this change - I'll >>>> probably begin around the following time, and require a short code >>>> freeze (hopefully just a few hours) while the restructuring is >>>> taking place. >>>> >>>> http://www.timeanddate.com/worldclock/fixedtime.html?month=4&day=19&a... >>>> <http://www.timeanddate.com/worldclock/fixedtime.html?month=4&day=19&a... >>>> >>>> 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 >> > -- > Pete Muir > http://www.seamframework.org > http://in.relation.to/Bloggers/Pete > >

The majority of the restructure is now complete, and what was in Seam trunk has now been moved to the Seam_2_1 branch: https://svn.jboss.org/repos/seam/branches/community/Seam_2_1/ Any further development on Seam 2.1.x should be done in this branch, and only Seam 3.x development should now be happening in trunk. From here onward there is still a lot of work to get trunk to a stable form, which will be my top priority this week. In no particular order: 1. The build needs to be fixed. We will be moving to a maven-based build at least for modules and common. This gets number one priority. 2. Examples build needs to be fixed - Dan do you think you could work on this? 3. Docs build need to be fixed. As each module has now become its own standalone project, the documentation will need to be self-contained within each module. So for example, docs for the pdf feature should be contained under modules/trunk/pdf/docs. We still need a master documentation build for when we do a full Seam release, which will include the docs for all modules. We also need to notify the documentation team so that they can update their build system. Pete do you know who we should contact for this? 4. The Hudson build is currently broken, so for now we should disable it for trunk. We also need to set up new Hudson builds for the 2_1 branch. Pete, can you please delegate this task to the appropriate person? 5. We need to start porting the modules to JSR-299. Our goal here should be to have implementation-independent modules, so that it should be possible to drop in any of our modules into any JSR-299 implementation and have it work in that environment. Security will be first off the bat as it is required by the booking example. 6. The booking example needs to be ported to run on JSR-299 (very high priority). 7. We should possibly evaluate whether any of the other major features such as framework, bpm, rules, etc deserve to be in their own module. That's the state of things at the moment, I'll try to post regular progress updates this week. I'll also post something to the forums to let the community know about the changes. Shane Shane Bryzak wrote: > I'm now starting the restructuring work on Seam trunk, so the code > freeze is now in effect. I'll send another mail once it's done. > > Thanks, > Shane > > Shane Bryzak wrote: >> All, >> >> Shortly (tomorrow evening my time) I'm going to branch Seam trunk >> into a Seam_2_1 branch, and start working on the directory structure >> for Seam 3 in trunk. After discussing with Pete, we've decided that >> we are going to go with a modular directory structure which will make >> it possible to do separate releases for individual Seam modules (as >> well as other advantages). The new directory structure will look >> somewhat like this: >> >> /seam/trunk >> /modules/trunk >> /excel >> /mail >> /pdf >> /remoting >> /resteasy >> /rss >> /security >> /sandbox/trunk >> /other sandbox modules >> go here, >> /and once stable they >> move to /modules >> /examples/trunk >> /existing seam examples >> go here >> /docs/trunk >> /common/trunk >> >> Could we please have all code checked in before this change - I'll >> probably begin around the following time, and require a short code >> freeze (hopefully just a few hours) while the restructuring is taking >> place. >> >> http://www.timeanddate.com/worldclock/fixedtime.html?month=4&day=19&a... >> <http://www.timeanddate.com/worldclock/fixedtime.html?month=4&day=19&a... >> >> >> 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

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknsMGkACgkQU4HO8G8hNxVBowCfT+GX542M11/pzX2xcwSBfK9r l0EAoLTxA1XE1rtxPx6T+yQgjLa60+lR =IoTk -----END PGP SIGNATURE-----

6. The booking example needs to be ported to run on JSR-299 (very high priority).

> > 1. Can I use the standard src/main/webapp for the web assets? The webbeans > build uses WebContent which I guess is for JBDS. But I think I can get JBDS > to work with src/main/webapp just fine. I'm also open to the folder named > "view". I really dislike the folder name WebContent. > A question for Max really - this is a good chance to fix up the structure if we need to. One thing I'd like to see is WEB-INF moved out of resources and into the web (or whatever we call it) directory.

6. The booking example needs to be ported to run on JSR-299 (very high priority). I've begun the work on this, focusing initially on the build (I will need lots of advice on how to best *implement* the functionality using 299). Right now, I have three pom.xml files committed: modules/version-matrix/pom.xml examples/pom.xml examples/booking/pom.xml They depend on each other ascending the list. Pete, you mentioned that the Seam version-matrix should use the WB version-matrix as the parent.

I have not done that yet (since I don't need that many dependencies yet given what I have so far). Shane, please feel free to hack this file up as needed. I just had to have it in place to do anything w/ the examples. The good news is that the seam-booking.war can be built and deployed to JBoss AS 5. It doesn't really do anything yet except show the home page. Tomorrow I can dive in and start to get a screen or two going. I would then like to research getting Maven to deploy the examples...only falling back to Ant if I am just fighting with it too much.

Couple of questions so far. 1. Can I use the standard src/main/webapp for the web assets? The webbeans build uses WebContent which I guess is for JBDS. But I think I can get JBDS to work with src/main/webapp just fine. I'm also open to the folder named "view". I really dislike the folder name WebContent.

2. We are setting JSF to version 2.0.0.PR2, right? I guess later if we need to we can think about how to enable JSF 1.2 in the build, but I'm assuming we are just not worrying about that yet. So I can use JSF 2 features (and knock out legacy Facelets), correct?

3. Should booking be an EAR or a WAR (or both)? I know I will need a Stateful session bean so with JBoss AS 5 that still requires use of an EAR I believe. I seem to have answered my own question. Just verify.

Also, please can we use consistent formatting of XML files in Seam 3? It appears this team likes 3 spaces. I'm willing to go with that (though I prefer tabs myself). Just be conscious of this because it really gets tedious when it's all different.

So far, so good. Shane, let's keep chatting. I should be back on IM this week. -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

BTW take a look at http://seamframework.org/Community/GettingStartedDevelopingTheSeamFramewo... if you aren't sure, and update it if something is missing.

I have not done that yet (since I don't need that many dependencies yet given what I have so far). Shane, please feel free to hack this file up as needed. I just had to have it in place to do anything w/ the examples. The good news is that the seam-booking.war can be built and deployed to JBoss AS 5. It doesn't really do anything yet except show the home page. Tomorrow I can dive in and start to get a screen or two going. I would then like to research getting Maven to deploy the examples...only falling back to Ant if I am just fighting with it too much. I've done this twice and it's a nightmare ;-) I was fortunate to have good fortune on my first try. I got the booking example to deploy with no trouble using the jboss plugin. The downside is that I've only got the packaged EAR going so far, not the exploded EAR. I'm going to see if I can build quickly on what I have.

Couple of questions so far. 1. Can I use the standard src/main/webapp for the web assets? The webbeans build uses WebContent which I guess is for JBDS. But I think I can get JBDS to work with src/main/webapp just fine. I'm also open to the folder named "view". I really dislike the folder name WebContent. I think we should go with the WTP standard here. I really don't like this idea. I want to stick to the Maven standard src/main/webapp or use view. WebContext is a stupid folder name and I've always hated that WTP wouldn't change it to something less lame. Besides, the location is completely configurable in WTP anyway, so it doesn't really care what the folder is called. I've also seen Maven plugins choke when the convention is not followed. So I'm going to hack on src/main/webapp for a couple of days and just see how it pans out.

2. We are setting JSF to version 2.0.0.PR2, right? I guess later if we need to we can think about how to enable JSF 1.2 in the build, but I'm assuming we are just not worrying about that yet. So I can use JSF 2 features (and knock out legacy Facelets), correct? I don't see a need to support JSF 1.2 All I was looking for was a decision. Fine with me. The only downside is that I have to use JSF 2 from SVN because the current PR2 doesn't have any of the Red Hat additions. But SVN is also not quite working right, so we are just going to have to hobble along for a short while. 3. Should booking be an EAR or a WAR (or both)? I know I will need a Stateful session bean so with JBoss AS 5 that still requires use of an EAR I believe. I seem to have answered my own question. Just verify. EAR. 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.

Hi Dan, On Tue, Apr 21, 2009 at 10:41 PM, Dan Allen <dan.j.allen(a)gmail.com&gt; wrote: > > I really don't like this idea. I want to stick to the Maven standard > src/main/webapp or use view. WebContext is a stupid folder name and I've > always hated that WTP wouldn't change it to something less lame. Besides, > the location is completely configurable in WTP anyway, so it doesn't really > care what the folder is called. I've also seen Maven plugins choke when the > convention is not followed. So I'm going to hack on src/main/webapp for a > couple of days and just see how it pans out. > > Did the src/main/webapp convention not pan out? I noticed you've committed examples using the WebContent convention. Personally, I'd rather see src/main/webapp, if possible.