From sbryzak at redhat.com Thu Sep 1 19:15:06 2011 From: sbryzak at redhat.com (Shane Bryzak) Date: Fri, 02 Sep 2011 09:15:06 +1000 Subject: [seam-dev] Bundled distribution documentation In-Reply-To: <4E5DB50C.3030409@redhat.com> References: <4E5DB50C.3030409@redhat.com> Message-ID: <4E6011FA.7010607@redhat.com> Guys, I need a yea or nay on this for your module. On 31/08/11 14:14, Shane Bryzak wrote: > Module leads, > > Can you please review the list below and confirm that the documentation > chapters are correct for your module. Also, I would like everyone to > take a moment to review the module documentation guidelines, as there > were a number of breakages in the bundled documentation build because > the guidelines weren't adhered to, particularly in the new modules for > Seam 3.1: > > 1) Always prefix the filenames of your documentation chapters with the > name of your module. E.g. security-authentication.xml, > security-authorization.xml, etc. > > 2) Whenever you assign an ID to a docbook element, such as a > or
, ALWAYS prefix the id with your module name. For example, > or
id="security-getting-started">. As all of the chapters for all modules > are combined when building the bundled documentation, all IDs must be > unique. This is a particularly time consuming problem to fix because > the error output from the Maven docbook plugin doesn't tell you which > files are the problem ones. > > 3) When adding, renaming or deleting a chapter of your documentation, > please notify me of the changes so that I can update > bundled_master.xml. This file must be manually kept up to date whenever > any documentation changes are made. > > Thanks, > Shane > > > > "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ ]> > > > > > Seam 3 > Bundled Reference Guide > > > > > > Forge > > > > > > > > Seam Solder > > > > > > > > > > > > > > > > > > > Seam Configuration > > > > > > Seam Persistence > > > > > Seam Transaction > > > > > Seam Servlet > > > > > > > > > > Seam Security > > > > > > > > > Seam International > > > > > > > > > Seam Faces > > > > > > > > > > > Seam Catch > > > > > > > > > > Seam Reports > > > > > > > Seam Remoting > > > > > > > Seam REST > > > > > > > > > > > Seam JCR > > > > > > > > > Seam JMS > > > > > > > > > > Seam Validation > > > > > > > > Seam Wicket > > > > > > > _______________________________________________ > seam-dev mailing list > seam-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/seam-dev From gegastaldi at gmail.com Thu Sep 1 19:31:25 2011 From: gegastaldi at gmail.com (George Gastaldi) Date: Thu, 1 Sep 2011 20:31:25 -0300 Subject: [seam-dev] Bundled distribution documentation In-Reply-To: <4E6011FA.7010607@redhat.com> References: <4E5DB50C.3030409@redhat.com> <4E6011FA.7010607@redhat.com> Message-ID: <-7880943549841437954@unknownmsgid> Hi Shane, I still couldn't review the docs on Seam Reports, so I guess thats a nay for me. Regards, George Em 01/09/2011, ?s 20:15, Shane Bryzak escreveu: > Guys, I need a yea or nay on this for your module. > > On 31/08/11 14:14, Shane Bryzak wrote: >> Module leads, >> >> Can you please review the list below and confirm that the documentation >> chapters are correct for your module. Also, I would like everyone to >> take a moment to review the module documentation guidelines, as there >> were a number of breakages in the bundled documentation build because >> the guidelines weren't adhered to, particularly in the new modules for >> Seam 3.1: >> >> 1) Always prefix the filenames of your documentation chapters with the >> name of your module. E.g. security-authentication.xml, >> security-authorization.xml, etc. >> >> 2) Whenever you assign an ID to a docbook element, such as a >> or
, ALWAYS prefix the id with your module name. For example, >> or
> id="security-getting-started">. As all of the chapters for all modules >> are combined when building the bundled documentation, all IDs must be >> unique. This is a particularly time consuming problem to fix because >> the error output from the Maven docbook plugin doesn't tell you which >> files are the problem ones. >> >> 3) When adding, renaming or deleting a chapter of your documentation, >> please notify me of the changes so that I can update >> bundled_master.xml. This file must be manually kept up to date whenever >> any documentation changes are made. >> >> Thanks, >> Shane >> >> >> >> > "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ ]> >> >> >> >> >> Seam 3 >> Bundled Reference Guide >> >> >> >> >> >> Forge >> >> >> >> >> >> >> >> Seam Solder >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Seam Configuration >> >> >> >> >> >> Seam Persistence >> >> >> >> >> Seam Transaction >> >> >> >> >> Seam Servlet >> >> >> >> >> >> >> >> >> >> Seam Security >> >> >> >> >> >> >> >> >> Seam International >> >> >> >> >> >> >> >> >> Seam Faces >> >> >> >> >> >> >> >> >> >> >> Seam Catch >> >> >> >> >> >> >> >> >> >> Seam Reports >> >> >> >> >> >> >> Seam Remoting >> >> >> >> >> >> >> Seam REST >> >> >> >> >> >> >> >> >> >> >> Seam JCR >> >> >> >> >> >> >> >> >> Seam JMS >> >> >> >> >> >> >> >> >> >> Seam Validation >> >> >> >> >> >> >> >> Seam Wicket >> >> >> >> >> >> >> _______________________________________________ >> seam-dev mailing list >> seam-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/seam-dev > > _______________________________________________ > seam-dev mailing list > seam-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/seam-dev From lightguard.jp at gmail.com Thu Sep 1 19:32:36 2011 From: lightguard.jp at gmail.com (Jason Porter) Date: Thu, 1 Sep 2011 17:32:36 -0600 Subject: [seam-dev] Bundled distribution documentation In-Reply-To: <-7880943549841437954@unknownmsgid> References: <4E5DB50C.3030409@redhat.com> <4E6011FA.7010607@redhat.com> <-7880943549841437954@unknownmsgid> Message-ID: Catch should be fine. On Thu, Sep 1, 2011 at 17:31, George Gastaldi wrote: > Hi Shane, > > I still couldn't review the docs on Seam Reports, so I guess thats a nay > for me. > > Regards, > > George > > Em 01/09/2011, ?s 20:15, Shane Bryzak escreveu: > > > Guys, I need a yea or nay on this for your module. > > > > On 31/08/11 14:14, Shane Bryzak wrote: > >> Module leads, > >> > >> Can you please review the list below and confirm that the documentation > >> chapters are correct for your module. Also, I would like everyone to > >> take a moment to review the module documentation guidelines, as there > >> were a number of breakages in the bundled documentation build because > >> the guidelines weren't adhered to, particularly in the new modules for > >> Seam 3.1: > >> > >> 1) Always prefix the filenames of your documentation chapters with the > >> name of your module. E.g. security-authentication.xml, > >> security-authorization.xml, etc. > >> > >> 2) Whenever you assign an ID to a docbook element, such as a > >> or
, ALWAYS prefix the id with your module name. For example, > >> or
>> id="security-getting-started">. As all of the chapters for all modules > >> are combined when building the bundled documentation, all IDs must be > >> unique. This is a particularly time consuming problem to fix because > >> the error output from the Maven docbook plugin doesn't tell you which > >> files are the problem ones. > >> > >> 3) When adding, renaming or deleting a chapter of your documentation, > >> please notify me of the changes so that I can update > >> bundled_master.xml. This file must be manually kept up to date whenever > >> any documentation changes are made. > >> > >> Thanks, > >> Shane > >> > >> > >> > >> >> "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ ]> > >> > >> > >> > >> > >> Seam 3 > >> Bundled Reference Guide > >> > >> > >> > >> > >> > >> Forge > >> > >> > >> > >> > >> > >> > >> > >> Seam Solder > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> Seam Configuration > >> > >> > >> > >> > >> > >> Seam Persistence > >> > >> > >> > >> > >> Seam Transaction > >> > >> > >> > >> > >> Seam Servlet > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> Seam Security > >> > >> > >> > >> > >> > >> > >> > >> > >> Seam International > >> > >> > >> > >> > >> > >> > >> > >> > >> Seam Faces > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> Seam Catch > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> Seam Reports > >> > >> > >> > >> > >> > >> > >> Seam Remoting > >> > >> > >> > >> > >> > >> > >> Seam REST > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> Seam JCR > >> > >> > >> > >> > >> > >> > >> > >> > >> Seam JMS > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> Seam Validation > >> > >> > >> > >> > >> > >> > >> > >> Seam Wicket > >> > >> > >> > >> > >> > >> > >> _______________________________________________ > >> seam-dev mailing list > >> seam-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/seam-dev > > > > _______________________________________________ > > seam-dev mailing list > > seam-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/seam-dev > > _______________________________________________ > seam-dev mailing list > seam-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/seam-dev > -- Jason Porter http://lightguard-jp.blogspot.com http://twitter.com/lightguardjp Software Engineer Open Source Advocate Author of Seam Catch - Next Generation Java Exception Handling PGP key id: 926CCFF5 PGP key available at: keyserver.net, pgp.mit.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110901/f40a7cbd/attachment-0001.html From ken at kenfinnigan.me Thu Sep 1 19:46:35 2011 From: ken at kenfinnigan.me (Ken Finnigan) Date: Thu, 1 Sep 2011 19:46:35 -0400 Subject: [seam-dev] Bundled distribution documentation In-Reply-To: References: <4E5DB50C.3030409@redhat.com> <4E6011FA.7010607@redhat.com> <-7880943549841437954@unknownmsgid> Message-ID: International should be good Sent from my iPhone On Sep 1, 2011, at 19:32, Jason Porter wrote: > Catch should be fine. > > On Thu, Sep 1, 2011 at 17:31, George Gastaldi wrote: > Hi Shane, > > I still couldn't review the docs on Seam Reports, so I guess thats a nay for me. > > Regards, > > George > > Em 01/09/2011, ?s 20:15, Shane Bryzak escreveu: > > > Guys, I need a yea or nay on this for your module. > > > > On 31/08/11 14:14, Shane Bryzak wrote: > >> Module leads, > >> > >> Can you please review the list below and confirm that the documentation > >> chapters are correct for your module. Also, I would like everyone to > >> take a moment to review the module documentation guidelines, as there > >> were a number of breakages in the bundled documentation build because > >> the guidelines weren't adhered to, particularly in the new modules for > >> Seam 3.1: > >> > >> 1) Always prefix the filenames of your documentation chapters with the > >> name of your module. E.g. security-authentication.xml, > >> security-authorization.xml, etc. > >> > >> 2) Whenever you assign an ID to a docbook element, such as a > >> or
, ALWAYS prefix the id with your module name. For example, > >> or
>> id="security-getting-started">. As all of the chapters for all modules > >> are combined when building the bundled documentation, all IDs must be > >> unique. This is a particularly time consuming problem to fix because > >> the error output from the Maven docbook plugin doesn't tell you which > >> files are the problem ones. > >> > >> 3) When adding, renaming or deleting a chapter of your documentation, > >> please notify me of the changes so that I can update > >> bundled_master.xml. This file must be manually kept up to date whenever > >> any documentation changes are made. > >> > >> Thanks, > >> Shane > >> > >> > >> > >> >> "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ ]> > >> > >> > >> > >> > >> Seam 3 > >> Bundled Reference Guide > >> > >> > >> > >> > >> > >> Forge > >> > >> > >> > >> > >> > >> > >> > >> Seam Solder > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> Seam Configuration > >> > >> > >> > >> > >> > >> Seam Persistence > >> > >> > >> > >> > >> Seam Transaction > >> > >> > >> > >> > >> Seam Servlet > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> Seam Security > >> > >> > >> > >> > >> > >> > >> > >> > >> Seam International > >> > >> > >> > >> > >> > >> > >> > >> > >> Seam Faces > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> Seam Catch > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> Seam Reports > >> > >> > >> > >> > >> > >> > >> Seam Remoting > >> > >> > >> > >> > >> > >> > >> Seam REST > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> Seam JCR > >> > >> > >> > >> > >> > >> > >> > >> > >> Seam JMS > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> Seam Validation > >> > >> > >> > >> > >> > >> > >> > >> Seam Wicket > >> > >> > >> > >> > >> > >> > >> _______________________________________________ > >> seam-dev mailing list > >> seam-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/seam-dev > > > > _______________________________________________ > > seam-dev mailing list > > seam-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/seam-dev > > _______________________________________________ > seam-dev mailing list > seam-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/seam-dev > > > > -- > Jason Porter > http://lightguard-jp.blogspot.com > http://twitter.com/lightguardjp > > Software Engineer > Open Source Advocate > Author of Seam Catch - Next Generation Java Exception Handling > > PGP key id: 926CCFF5 > PGP key available at: keyserver.net, pgp.mit.edu > _______________________________________________ > seam-dev mailing list > seam-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/seam-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110901/5f9d116d/attachment.html From lincolnbaxter at gmail.com Thu Sep 1 23:48:41 2011 From: lincolnbaxter at gmail.com (Lincoln Baxter, III) Date: Thu, 1 Sep 2011 23:48:41 -0400 Subject: [seam-dev] Bundled distribution documentation In-Reply-To: References: <4E5DB50C.3030409@redhat.com> <4E5EA2EA.2000109@redhat.com> <4E6001BD.4070301@redhat.com> <4E601AA2.7090705@redhat.com> Message-ID: Actually, maybe the best thing to do is just to add a new section to the Seam umbrella doc, with an HTML link to the forge confluence space? On Thu, Sep 1, 2011 at 7:54 PM, Lincoln Baxter, III wrote: > Ok. If you include beta1, the artifact for dist is: > > org.jboss.forge:forge-modules:1.0.0.Beta1 > > -- > Lincoln Baxter's Droid > http://ocpsoft.com > "Keep it Simple" > On Sep 1, 2011 7:52 PM, "Shane Bryzak" wrote: > > Yep, I planned on extracting it in the forge folder. > > > > On 02/09/11 09:43, Lincoln Baxter, III wrote: > >> > >> Also, if forge is unzipped. It should be done so in its own subfolder. > >> > >> Ill try to catch you online tonight and make sure you've got the right > >> artifact. (it moved temporarily during the jboss modules transition. > >> > >> -- > >> Lincoln Baxter's Droid > >> http://ocpsoft.com > >> "Keep it Simple" > >> > >> On Sep 1, 2011 7:41 PM, "Lincoln Baxter, III" >> > wrote: > >> > Well. The forge distribution doesn't contain docs either. They are > >> purely > >> > online at this point. So I think just don't worry about it. This > >> confluence > >> > thing is a bit of a pain in that regard. > >> > > >> > -- > >> > Lincoln Baxter's Droid > >> > http://ocpsoft.com > >> > "Keep it Simple" > >> > On Sep 1, 2011 6:05 PM, "Shane Bryzak" >> > wrote: > >> >> Unless an export could be automated as part of the build process, I > >> >> don't think that's a good idea. How about we just include the Forge > >> >> distribution extracted inside the Seam distribution? The > documentation > >> >> won't be combined with the main Seam docs, but as long as it's in the > >> >> Forge distribution then a user should be able to find it without too > >> >> much effort. > >> >> > >> >> On 02/09/11 01:22, Lincoln Baxter, III wrote: > >> >>> > >> >>> I'm not really sure how to do this, then. There are no sources since > >> >>> the docs are in confluence. > >> >>> > >> >>> I suppose an export could work? > >> >>> > >> >>> -- > >> >>> Lincoln Baxter's Droid > >> >>> http://ocpsoft.com > >> >>> "Keep it Simple" > >> >>> > >> >>> On Aug 31, 2011 5:09 PM, "Shane Bryzak" >> > >> >>> >> wrote: > >> >>> > The source artifact for the Forge docs were being pulled in like > >> this: > >> >>> > > >> >>> > > >> >>> > org.jboss.seam.forge > >> >>> > forge-reference-guide > >> >>> > 1.0.0-SNAPSHOT > >> >>> > sources > >> >>> > jar > >> >>> > > >> >>> > > >> >>> > When I update the version to 1.0.0.Beta1, it can't find the source > - > >> >>> was > >> >>> > the Beta1 source artifact published to Maven? > >> >>> > > >> >>> > > >> >>> > > >> >>> > On 01/09/11 03:02, Lincoln Baxter, III wrote: > >> >>> >> https://docs.jboss.org/author/display/SEAMFORGE/Home > >> >>> >> > >> >>> >> On Wed, Aug 31, 2011 at 1:02 PM, Lincoln Baxter, III > >> >>> >> > >> > > >> >>> > >> >>> > wrote: > >> >>> >> > >> >>> >> Just checking - the Forge docs are no longer in SVN / are in > >> >>> >> Confluence; have you taken this into account? > >> >>> >> > >> >>> >> Also, the which distribution are you including? You could choose > >> >>> >> either Beta1 or the latest SNAPSHOT (which is actually in a new > >> >>> >> location - moved back to the original > >> >>> >> org.jboss.forge:forge-distribution - though it looks like the > >> >>> >> build hasn't deployed artifacts in a little while - looking in to > >> >>> >> that) > >> >>> >> > >> >>> >> ~Lincoln > >> >>> >> > >> >>> >> > >> >>> >> On Wed, Aug 31, 2011 at 12:14 AM, Shane Bryzak > >> > >> >>> > > >> >>> >> > >> >>> wrote: > >> >>> >> > >> >>> >> Module leads, > >> >>> >> > >> >>> >> Can you please review the list below and confirm that the > >> >>> >> documentation > >> >>> >> chapters are correct for your module. Also, I would like > >> >>> >> everyone to > >> >>> >> take a moment to review the module documentation guidelines, > >> >>> >> as there > >> >>> >> were a number of breakages in the bundled documentation build > >> >>> >> because > >> >>> >> the guidelines weren't adhered to, particularly in the new > >> >>> >> modules for > >> >>> >> Seam 3.1: > >> >>> >> > >> >>> >> 1) Always prefix the filenames of your documentation chapters > >> >>> >> with the > >> >>> >> name of your module. E.g. security-authentication.xml, > >> >>> >> security-authorization.xml, etc. > >> >>> >> > >> >>> >> 2) Whenever you assign an ID to a docbook element, such as a > >> >>> >> > >> >>> >> or
, ALWAYS prefix the id with your module name. For > >> >>> >> example, > >> >>> >> or
>> >>> >> id="security-getting-started">. As all of the chapters for > >> >>> >> all modules > >> >>> >> are combined when building the bundled documentation, all IDs > >> >>> >> must be > >> >>> >> unique. This is a particularly time consuming problem to fix > >> >>> >> because > >> >>> >> the error output from the Maven docbook plugin doesn't tell > >> >>> >> you which > >> >>> >> files are the problem ones. > >> >>> >> > >> >>> >> 3) When adding, renaming or deleting a chapter of your > >> >>> >> documentation, > >> >>> >> please notify me of the changes so that I can update > >> >>> >> bundled_master.xml. This file must be manually kept up to > >> >>> >> date whenever > >> >>> >> any documentation changes are made. > >> >>> >> > >> >>> >> Thanks, > >> >>> >> Shane > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> >> >>> >> "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ ]> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> Seam 3 > >> >>> >> Bundled Reference Guide > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> Forge > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> Seam Solder > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> Seam Configuration > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> Seam Persistence > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> Seam Transaction > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> Seam Servlet > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> Seam Security > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> Seam International > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> Seam Faces > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> Seam Catch > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> Seam Reports > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> Seam Remoting > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> Seam REST > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> Seam JCR > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> Seam JMS > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> Seam Validation > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> Seam Wicket > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> _______________________________________________ > >> >>> >> seam-dev mailing list > >> >>> >> seam-dev at lists.jboss.org > >> > > >> >>> > >> >> > >> >>> >> https://lists.jboss.org/mailman/listinfo/seam-dev > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> -- > >> >>> >> Lincoln Baxter, III > >> >>> >> http://ocpsoft.com > >> >>> >> http://scrumshark.com > >> >>> >> "Keep it Simple" > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> -- > >> >>> >> Lincoln Baxter, III > >> >>> >> http://ocpsoft.com > >> >>> >> http://scrumshark.com > >> >>> >> "Keep it Simple" > >> >>> > > >> >> > > > -- Lincoln Baxter, III http://ocpsoft.com http://scrumshark.com "Keep it Simple" -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110901/0a42e775/attachment-0001.html From sbryzak at redhat.com Thu Sep 1 23:51:57 2011 From: sbryzak at redhat.com (Shane Bryzak) Date: Fri, 02 Sep 2011 13:51:57 +1000 Subject: [seam-dev] Bundled distribution documentation In-Reply-To: References: <4E5DB50C.3030409@redhat.com> <4E5EA2EA.2000109@redhat.com> <4E6001BD.4070301@redhat.com> <4E601AA2.7090705@redhat.com> Message-ID: <4E6052DD.1090602@redhat.com> Yeah, that's a good idea. Do you have plans to provide documentation as part of the Forge download? I'm thinking of the users who might have no/limited connectivity who won't be able to access the Forge docs online. Also, how does confluence work in conjunction with our documentation team? From my understanding all their tools for translating etc are based on Publican/Docbook. On 02/09/11 13:48, Lincoln Baxter, III wrote: > Actually, maybe the best thing to do is just to add a new section to > the Seam umbrella doc, with an HTML link to the forge confluence space? > > On Thu, Sep 1, 2011 at 7:54 PM, Lincoln Baxter, III > > wrote: > > Ok. If you include beta1, the artifact for dist is: > > org.jboss.forge:forge-modules:1.0.0.Beta1 > > -- > Lincoln Baxter's Droid > http://ocpsoft.com > "Keep it Simple" > > On Sep 1, 2011 7:52 PM, "Shane Bryzak" > wrote: > > Yep, I planned on extracting it in the forge folder. > > > > On 02/09/11 09:43, Lincoln Baxter, III wrote: > >> > >> Also, if forge is unzipped. It should be done so in its own > subfolder. > >> > >> Ill try to catch you online tonight and make sure you've got > the right > >> artifact. (it moved temporarily during the jboss modules > transition. > >> > >> -- > >> Lincoln Baxter's Droid > >> http://ocpsoft.com > >> "Keep it Simple" > >> > >> On Sep 1, 2011 7:41 PM, "Lincoln Baxter, III" > > >> >> wrote: > >> > Well. The forge distribution doesn't contain docs either. > They are > >> purely > >> > online at this point. So I think just don't worry about it. This > >> confluence > >> > thing is a bit of a pain in that regard. > >> > > >> > -- > >> > Lincoln Baxter's Droid > >> > http://ocpsoft.com > >> > "Keep it Simple" > >> > On Sep 1, 2011 6:05 PM, "Shane Bryzak" > >> >> wrote: > >> >> Unless an export could be automated as part of the build > process, I > >> >> don't think that's a good idea. How about we just include > the Forge > >> >> distribution extracted inside the Seam distribution? The > documentation > >> >> won't be combined with the main Seam docs, but as long as > it's in the > >> >> Forge distribution then a user should be able to find it > without too > >> >> much effort. > >> >> > >> >> On 02/09/11 01:22, Lincoln Baxter, III wrote: > >> >>> > >> >>> I'm not really sure how to do this, then. There are no > sources since > >> >>> the docs are in confluence. > >> >>> > >> >>> I suppose an export could work? > >> >>> > >> >>> -- > >> >>> Lincoln Baxter's Droid > >> >>> http://ocpsoft.com > >> >>> "Keep it Simple" > >> >>> > >> >>> On Aug 31, 2011 5:09 PM, "Shane Bryzak" > >> > > >> >>> > >>> wrote: > >> >>> > The source artifact for the Forge docs were being pulled > in like > >> this: > >> >>> > > >> >>> > > >> >>> > org.jboss.seam.forge > >> >>> > forge-reference-guide > >> >>> > 1.0.0-SNAPSHOT > >> >>> > sources > >> >>> > jar > >> >>> > > >> >>> > > >> >>> > When I update the version to 1.0.0.Beta1, it can't find > the source - > >> >>> was > >> >>> > the Beta1 source artifact published to Maven? > >> >>> > > >> >>> > > >> >>> > > >> >>> > On 01/09/11 03:02, Lincoln Baxter, III wrote: > >> >>> >> https://docs.jboss.org/author/display/SEAMFORGE/Home > >> >>> >> > >> >>> >> On Wed, Aug 31, 2011 at 1:02 PM, Lincoln Baxter, III > >> >>> >> > > >> >> > >> >>> > > >> >>>> wrote: > >> >>> >> > >> >>> >> Just checking - the Forge docs are no longer in SVN / are in > >> >>> >> Confluence; have you taken this into account? > >> >>> >> > >> >>> >> Also, the which distribution are you including? You > could choose > >> >>> >> either Beta1 or the latest SNAPSHOT (which is actually > in a new > >> >>> >> location - moved back to the original > >> >>> >> org.jboss.forge:forge-distribution - though it looks > like the > >> >>> >> build hasn't deployed artifacts in a little while - > looking in to > >> >>> >> that) > >> >>> >> > >> >>> >> ~Lincoln > >> >>> >> > >> >>> >> > >> >>> >> On Wed, Aug 31, 2011 at 12:14 AM, Shane Bryzak > >> > > > >> >>> > >> > >> >>> >> > > > >> > >>>> wrote: > >> >>> >> > >> >>> >> Module leads, > >> >>> >> > >> >>> >> Can you please review the list below and confirm that the > >> >>> >> documentation > >> >>> >> chapters are correct for your module. Also, I would like > >> >>> >> everyone to > >> >>> >> take a moment to review the module documentation guidelines, > >> >>> >> as there > >> >>> >> were a number of breakages in the bundled documentation > build > >> >>> >> because > >> >>> >> the guidelines weren't adhered to, particularly in the new > >> >>> >> modules for > >> >>> >> Seam 3.1: > >> >>> >> > >> >>> >> 1) Always prefix the filenames of your documentation > chapters > >> >>> >> with the > >> >>> >> name of your module. E.g. security-authentication.xml, > >> >>> >> security-authorization.xml, etc. > >> >>> >> > >> >>> >> 2) Whenever you assign an ID to a docbook element, such as a > >> >>> >> > >> >>> >> or
, ALWAYS prefix the id with your module > name. For > >> >>> >> example, > >> >>> >> or
>> >>> >> id="security-getting-started">. As all of the chapters for > >> >>> >> all modules > >> >>> >> are combined when building the bundled documentation, > all IDs > >> >>> >> must be > >> >>> >> unique. This is a particularly time consuming problem to fix > >> >>> >> because > >> >>> >> the error output from the Maven docbook plugin doesn't tell > >> >>> >> you which > >> >>> >> files are the problem ones. > >> >>> >> > >> >>> >> 3) When adding, renaming or deleting a chapter of your > >> >>> >> documentation, > >> >>> >> please notify me of the changes so that I can update > >> >>> >> bundled_master.xml. This file must be manually kept up to > >> >>> >> date whenever > >> >>> >> any documentation changes are made. > >> >>> >> > >> >>> >> Thanks, > >> >>> >> Shane > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> >> >>> >> "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" > [ ]> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> Seam 3 > >> >>> >> Bundled Reference Guide > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> Forge > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> Seam Solder > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> Seam Configuration > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> Seam Persistence > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> Seam Transaction > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> Seam Servlet > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> Seam Security > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> Seam International > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> Seam Faces > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> Seam Catch > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> Seam Reports > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> Seam Remoting > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> Seam REST > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> Seam JCR > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> Seam JMS > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> Seam Validation > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> Seam Wicket > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> _______________________________________________ > >> >>> >> seam-dev mailing list > >> >>> >> seam-dev at lists.jboss.org > > > >> >> > >> >>> > > >> >>> > >> >>> >> https://lists.jboss.org/mailman/listinfo/seam-dev > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> -- > >> >>> >> Lincoln Baxter, III > >> >>> >> http://ocpsoft.com > >> >>> >> http://scrumshark.com > >> >>> >> "Keep it Simple" > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> -- > >> >>> >> Lincoln Baxter, III > >> >>> >> http://ocpsoft.com > >> >>> >> http://scrumshark.com > >> >>> >> "Keep it Simple" > >> >>> > > >> >> > > > > > > > -- > Lincoln Baxter, III > http://ocpsoft.com > http://scrumshark.com > "Keep it Simple" -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110902/e0f1e811/attachment-0001.html From lightguard.jp at gmail.com Thu Sep 1 23:54:02 2011 From: lightguard.jp at gmail.com (Jason Porter) Date: Thu, 1 Sep 2011 21:54:02 -0600 Subject: [seam-dev] Bundled distribution documentation In-Reply-To: <4E6052DD.1090602@redhat.com> References: <4E5DB50C.3030409@redhat.com> <4E5EA2EA.2000109@redhat.com> <4E6001BD.4070301@redhat.com> <4E601AA2.7090705@redhat.com> <4E6052DD.1090602@redhat.com> Message-ID: Could we do the same thing for the getting started guide as well? On Thu, Sep 1, 2011 at 21:51, Shane Bryzak wrote: > Yeah, that's a good idea. Do you have plans to provide documentation as > part of the Forge download? I'm thinking of the users who might have > no/limited connectivity who won't be able to access the Forge docs online. > Also, how does confluence work in conjunction with our documentation team? > From my understanding all their tools for translating etc are based on > Publican/Docbook. > > > On 02/09/11 13:48, Lincoln Baxter, III wrote: > > Actually, maybe the best thing to do is just to add a new section to the > Seam umbrella doc, with an HTML link to the forge confluence space? > > On Thu, Sep 1, 2011 at 7:54 PM, Lincoln Baxter, III < > lincolnbaxter at gmail.com> wrote: > >> Ok. If you include beta1, the artifact for dist is: >> >> org.jboss.forge:forge-modules:1.0.0.Beta1 >> >> -- >> Lincoln Baxter's Droid >> http://ocpsoft.com >> "Keep it Simple" >> On Sep 1, 2011 7:52 PM, "Shane Bryzak" wrote: >> > Yep, I planned on extracting it in the forge folder. >> > >> > On 02/09/11 09:43, Lincoln Baxter, III wrote: >> >> >> >> Also, if forge is unzipped. It should be done so in its own subfolder. >> >> >> >> Ill try to catch you online tonight and make sure you've got the right >> >> artifact. (it moved temporarily during the jboss modules transition. >> >> >> >> -- >> >> Lincoln Baxter's Droid >> >> http://ocpsoft.com >> >> "Keep it Simple" >> >> >> >> On Sep 1, 2011 7:41 PM, "Lincoln Baxter, III" > >> > wrote: >> >> > Well. The forge distribution doesn't contain docs either. They are >> >> purely >> >> > online at this point. So I think just don't worry about it. This >> >> confluence >> >> > thing is a bit of a pain in that regard. >> >> > >> >> > -- >> >> > Lincoln Baxter's Droid >> >> > http://ocpsoft.com >> >> > "Keep it Simple" >> >> > On Sep 1, 2011 6:05 PM, "Shane Bryzak" > >> > wrote: >> >> >> Unless an export could be automated as part of the build process, I >> >> >> don't think that's a good idea. How about we just include the Forge >> >> >> distribution extracted inside the Seam distribution? The >> documentation >> >> >> won't be combined with the main Seam docs, but as long as it's in >> the >> >> >> Forge distribution then a user should be able to find it without too >> >> >> much effort. >> >> >> >> >> >> On 02/09/11 01:22, Lincoln Baxter, III wrote: >> >> >>> >> >> >>> I'm not really sure how to do this, then. There are no sources >> since >> >> >>> the docs are in confluence. >> >> >>> >> >> >>> I suppose an export could work? >> >> >>> >> >> >>> -- >> >> >>> Lincoln Baxter's Droid >> >> >>> http://ocpsoft.com >> >> >>> "Keep it Simple" >> >> >>> >> >> >>> On Aug 31, 2011 5:09 PM, "Shane Bryzak" > >> >> >> >>> >> wrote: >> >> >>> > The source artifact for the Forge docs were being pulled in >> like >> >> this: >> >> >>> > >> >> >>> > >> >> >>> > org.jboss.seam.forge >> >> >>> > forge-reference-guide >> >> >>> > 1.0.0-SNAPSHOT >> >> >>> > sources >> >> >>> > jar >> >> >>> > >> >> >>> > >> >> >>> > When I update the version to 1.0.0.Beta1, it can't find the >> source - >> >> >>> was >> >> >>> > the Beta1 source artifact published to Maven? >> >> >>> > >> >> >>> > >> >> >>> > >> >> >>> > On 01/09/11 03:02, Lincoln Baxter, III wrote: >> >> >>> >> https://docs.jboss.org/author/display/SEAMFORGE/Home >> >> >>> >> >> >> >>> >> On Wed, Aug 31, 2011 at 1:02 PM, Lincoln Baxter, III >> >> >>> >> >> >> > >> >> >>> >> >> >>> >> wrote: >> >> >>> >> >> >> >>> >> Just checking - the Forge docs are no longer in SVN / are in >> >> >>> >> Confluence; have you taken this into account? >> >> >>> >> >> >> >>> >> Also, the which distribution are you including? You could choose >> >> >>> >> either Beta1 or the latest SNAPSHOT (which is actually in a new >> >> >>> >> location - moved back to the original >> >> >>> >> org.jboss.forge:forge-distribution - though it looks like the >> >> >>> >> build hasn't deployed artifacts in a little while - looking in >> to >> >> >>> >> that) >> >> >>> >> >> >> >>> >> ~Lincoln >> >> >>> >> >> >> >>> >> >> >> >>> >> On Wed, Aug 31, 2011 at 12:14 AM, Shane Bryzak >> >> >> >> >>> > >> >> >>> >> >> >> >>> wrote: >> >> >>> >> >> >> >>> >> Module leads, >> >> >>> >> >> >> >>> >> Can you please review the list below and confirm that the >> >> >>> >> documentation >> >> >>> >> chapters are correct for your module. Also, I would like >> >> >>> >> everyone to >> >> >>> >> take a moment to review the module documentation guidelines, >> >> >>> >> as there >> >> >>> >> were a number of breakages in the bundled documentation build >> >> >>> >> because >> >> >>> >> the guidelines weren't adhered to, particularly in the new >> >> >>> >> modules for >> >> >>> >> Seam 3.1: >> >> >>> >> >> >> >>> >> 1) Always prefix the filenames of your documentation chapters >> >> >>> >> with the >> >> >>> >> name of your module. E.g. security-authentication.xml, >> >> >>> >> security-authorization.xml, etc. >> >> >>> >> >> >> >>> >> 2) Whenever you assign an ID to a docbook element, such as a >> >> >>> >> >> >> >>> >> or
, ALWAYS prefix the id with your module name. For >> >> >>> >> example, >> >> >>> >> or
> >> >>> >> id="security-getting-started">. As all of the chapters for >> >> >>> >> all modules >> >> >>> >> are combined when building the bundled documentation, all IDs >> >> >>> >> must be >> >> >>> >> unique. This is a particularly time consuming problem to fix >> >> >>> >> because >> >> >>> >> the error output from the Maven docbook plugin doesn't tell >> >> >>> >> you which >> >> >>> >> files are the problem ones. >> >> >>> >> >> >> >>> >> 3) When adding, renaming or deleting a chapter of your >> >> >>> >> documentation, >> >> >>> >> please notify me of the changes so that I can update >> >> >>> >> bundled_master.xml. This file must be manually kept up to >> >> >>> >> date whenever >> >> >>> >> any documentation changes are made. >> >> >>> >> >> >> >>> >> Thanks, >> >> >>> >> Shane >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> > >> >>> >> "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ ]> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> Seam 3 >> >> >>> >> Bundled Reference Guide >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> Forge >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> Seam Solder >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> Seam Configuration >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> Seam Persistence >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> Seam Transaction >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> Seam Servlet >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> Seam Security >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> Seam International >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> Seam Faces >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> Seam Catch >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> Seam Reports >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> Seam Remoting >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> Seam REST >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> Seam JCR >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> Seam JMS >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> Seam Validation >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> Seam Wicket >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> _______________________________________________ >> >> >>> >> seam-dev mailing list >> >> >>> >> seam-dev at lists.jboss.org >> >> > >> >> >>> >> >> >> >> >> >> >>> >> https://lists.jboss.org/mailman/listinfo/seam-dev >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> -- >> >> >>> >> Lincoln Baxter, III >> >> >>> >> http://ocpsoft.com >> >> >>> >> http://scrumshark.com >> >> >>> >> "Keep it Simple" >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> -- >> >> >>> >> Lincoln Baxter, III >> >> >>> >> http://ocpsoft.com >> >> >>> >> http://scrumshark.com >> >> >>> >> "Keep it Simple" >> >> >>> > >> >> >> >> > >> > > > > -- > Lincoln Baxter, III > http://ocpsoft.com > http://scrumshark.com > "Keep it Simple" > > > > _______________________________________________ > seam-dev mailing list > seam-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/seam-dev > > -- Jason Porter http://lightguard-jp.blogspot.com http://twitter.com/lightguardjp Software Engineer Open Source Advocate Author of Seam Catch - Next Generation Java Exception Handling PGP key id: 926CCFF5 PGP key available at: keyserver.net, pgp.mit.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110901/b15ccf5e/attachment-0001.html From sbryzak at redhat.com Thu Sep 1 23:55:26 2011 From: sbryzak at redhat.com (Shane Bryzak) Date: Fri, 02 Sep 2011 13:55:26 +1000 Subject: [seam-dev] Bundled distribution documentation In-Reply-To: References: <4E5DB50C.3030409@redhat.com> <4E5EA2EA.2000109@redhat.com> <4E6001BD.4070301@redhat.com> <4E601AA2.7090705@redhat.com> <4E6052DD.1090602@redhat.com> Message-ID: <4E6053AE.7010007@redhat.com> We definitely want to include the getting started guide in the reference docs. On 02/09/11 13:54, Jason Porter wrote: > Could we do the same thing for the getting started guide as well? > > On Thu, Sep 1, 2011 at 21:51, Shane Bryzak > wrote: > > Yeah, that's a good idea. Do you have plans to provide > documentation as part of the Forge download? I'm thinking of the > users who might have no/limited connectivity who won't be able to > access the Forge docs online. Also, how does confluence work in > conjunction with our documentation team? From my understanding > all their tools for translating etc are based on Publican/Docbook. > > > On 02/09/11 13:48, Lincoln Baxter, III wrote: >> Actually, maybe the best thing to do is just to add a new section >> to the Seam umbrella doc, with an HTML link to the forge >> confluence space? >> >> On Thu, Sep 1, 2011 at 7:54 PM, Lincoln Baxter, III >> > wrote: >> >> Ok. If you include beta1, the artifact for dist is: >> >> org.jboss.forge:forge-modules:1.0.0.Beta1 >> >> -- >> Lincoln Baxter's Droid >> http://ocpsoft.com >> "Keep it Simple" >> >> On Sep 1, 2011 7:52 PM, "Shane Bryzak" > > wrote: >> > Yep, I planned on extracting it in the forge folder. >> > >> > On 02/09/11 09:43, Lincoln Baxter, III wrote: >> >> >> >> Also, if forge is unzipped. It should be done so in its >> own subfolder. >> >> >> >> Ill try to catch you online tonight and make sure you've >> got the right >> >> artifact. (it moved temporarily during the jboss modules >> transition. >> >> >> >> -- >> >> Lincoln Baxter's Droid >> >> http://ocpsoft.com >> >> "Keep it Simple" >> >> >> >> On Sep 1, 2011 7:41 PM, "Lincoln Baxter, III" >> >> >> > >> wrote: >> >> > Well. The forge distribution doesn't contain docs >> either. They are >> >> purely >> >> > online at this point. So I think just don't worry about >> it. This >> >> confluence >> >> > thing is a bit of a pain in that regard. >> >> > >> >> > -- >> >> > Lincoln Baxter's Droid >> >> > http://ocpsoft.com >> >> > "Keep it Simple" >> >> > On Sep 1, 2011 6:05 PM, "Shane Bryzak" >> >> >> >> >> wrote: >> >> >> Unless an export could be automated as part of the >> build process, I >> >> >> don't think that's a good idea. How about we just >> include the Forge >> >> >> distribution extracted inside the Seam distribution? >> The documentation >> >> >> won't be combined with the main Seam docs, but as long >> as it's in the >> >> >> Forge distribution then a user should be able to find >> it without too >> >> >> much effort. >> >> >> >> >> >> On 02/09/11 01:22, Lincoln Baxter, III wrote: >> >> >>> >> >> >>> I'm not really sure how to do this, then. There are no >> sources since >> >> >>> the docs are in confluence. >> >> >>> >> >> >>> I suppose an export could work? >> >> >>> >> >> >>> -- >> >> >>> Lincoln Baxter's Droid >> >> >>> http://ocpsoft.com >> >> >>> "Keep it Simple" >> >> >>> >> >> >>> On Aug 31, 2011 5:09 PM, "Shane Bryzak" >> >> >> > >> >> >>> >> >>> wrote: >> >> >>> > The source artifact for the Forge docs were being >> pulled in like >> >> this: >> >> >>> > >> >> >>> > >> >> >>> > org.jboss.seam.forge >> >> >>> > forge-reference-guide >> >> >>> > 1.0.0-SNAPSHOT >> >> >>> > sources >> >> >>> > jar >> >> >>> > >> >> >>> > >> >> >>> > When I update the version to 1.0.0.Beta1, it can't >> find the source - >> >> >>> was >> >> >>> > the Beta1 source artifact published to Maven? >> >> >>> > >> >> >>> > >> >> >>> > >> >> >>> > On 01/09/11 03:02, Lincoln Baxter, III wrote: >> >> >>> >> https://docs.jboss.org/author/display/SEAMFORGE/Home >> >> >>> >> >> >> >>> >> On Wed, Aug 31, 2011 at 1:02 PM, Lincoln Baxter, III >> >> >>> >> > >> > > >> >> > >> > >> >> >> >>> > >> > > >> >> > >> > >>>> wrote: >> >> >>> >> >> >> >>> >> Just checking - the Forge docs are no longer in SVN >> / are in >> >> >>> >> Confluence; have you taken this into account? >> >> >>> >> >> >> >>> >> Also, the which distribution are you including? You >> could choose >> >> >>> >> either Beta1 or the latest SNAPSHOT (which is >> actually in a new >> >> >>> >> location - moved back to the original >> >> >>> >> org.jboss.forge:forge-distribution - though it >> looks like the >> >> >>> >> build hasn't deployed artifacts in a little while - >> looking in to >> >> >>> >> that) >> >> >>> >> >> >> >>> >> ~Lincoln >> >> >>> >> >> >> >>> >> >> >> >>> >> On Wed, Aug 31, 2011 at 12:14 AM, Shane Bryzak >> >> >> > >> >> >>> >> >> >> >> >>> >> > > > >> >> >> >>>> wrote: >> >> >>> >> >> >> >>> >> Module leads, >> >> >>> >> >> >> >>> >> Can you please review the list below and confirm >> that the >> >> >>> >> documentation >> >> >>> >> chapters are correct for your module. Also, I would >> like >> >> >>> >> everyone to >> >> >>> >> take a moment to review the module documentation >> guidelines, >> >> >>> >> as there >> >> >>> >> were a number of breakages in the bundled >> documentation build >> >> >>> >> because >> >> >>> >> the guidelines weren't adhered to, particularly in >> the new >> >> >>> >> modules for >> >> >>> >> Seam 3.1: >> >> >>> >> >> >> >>> >> 1) Always prefix the filenames of your >> documentation chapters >> >> >>> >> with the >> >> >>> >> name of your module. E.g. security-authentication.xml, >> >> >>> >> security-authorization.xml, etc. >> >> >>> >> >> >> >>> >> 2) Whenever you assign an ID to a docbook element, >> such as a >> >> >>> >> >> >> >>> >> or
, ALWAYS prefix the id with your module >> name. For >> >> >>> >> example, >> >> >>> >> or
> >> >>> >> id="security-getting-started">. As all of the >> chapters for >> >> >>> >> all modules >> >> >>> >> are combined when building the bundled >> documentation, all IDs >> >> >>> >> must be >> >> >>> >> unique. This is a particularly time consuming >> problem to fix >> >> >>> >> because >> >> >>> >> the error output from the Maven docbook plugin >> doesn't tell >> >> >>> >> you which >> >> >>> >> files are the problem ones. >> >> >>> >> >> >> >>> >> 3) When adding, renaming or deleting a chapter of your >> >> >>> >> documentation, >> >> >>> >> please notify me of the changes so that I can update >> >> >>> >> bundled_master.xml. This file must be manually kept >> up to >> >> >>> >> date whenever >> >> >>> >> any documentation changes are made. >> >> >>> >> >> >> >>> >> Thanks, >> >> >>> >> Shane >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> > V4.5//EN" >> >> >>> >> >> "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ ]> >> >> >>> >> > xmlns:xi="http://www.w3.org/2001/XInclude"> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> Seam 3 >> >> >>> >> Bundled Reference Guide >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> Forge >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> Seam Solder >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> Seam Configuration >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> Seam Persistence >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> Seam Transaction >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> Seam Servlet >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> Seam Security >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> > href="security-authentication-external.xml"/> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> Seam International >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> Seam Faces >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> Seam Catch >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> Seam Reports >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> Seam Remoting >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> Seam REST >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> Seam JCR >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> Seam JMS >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> Seam Validation >> >> >>> >> >> >> >>> >> >> >> >>> >> > href="validation-dependency-injection.xml"/> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> Seam Wicket >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> _______________________________________________ >> >> >>> >> seam-dev mailing list >> >> >>> >> seam-dev at lists.jboss.org >> >> > > >> >> > >> > >> >> >> >>> > >> > > >> >> > >> > >>> >> >> >>> >> https://lists.jboss.org/mailman/listinfo/seam-dev >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> -- >> >> >>> >> Lincoln Baxter, III >> >> >>> >> http://ocpsoft.com >> >> >>> >> http://scrumshark.com >> >> >>> >> "Keep it Simple" >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> -- >> >> >>> >> Lincoln Baxter, III >> >> >>> >> http://ocpsoft.com >> >> >>> >> http://scrumshark.com >> >> >>> >> "Keep it Simple" >> >> >>> > >> >> >> >> > >> >> >> >> >> -- >> Lincoln Baxter, III >> http://ocpsoft.com >> http://scrumshark.com >> "Keep it Simple" > > > _______________________________________________ > seam-dev mailing list > seam-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/seam-dev > > > > > -- > Jason Porter > http://lightguard-jp.blogspot.com > http://twitter.com/lightguardjp > > Software Engineer > Open Source Advocate > Author of Seam Catch - Next Generation Java Exception Handling > > PGP key id: 926CCFF5 > PGP key available at: keyserver.net , > pgp.mit.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110902/25d4e9c8/attachment-0001.html From lincolnbaxter at gmail.com Fri Sep 2 00:15:06 2011 From: lincolnbaxter at gmail.com (Lincoln Baxter, III) Date: Fri, 2 Sep 2011 00:15:06 -0400 Subject: [seam-dev] Bundled distribution documentation In-Reply-To: <4E6052DD.1090602@redhat.com> References: <4E5DB50C.3030409@redhat.com> <4E5EA2EA.2000109@redhat.com> <4E6001BD.4070301@redhat.com> <4E601AA2.7090705@redhat.com> <4E6052DD.1090602@redhat.com> Message-ID: I don't know. I don't really have plans to include docbook in the dist until we get some better integration there from the .ORG team. I don't see that happening, though, so until then, online docs are the way people will be learning about forge. Our tools don't make this easy. I don't think the connectivity issue will be a problem. People can always print or download the site for later if they have connectivity issues. It might be nice (on confluence) to be able to have a 1-click download, though. ~Lincoln On Thu, Sep 1, 2011 at 11:51 PM, Shane Bryzak wrote: > Yeah, that's a good idea. Do you have plans to provide documentation as > part of the Forge download? I'm thinking of the users who might have > no/limited connectivity who won't be able to access the Forge docs online. > Also, how does confluence work in conjunction with our documentation team? > From my understanding all their tools for translating etc are based on > Publican/Docbook. > > > On 02/09/11 13:48, Lincoln Baxter, III wrote: > > Actually, maybe the best thing to do is just to add a new section to the > Seam umbrella doc, with an HTML link to the forge confluence space? > > On Thu, Sep 1, 2011 at 7:54 PM, Lincoln Baxter, III < > lincolnbaxter at gmail.com> wrote: > >> Ok. If you include beta1, the artifact for dist is: >> >> org.jboss.forge:forge-modules:1.0.0.Beta1 >> >> -- >> Lincoln Baxter's Droid >> http://ocpsoft.com >> "Keep it Simple" >> On Sep 1, 2011 7:52 PM, "Shane Bryzak" wrote: >> > Yep, I planned on extracting it in the forge folder. >> > >> > On 02/09/11 09:43, Lincoln Baxter, III wrote: >> >> >> >> Also, if forge is unzipped. It should be done so in its own subfolder. >> >> >> >> Ill try to catch you online tonight and make sure you've got the right >> >> artifact. (it moved temporarily during the jboss modules transition. >> >> >> >> -- >> >> Lincoln Baxter's Droid >> >> http://ocpsoft.com >> >> "Keep it Simple" >> >> >> >> On Sep 1, 2011 7:41 PM, "Lincoln Baxter, III" > >> > wrote: >> >> > Well. The forge distribution doesn't contain docs either. They are >> >> purely >> >> > online at this point. So I think just don't worry about it. This >> >> confluence >> >> > thing is a bit of a pain in that regard. >> >> > >> >> > -- >> >> > Lincoln Baxter's Droid >> >> > http://ocpsoft.com >> >> > "Keep it Simple" >> >> > On Sep 1, 2011 6:05 PM, "Shane Bryzak" > >> > wrote: >> >> >> Unless an export could be automated as part of the build process, I >> >> >> don't think that's a good idea. How about we just include the Forge >> >> >> distribution extracted inside the Seam distribution? The >> documentation >> >> >> won't be combined with the main Seam docs, but as long as it's in >> the >> >> >> Forge distribution then a user should be able to find it without too >> >> >> much effort. >> >> >> >> >> >> On 02/09/11 01:22, Lincoln Baxter, III wrote: >> >> >>> >> >> >>> I'm not really sure how to do this, then. There are no sources >> since >> >> >>> the docs are in confluence. >> >> >>> >> >> >>> I suppose an export could work? >> >> >>> >> >> >>> -- >> >> >>> Lincoln Baxter's Droid >> >> >>> http://ocpsoft.com >> >> >>> "Keep it Simple" >> >> >>> >> >> >>> On Aug 31, 2011 5:09 PM, "Shane Bryzak" > >> >> >> >>> >> wrote: >> >> >>> > The source artifact for the Forge docs were being pulled in >> like >> >> this: >> >> >>> > >> >> >>> > >> >> >>> > org.jboss.seam.forge >> >> >>> > forge-reference-guide >> >> >>> > 1.0.0-SNAPSHOT >> >> >>> > sources >> >> >>> > jar >> >> >>> > >> >> >>> > >> >> >>> > When I update the version to 1.0.0.Beta1, it can't find the >> source - >> >> >>> was >> >> >>> > the Beta1 source artifact published to Maven? >> >> >>> > >> >> >>> > >> >> >>> > >> >> >>> > On 01/09/11 03:02, Lincoln Baxter, III wrote: >> >> >>> >> https://docs.jboss.org/author/display/SEAMFORGE/Home >> >> >>> >> >> >> >>> >> On Wed, Aug 31, 2011 at 1:02 PM, Lincoln Baxter, III >> >> >>> >> >> >> > >> >> >>> >> >> >>> >> wrote: >> >> >>> >> >> >> >>> >> Just checking - the Forge docs are no longer in SVN / are in >> >> >>> >> Confluence; have you taken this into account? >> >> >>> >> >> >> >>> >> Also, the which distribution are you including? You could choose >> >> >>> >> either Beta1 or the latest SNAPSHOT (which is actually in a new >> >> >>> >> location - moved back to the original >> >> >>> >> org.jboss.forge:forge-distribution - though it looks like the >> >> >>> >> build hasn't deployed artifacts in a little while - looking in >> to >> >> >>> >> that) >> >> >>> >> >> >> >>> >> ~Lincoln >> >> >>> >> >> >> >>> >> >> >> >>> >> On Wed, Aug 31, 2011 at 12:14 AM, Shane Bryzak >> >> >> >> >>> > >> >> >>> >> >> >> >>> wrote: >> >> >>> >> >> >> >>> >> Module leads, >> >> >>> >> >> >> >>> >> Can you please review the list below and confirm that the >> >> >>> >> documentation >> >> >>> >> chapters are correct for your module. Also, I would like >> >> >>> >> everyone to >> >> >>> >> take a moment to review the module documentation guidelines, >> >> >>> >> as there >> >> >>> >> were a number of breakages in the bundled documentation build >> >> >>> >> because >> >> >>> >> the guidelines weren't adhered to, particularly in the new >> >> >>> >> modules for >> >> >>> >> Seam 3.1: >> >> >>> >> >> >> >>> >> 1) Always prefix the filenames of your documentation chapters >> >> >>> >> with the >> >> >>> >> name of your module. E.g. security-authentication.xml, >> >> >>> >> security-authorization.xml, etc. >> >> >>> >> >> >> >>> >> 2) Whenever you assign an ID to a docbook element, such as a >> >> >>> >> >> >> >>> >> or
, ALWAYS prefix the id with your module name. For >> >> >>> >> example, >> >> >>> >> or
> >> >>> >> id="security-getting-started">. As all of the chapters for >> >> >>> >> all modules >> >> >>> >> are combined when building the bundled documentation, all IDs >> >> >>> >> must be >> >> >>> >> unique. This is a particularly time consuming problem to fix >> >> >>> >> because >> >> >>> >> the error output from the Maven docbook plugin doesn't tell >> >> >>> >> you which >> >> >>> >> files are the problem ones. >> >> >>> >> >> >> >>> >> 3) When adding, renaming or deleting a chapter of your >> >> >>> >> documentation, >> >> >>> >> please notify me of the changes so that I can update >> >> >>> >> bundled_master.xml. This file must be manually kept up to >> >> >>> >> date whenever >> >> >>> >> any documentation changes are made. >> >> >>> >> >> >> >>> >> Thanks, >> >> >>> >> Shane >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> > >> >>> >> "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ ]> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> Seam 3 >> >> >>> >> Bundled Reference Guide >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> Forge >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> Seam Solder >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> Seam Configuration >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> Seam Persistence >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> Seam Transaction >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> Seam Servlet >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> Seam Security >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> Seam International >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> Seam Faces >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> Seam Catch >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> Seam Reports >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> Seam Remoting >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> Seam REST >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> Seam JCR >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> Seam JMS >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> Seam Validation >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> Seam Wicket >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> _______________________________________________ >> >> >>> >> seam-dev mailing list >> >> >>> >> seam-dev at lists.jboss.org >> >> > >> >> >>> >> >> >> >> >> >> >>> >> https://lists.jboss.org/mailman/listinfo/seam-dev >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> -- >> >> >>> >> Lincoln Baxter, III >> >> >>> >> http://ocpsoft.com >> >> >>> >> http://scrumshark.com >> >> >>> >> "Keep it Simple" >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> -- >> >> >>> >> Lincoln Baxter, III >> >> >>> >> http://ocpsoft.com >> >> >>> >> http://scrumshark.com >> >> >>> >> "Keep it Simple" >> >> >>> > >> >> >> >> > >> > > > > -- > Lincoln Baxter, III > http://ocpsoft.com > http://scrumshark.com > "Keep it Simple" > > > -- Lincoln Baxter, III http://ocpsoft.com http://scrumshark.com "Keep it Simple" -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110902/309024cc/attachment-0001.html From mnovotny at redhat.com Fri Sep 2 05:35:13 2011 From: mnovotny at redhat.com (Marek Novotny) Date: Fri, 02 Sep 2011 11:35:13 +0200 Subject: [seam-dev] Bundled distribution documentation In-Reply-To: References: <4E5DB50C.3030409@redhat.com> <4E5EA2EA.2000109@redhat.com> <4E6001BD.4070301@redhat.com> <4E601AA2.7090705@redhat.com> <4E6052DD.1090602@redhat.com> Message-ID: <1314956113.2908.9.camel@localhost.localdomain> What about using feature "Export to docbook" and then just generate standard jdocbook output in release process? https://docs.jboss.org/author/display/AUTHGUIDE/Exporting+content+to +DocBook+XML On Fri, 2011-09-02 at 00:15 -0400, Lincoln Baxter, III wrote: > I don't know. I don't really have plans to include docbook in the dist > until we get some better integration there from the .ORG team. I don't > see that happening, though, so until then, online docs are the way > people will be learning about forge. Our tools don't make this easy. > > I don't think the connectivity issue will be a problem. People can > always print or download the site for later if they have connectivity > issues. It might be nice (on confluence) to be able to have a 1-click > download, though. > > ~Lincoln > > On Thu, Sep 1, 2011 at 11:51 PM, Shane Bryzak > wrote: > Yeah, that's a good idea. Do you have plans to provide > documentation as part of the Forge download? I'm thinking of > the users who might have no/limited connectivity who won't be > able to access the Forge docs online. Also, how does > confluence work in conjunction with our documentation team? > From my understanding all their tools for translating etc are > based on Publican/Docbook. > > > > On 02/09/11 13:48, Lincoln Baxter, III wrote: > > Actually, maybe the best thing to do is just to add a new > > section to the Seam umbrella doc, with an HTML link to the > > forge confluence space? > > > > On Thu, Sep 1, 2011 at 7:54 PM, Lincoln Baxter, III > > wrote: > > Ok. If you include beta1, the artifact for dist is: > > > > org.jboss.forge:forge-modules:1.0.0.Beta1 > > > > -- > > Lincoln Baxter's Droid > > http://ocpsoft.com > > "Keep it Simple" > > > > > > On Sep 1, 2011 7:52 PM, "Shane Bryzak" > > wrote: > > > Yep, I planned on extracting it in the forge > > folder. > > > > > > On 02/09/11 09:43, Lincoln Baxter, III wrote: > > >> > > >> Also, if forge is unzipped. It should be done so > > in its own subfolder. > > >> > > >> Ill try to catch you online tonight and make sure > > you've got the right > > >> artifact. (it moved temporarily during the jboss > > modules transition. > > >> > > >> -- > > >> Lincoln Baxter's Droid > > >> http://ocpsoft.com > > >> "Keep it Simple" > > >> > > >> On Sep 1, 2011 7:41 PM, "Lincoln Baxter, III" > > > > > >> > wrote: > > > > >> > Well. The forge distribution doesn't contain > > docs either. They are > > >> purely > > >> > online at this point. So I think just don't > > worry about it. This > > >> confluence > > >> > thing is a bit of a pain in that regard. > > >> > > > >> > -- > > >> > Lincoln Baxter's Droid > > >> > http://ocpsoft.com > > >> > "Keep it Simple" > > >> > On Sep 1, 2011 6:05 PM, "Shane Bryzak" > > > > > >> > wrote: > > >> >> Unless an export could be automated as part of > > the build process, I > > >> >> don't think that's a good idea. How about we > > just include the Forge > > >> >> distribution extracted inside the Seam > > distribution? The documentation > > >> >> won't be combined with the main Seam docs, but > > as long as it's in the > > >> >> Forge distribution then a user should be able > > to find it without too > > >> >> much effort. > > >> >> > > >> >> On 02/09/11 01:22, Lincoln Baxter, III wrote: > > >> >>> > > >> >>> I'm not really sure how to do this, then. > > There are no sources since > > >> >>> the docs are in confluence. > > >> >>> > > >> >>> I suppose an export could work? > > >> >>> > > >> >>> -- > > >> >>> Lincoln Baxter's Droid > > >> >>> http://ocpsoft.com > > >> >>> "Keep it Simple" > > >> >>> > > >> >>> On Aug 31, 2011 5:09 PM, "Shane Bryzak" > > > >> > > > > >> >>> > >> wrote: > > > > >> >>> > The source artifact for the Forge docs were > > being pulled in like > > >> this: > > >> >>> > > > >> >>> > > > >> >>> > org.jboss.seam.forge > > >> >>> > > > forge-reference-guide > > >> >>> > 1.0.0-SNAPSHOT > > >> >>> > sources > > >> >>> > jar > > >> >>> > > > >> >>> > > > >> >>> > When I update the version to 1.0.0.Beta1, > > it can't find the source - > > >> >>> was > > >> >>> > the Beta1 source artifact published to > > Maven? > > >> >>> > > > >> >>> > > > >> >>> > > > >> >>> > On 01/09/11 03:02, Lincoln Baxter, III > > wrote: > > >> >>> >> > > https://docs.jboss.org/author/display/SEAMFORGE/Home > > >> >>> >> > > >> >>> >> On Wed, Aug 31, 2011 at 1:02 PM, Lincoln > > Baxter, III > > >> >>> >> > > > >> > > > > >> >>> > > > >> > >>> wrote: > > >> >>> >> > > >> >>> >> Just checking - the Forge docs are no > > longer in SVN / are in > > >> >>> >> Confluence; have you taken this into > > account? > > >> >>> >> > > >> >>> >> Also, the which distribution are you > > including? You could choose > > >> >>> >> either Beta1 or the latest SNAPSHOT (which > > is actually in a new > > >> >>> >> location - moved back to the original > > >> >>> >> org.jboss.forge:forge-distribution - > > though it looks like the > > >> >>> >> build hasn't deployed artifacts in a > > little while - looking in to > > >> >>> >> that) > > >> >>> >> > > >> >>> >> ~Lincoln > > >> >>> >> > > >> >>> >> > > >> >>> >> On Wed, Aug 31, 2011 at 12:14 AM, Shane > > Bryzak > > >> > > >> >>> > > > > >> >>> >> > > > >> > >>> wrote: > > >> >>> >> > > >> >>> >> Module leads, > > >> >>> >> > > >> >>> >> Can you please review the list below and > > confirm that the > > >> >>> >> documentation > > >> >>> >> chapters are correct for your module. > > Also, I would like > > >> >>> >> everyone to > > >> >>> >> take a moment to review the module > > documentation guidelines, > > >> >>> >> as there > > >> >>> >> were a number of breakages in the bundled > > documentation build > > >> >>> >> because > > >> >>> >> the guidelines weren't adhered to, > > particularly in the new > > >> >>> >> modules for > > >> >>> >> Seam 3.1: > > >> >>> >> > > >> >>> >> 1) Always prefix the filenames of your > > documentation chapters > > >> >>> >> with the > > >> >>> >> name of your module. E.g. > > security-authentication.xml, > > >> >>> >> security-authorization.xml, etc. > > >> >>> >> > > >> >>> >> 2) Whenever you assign an ID to a docbook > > element, such as a > > >> >>> >> > > >> >>> >> or
, ALWAYS prefix the id with > > your module name. For > > >> >>> >> example, > > >> >>> >> or > >
> >> >>> >> id="security-getting-started">. As all of > > the chapters for > > >> >>> >> all modules > > >> >>> >> are combined when building the bundled > > documentation, all IDs > > >> >>> >> must be > > >> >>> >> unique. This is a particularly time > > consuming problem to fix > > >> >>> >> because > > >> >>> >> the error output from the Maven docbook > > plugin doesn't tell > > >> >>> >> you which > > >> >>> >> files are the problem ones. > > >> >>> >> > > >> >>> >> 3) When adding, renaming or deleting a > > chapter of your > > >> >>> >> documentation, > > >> >>> >> please notify me of the changes so that I > > can update > > >> >>> >> bundled_master.xml. This file must be > > manually kept up to > > >> >>> >> date whenever > > >> >>> >> any documentation changes are made. > > >> >>> >> > > >> >>> >> Thanks, > > >> >>> >> Shane > > >> >>> >> > > >> >>> >> > > >> >>> >> > > >> >>> >> > DocBook XML V4.5//EN" > > >> >>> >> > > "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ ]> > > >> >>> >> > xmlns:xi="http://www.w3.org/2001/XInclude"> > > >> >>> >> > > >> >>> >> > > >> >>> >> > > >> >>> >> Seam 3 > > >> >>> >> Bundled Reference > > Guide > > >> >>> >> > > >> >>> >> > > >> >>> >> > > >> >>> >> > > >> >>> >> > > >> >>> >> Forge > > >> >>> >> > > >> >>> >> > href="forge-installation.xml" /> > > >> >>> >> > href="forge-creating-basic-webapp.xml" /> > > >> >>> >> > > >> >>> >> > > >> >>> >> > > >> >>> >> > > >> >>> >> Seam Solder > > >> >>> >> > > >> >>> >> > href="solder-gettingstarted.xml"/> > > >> >>> >> > href="solder-programmingmodel.xml"/> > > >> >>> >> > href="solder-annotationliterals.xml"/> > > >> >>> >> > href="solder-elextensions.xml"/> > > >> >>> >> > href="solder-resourceloading.xml"/> > > >> >>> >> > > >> >>> >> > href="solder-typeutilities.xml"/> > > >> >>> >> > href="solder-beanmanagerprovider.xml"/> > > >> >>> >> > href="solder-beanutilities.xml"/> > > >> >>> >> > > >> >>> >> > > >> >>> >> > href="solder-defaultbeans.xml"/> > > >> >>> >> > href="solder-genericbeans.xml"/> > > >> >>> >> > href="solder-servicehandler.xml"/> > > >> >>> >> > > >> >>> >> > > >> >>> >> > > >> >>> >> Seam Configuration > > >> >>> >> > href="config-introduction.xml"/> > > >> >>> >> > href="config-xml-provider.xml"/> > > >> >>> >> > > >> >>> >> > > >> >>> >> > > >> >>> >> Seam Persistence > > >> >>> >> > href="persistence-general.xml"/> > > >> >>> >> > > >> >>> >> > > >> >>> >> > > >> >>> >> Seam Transaction > > >> >>> >> > href="transaction-general.xml"/> > > >> >>> >> > > >> >>> >> > > >> >>> >> > > >> >>> >> Seam Servlet > > >> >>> >> > href="servlet-introduction.xml"/> > > >> >>> >> > href="servlet-installation.xml"/> > > >> >>> >> > > >> >>> >> > href="servlet-injectable_refs.xml"/> > > >> >>> >> > href="servlet-exception_handling.xml" /> > > >> >>> >> > href="servlet-beanmanager.xml"/> > > >> >>> >> > > >> >>> >> > > >> >>> >> > > >> >>> >> Seam Security > > >> >>> >> > href="security-introduction.xml"/> > > >> >>> >> > href="security-authentication.xml"/> > > >> >>> >> > href="security-identitymanagement.xml"/> > > >> >>> >> > href="security-authentication-external.xml"/> > > >> >>> >> > href="security-authorization.xml"/> > > >> >>> >> > > >> >>> >> > > >> >>> >> > > >> >>> >> Seam International > > >> >>> >> > href="international-preface.xml" /> > > >> >>> >> > href="international-installation.xml" /> > > >> >>> >> > href="international-locales.xml" /> > > >> >>> >> > href="international-timezones.xml" /> > > >> >>> >> > href="international-messages.xml" /> > > >> >>> >> > > >> >>> >> > > >> >>> >> > > >> >>> >> Seam Faces > > >> >>> >> > > >> >>> >> > href="faces-installation.xml" /> > > >> >>> >> > > >> >>> >> > > >> >>> >> > > >> >>> >> > > >> >>> >> > > >> >>> >> > > >> >>> >> > > >> >>> >> > > >> >>> >> Seam Catch > > >> >>> >> > href="catch-introduction.xml"/> > > >> >>> >> > href="catch-installation.xml"/> > > >> >>> >> > href="catch-client_usage.xml"/> > > >> >>> >> > href="catch-advanced_usage.xml"/> > > >> >>> >> > > >> >>> >> > > >> >>> >> > > >> >>> >> > > >> >>> >> > > >> >>> >> Seam Reports > > >> >>> >> > > >> >>> >> > href="reports-installation.xml" /> > > >> >>> >> > > >> >>> >> > > >> >>> >> > > >> >>> >> > > >> >>> >> Seam Remoting > > >> >>> >> > > >> >>> >> > > >> >>> >> > href="remoting-validation.xml"/> > > >> >>> >> > > >> >>> >> > > >> >>> >> > > >> >>> >> Seam REST > > >> >>> >> > > >> >>> >> > href="rest-installation.xml" /> > > >> >>> >> > href="rest-exception-mapping.xml" /> > > >> >>> >> > > >> >>> >> > > >> >>> >> > > >> >>> >> > href="rest-dependencies.xml" /> > > >> >>> >> > > >> >>> >> > > >> >>> >> > > >> >>> >> Seam JCR > > >> >>> >> > > >> >>> >> > > >> >>> >> > > >> >>> >> > > >> >>> >> > > >> >>> >> > > >> >>> >> > > >> >>> >> > > >> >>> >> Seam JMS > > >> >>> >> > > >> >>> >> > > >> >>> >> > href="jms-resource-injection.xml" /> > > >> >>> >> > > >> >>> >> > > >> >>> >> > href="jms-mapping-interfaces.xml" /> > > >> >>> >> > > >> >>> >> > > >> >>> >> > > >> >>> >> Seam Validation > > >> >>> >> > href="validation-introduction.xml"/> > > >> >>> >> > href="validation-installation.xml"/> > > >> >>> >> > href="validation-dependency-injection.xml"/> > > >> >>> >> > href="validation-method-validation.xml"/> > > >> >>> >> > > >> >>> >> > > >> >>> >> > > >> >>> >> Seam Wicket > > >> >>> >> > > >> >>> >> > href="wicket-installation.xml" /> > > >> >>> >> > > >> >>> >> > > >> >>> >> > > >> >>> >> > > >> >>> >> > > _______________________________________________ > > >> >>> >> seam-dev mailing list > > >> >>> >> seam-dev at lists.jboss.org > > > > >> > > > > >> >>> > > > >> > >> > > >> >>> >> > > https://lists.jboss.org/mailman/listinfo/seam-dev > > >> >>> >> > > >> >>> >> > > >> >>> >> > > >> >>> >> > > >> >>> >> -- > > >> >>> >> Lincoln Baxter, III > > >> >>> >> http://ocpsoft.com > > >> >>> >> http://scrumshark.com > > >> >>> >> "Keep it Simple" > > >> >>> >> > > >> >>> >> > > >> >>> >> > > >> >>> >> > > >> >>> >> -- > > >> >>> >> Lincoln Baxter, III > > >> >>> >> http://ocpsoft.com > > >> >>> >> http://scrumshark.com > > >> >>> >> "Keep it Simple" > > >> >>> > > > >> >> > > > > > > > > > > > > > -- > > Lincoln Baxter, III > > http://ocpsoft.com > > http://scrumshark.com > > "Keep it Simple" > > > > > > -- > Lincoln Baxter, III > http://ocpsoft.com > http://scrumshark.com > "Keep it Simple" > _______________________________________________ > seam-dev mailing list > seam-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/seam-dev -- Marek Novotny -- Seam and WFK Product Lead Red Hat Czech s.r.o. Purkynova 99 612 45 Brno Email: mnovotny at redhat.com Office phone: +420 532 294 287, ext. 82-62 087 mobile: +420 608 509 230 From sbryzak at redhat.com Fri Sep 2 06:43:38 2011 From: sbryzak at redhat.com (Shane Bryzak) Date: Fri, 02 Sep 2011 20:43:38 +1000 Subject: [seam-dev] Bundled distribution documentation In-Reply-To: <1314956113.2908.9.camel@localhost.localdomain> References: <4E5DB50C.3030409@redhat.com> <4E5EA2EA.2000109@redhat.com> <4E6001BD.4070301@redhat.com> <4E601AA2.7090705@redhat.com> <4E6052DD.1090602@redhat.com> <1314956113.2908.9.camel@localhost.localdomain> Message-ID: <4E60B35A.1090504@redhat.com> This would need to be automated for the Seam distribution build though. Currently, all modules have their docbook sources published as Maven artifacts, which is what we use to construct the bundled documentation. On 02/09/11 19:35, Marek Novotny wrote: > What about using feature "Export to docbook" and then just generate > standard jdocbook output in release process? > > https://docs.jboss.org/author/display/AUTHGUIDE/Exporting+content+to > +DocBook+XML > > On Fri, 2011-09-02 at 00:15 -0400, Lincoln Baxter, III wrote: >> I don't know. I don't really have plans to include docbook in the dist >> until we get some better integration there from the .ORG team. I don't >> see that happening, though, so until then, online docs are the way >> people will be learning about forge. Our tools don't make this easy. >> >> I don't think the connectivity issue will be a problem. People can >> always print or download the site for later if they have connectivity >> issues. It might be nice (on confluence) to be able to have a 1-click >> download, though. >> >> ~Lincoln >> >> On Thu, Sep 1, 2011 at 11:51 PM, Shane Bryzak >> wrote: >> Yeah, that's a good idea. Do you have plans to provide >> documentation as part of the Forge download? I'm thinking of >> the users who might have no/limited connectivity who won't be >> able to access the Forge docs online. Also, how does >> confluence work in conjunction with our documentation team? >> From my understanding all their tools for translating etc are >> based on Publican/Docbook. >> >> >> >> On 02/09/11 13:48, Lincoln Baxter, III wrote: >> > Actually, maybe the best thing to do is just to add a new >> > section to the Seam umbrella doc, with an HTML link to the >> > forge confluence space? >> > >> > On Thu, Sep 1, 2011 at 7:54 PM, Lincoln Baxter, III >> > wrote: >> > Ok. If you include beta1, the artifact for dist is: >> > >> > org.jboss.forge:forge-modules:1.0.0.Beta1 >> > >> > -- >> > Lincoln Baxter's Droid >> > http://ocpsoft.com >> > "Keep it Simple" >> > >> > >> > On Sep 1, 2011 7:52 PM, "Shane Bryzak" >> > wrote: >> > > Yep, I planned on extracting it in the forge >> > folder. >> > > >> > > On 02/09/11 09:43, Lincoln Baxter, III wrote: >> > >> >> > >> Also, if forge is unzipped. It should be done so >> > in its own subfolder. >> > >> >> > >> Ill try to catch you online tonight and make sure >> > you've got the right >> > >> artifact. (it moved temporarily during the jboss >> > modules transition. >> > >> >> > >> -- >> > >> Lincoln Baxter's Droid >> > >> http://ocpsoft.com >> > >> "Keep it Simple" >> > >> >> > >> On Sep 1, 2011 7:41 PM, "Lincoln Baxter, III" >> > > > >> > >> > wrote: >> > >> > >> > Well. The forge distribution doesn't contain >> > docs either. They are >> > >> purely >> > >> > online at this point. So I think just don't >> > worry about it. This >> > >> confluence >> > >> > thing is a bit of a pain in that regard. >> > >> > >> > >> > -- >> > >> > Lincoln Baxter's Droid >> > >> > http://ocpsoft.com >> > >> > "Keep it Simple" >> > >> > On Sep 1, 2011 6:05 PM, "Shane Bryzak" >> > > > >> > >> > wrote: >> > >> >> Unless an export could be automated as part of >> > the build process, I >> > >> >> don't think that's a good idea. How about we >> > just include the Forge >> > >> >> distribution extracted inside the Seam >> > distribution? The documentation >> > >> >> won't be combined with the main Seam docs, but >> > as long as it's in the >> > >> >> Forge distribution then a user should be able >> > to find it without too >> > >> >> much effort. >> > >> >> >> > >> >> On 02/09/11 01:22, Lincoln Baxter, III wrote: >> > >> >>> >> > >> >>> I'm not really sure how to do this, then. >> > There are no sources since >> > >> >>> the docs are in confluence. >> > >> >>> >> > >> >>> I suppose an export could work? >> > >> >>> >> > >> >>> -- >> > >> >>> Lincoln Baxter's Droid >> > >> >>> http://ocpsoft.com >> > >> >>> "Keep it Simple" >> > >> >>> >> > >> >>> On Aug 31, 2011 5:09 PM, "Shane Bryzak" >> > > > >> >> > >> > >> >>> > > >> wrote: >> > >> > >> >>> > The source artifact for the Forge docs were >> > being pulled in like >> > >> this: >> > >> >>> > >> > >> >>> > >> > >> >>> > org.jboss.seam.forge >> > >> >>> > >> > forge-reference-guide >> > >> >>> > 1.0.0-SNAPSHOT >> > >> >>> > sources >> > >> >>> > jar >> > >> >>> > >> > >> >>> > >> > >> >>> > When I update the version to 1.0.0.Beta1, >> > it can't find the source - >> > >> >>> was >> > >> >>> > the Beta1 source artifact published to >> > Maven? >> > >> >>> > >> > >> >>> > >> > >> >>> > >> > >> >>> > On 01/09/11 03:02, Lincoln Baxter, III >> > wrote: >> > >> >>> >> >> > https://docs.jboss.org/author/display/SEAMFORGE/Home >> > >> >>> >> >> > >> >>> >> On Wed, Aug 31, 2011 at 1:02 PM, Lincoln >> > Baxter, III >> > >> >>> >> > > >> > >> > > > >> > >> >>> > > >> > >> > > >>> wrote: >> > >> >>> >> >> > >> >>> >> Just checking - the Forge docs are no >> > longer in SVN / are in >> > >> >>> >> Confluence; have you taken this into >> > account? >> > >> >>> >> >> > >> >>> >> Also, the which distribution are you >> > including? You could choose >> > >> >>> >> either Beta1 or the latest SNAPSHOT (which >> > is actually in a new >> > >> >>> >> location - moved back to the original >> > >> >>> >> org.jboss.forge:forge-distribution - >> > though it looks like the >> > >> >>> >> build hasn't deployed artifacts in a >> > little while - looking in to >> > >> >>> >> that) >> > >> >>> >> >> > >> >>> >> ~Lincoln >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> On Wed, Aug 31, 2011 at 12:14 AM, Shane >> > Bryzak >> > >> >> > >> >>> > > > >> > >> >>> >> > > >> > >> > > >>> wrote: >> > >> >>> >> >> > >> >>> >> Module leads, >> > >> >>> >> >> > >> >>> >> Can you please review the list below and >> > confirm that the >> > >> >>> >> documentation >> > >> >>> >> chapters are correct for your module. >> > Also, I would like >> > >> >>> >> everyone to >> > >> >>> >> take a moment to review the module >> > documentation guidelines, >> > >> >>> >> as there >> > >> >>> >> were a number of breakages in the bundled >> > documentation build >> > >> >>> >> because >> > >> >>> >> the guidelines weren't adhered to, >> > particularly in the new >> > >> >>> >> modules for >> > >> >>> >> Seam 3.1: >> > >> >>> >> >> > >> >>> >> 1) Always prefix the filenames of your >> > documentation chapters >> > >> >>> >> with the >> > >> >>> >> name of your module. E.g. >> > security-authentication.xml, >> > >> >>> >> security-authorization.xml, etc. >> > >> >>> >> >> > >> >>> >> 2) Whenever you assign an ID to a docbook >> > element, such as a >> > >> >>> >> >> > >> >>> >> or
, ALWAYS prefix the id with >> > your module name. For >> > >> >>> >> example, >> > >> >>> >> or >> >
> > >> >>> >> id="security-getting-started">. As all of >> > the chapters for >> > >> >>> >> all modules >> > >> >>> >> are combined when building the bundled >> > documentation, all IDs >> > >> >>> >> must be >> > >> >>> >> unique. This is a particularly time >> > consuming problem to fix >> > >> >>> >> because >> > >> >>> >> the error output from the Maven docbook >> > plugin doesn't tell >> > >> >>> >> you which >> > >> >>> >> files are the problem ones. >> > >> >>> >> >> > >> >>> >> 3) When adding, renaming or deleting a >> > chapter of your >> > >> >>> >> documentation, >> > >> >>> >> please notify me of the changes so that I >> > can update >> > >> >>> >> bundled_master.xml. This file must be >> > manually kept up to >> > >> >>> >> date whenever >> > >> >>> >> any documentation changes are made. >> > >> >>> >> >> > >> >>> >> Thanks, >> > >> >>> >> Shane >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> > > DocBook XML V4.5//EN" >> > >> >>> >> >> > "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ ]> >> > >> >>> >> > > xmlns:xi="http://www.w3.org/2001/XInclude"> >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> Seam 3 >> > >> >>> >> Bundled Reference >> > Guide >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> Forge >> > >> >>> >> >> > >> >>> >> > > href="forge-installation.xml" /> >> > >> >>> >> > > href="forge-creating-basic-webapp.xml" /> >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> Seam Solder >> > >> >>> >> >> > >> >>> >> > > href="solder-gettingstarted.xml"/> >> > >> >>> >> > > href="solder-programmingmodel.xml"/> >> > >> >>> >> > > href="solder-annotationliterals.xml"/> >> > >> >>> >> > > href="solder-elextensions.xml"/> >> > >> >>> >> > > href="solder-resourceloading.xml"/> >> > >> >>> >> >> > >> >>> >> > > href="solder-typeutilities.xml"/> >> > >> >>> >> > > href="solder-beanmanagerprovider.xml"/> >> > >> >>> >> > > href="solder-beanutilities.xml"/> >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> > > href="solder-defaultbeans.xml"/> >> > >> >>> >> > > href="solder-genericbeans.xml"/> >> > >> >>> >> > > href="solder-servicehandler.xml"/> >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> Seam Configuration >> > >> >>> >> > > href="config-introduction.xml"/> >> > >> >>> >> > > href="config-xml-provider.xml"/> >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> Seam Persistence >> > >> >>> >> > > href="persistence-general.xml"/> >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> Seam Transaction >> > >> >>> >> > > href="transaction-general.xml"/> >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> Seam Servlet >> > >> >>> >> > > href="servlet-introduction.xml"/> >> > >> >>> >> > > href="servlet-installation.xml"/> >> > >> >>> >> >> > >> >>> >> > > href="servlet-injectable_refs.xml"/> >> > >> >>> >> > > href="servlet-exception_handling.xml" /> >> > >> >>> >> > > href="servlet-beanmanager.xml"/> >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> Seam Security >> > >> >>> >> > > href="security-introduction.xml"/> >> > >> >>> >> > > href="security-authentication.xml"/> >> > >> >>> >> > > href="security-identitymanagement.xml"/> >> > >> >>> >> > > href="security-authentication-external.xml"/> >> > >> >>> >> > > href="security-authorization.xml"/> >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> Seam International >> > >> >>> >> > > href="international-preface.xml" /> >> > >> >>> >> > > href="international-installation.xml" /> >> > >> >>> >> > > href="international-locales.xml" /> >> > >> >>> >> > > href="international-timezones.xml" /> >> > >> >>> >> > > href="international-messages.xml" /> >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> Seam Faces >> > >> >>> >> >> > >> >>> >> > > href="faces-installation.xml" /> >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> Seam Catch >> > >> >>> >> > > href="catch-introduction.xml"/> >> > >> >>> >> > > href="catch-installation.xml"/> >> > >> >>> >> > > href="catch-client_usage.xml"/> >> > >> >>> >> > > href="catch-advanced_usage.xml"/> >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> Seam Reports >> > >> >>> >> >> > >> >>> >> > > href="reports-installation.xml" /> >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> Seam Remoting >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> > > href="remoting-validation.xml"/> >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> Seam REST >> > >> >>> >> >> > >> >>> >> > > href="rest-installation.xml" /> >> > >> >>> >> > > href="rest-exception-mapping.xml" /> >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> > > href="rest-dependencies.xml" /> >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> Seam JCR >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> Seam JMS >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> > > href="jms-resource-injection.xml" /> >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> > > href="jms-mapping-interfaces.xml" /> >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> Seam Validation >> > >> >>> >> > > href="validation-introduction.xml"/> >> > >> >>> >> > > href="validation-installation.xml"/> >> > >> >>> >> > > href="validation-dependency-injection.xml"/> >> > >> >>> >> > > href="validation-method-validation.xml"/> >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> Seam Wicket >> > >> >>> >> >> > >> >>> >> > > href="wicket-installation.xml" /> >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> >> > _______________________________________________ >> > >> >>> >> seam-dev mailing list >> > >> >>> >> seam-dev at lists.jboss.org >> > >> > >> > > > >> > >> >>> > > >> > >> > > >> >> > >> >>> >> >> > https://lists.jboss.org/mailman/listinfo/seam-dev >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> -- >> > >> >>> >> Lincoln Baxter, III >> > >> >>> >> http://ocpsoft.com >> > >> >>> >> http://scrumshark.com >> > >> >>> >> "Keep it Simple" >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> >> > >> >>> >> -- >> > >> >>> >> Lincoln Baxter, III >> > >> >>> >> http://ocpsoft.com >> > >> >>> >> http://scrumshark.com >> > >> >>> >> "Keep it Simple" >> > >> >>> > >> > >> >> >> > > >> > >> > >> > >> > >> > -- >> > Lincoln Baxter, III >> > http://ocpsoft.com >> > http://scrumshark.com >> > "Keep it Simple" >> >> >> >> >> >> -- >> Lincoln Baxter, III >> http://ocpsoft.com >> http://scrumshark.com >> "Keep it Simple" >> _______________________________________________ >> seam-dev mailing list >> seam-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/seam-dev From mnovotny at redhat.com Fri Sep 2 06:52:01 2011 From: mnovotny at redhat.com (Marek Novotny) Date: Fri, 02 Sep 2011 12:52:01 +0200 Subject: [seam-dev] Bundled distribution documentation In-Reply-To: <4E60B35A.1090504@redhat.com> References: <4E5DB50C.3030409@redhat.com> <4E5EA2EA.2000109@redhat.com> <4E6001BD.4070301@redhat.com> <4E601AA2.7090705@redhat.com> <4E6052DD.1090602@redhat.com> <1314956113.2908.9.camel@localhost.localdomain> <4E60B35A.1090504@redhat.com> Message-ID: <1314960721.2908.11.camel@localhost.localdomain> I guess, it could be done by scripting a Web service https://issues.jboss.org/browse/ORG-1123 On Fri, 2011-09-02 at 20:43 +1000, Shane Bryzak wrote: > This would need to be automated for the Seam distribution build though. > Currently, all modules have their docbook sources published as Maven > artifacts, which is what we use to construct the bundled documentation. > > On 02/09/11 19:35, Marek Novotny wrote: > > What about using feature "Export to docbook" and then just generate > > standard jdocbook output in release process? > > > > https://docs.jboss.org/author/display/AUTHGUIDE/Exporting+content+to > > +DocBook+XML > > > > On Fri, 2011-09-02 at 00:15 -0400, Lincoln Baxter, III wrote: > >> I don't know. I don't really have plans to include docbook in the dist > >> until we get some better integration there from the .ORG team. I don't > >> see that happening, though, so until then, online docs are the way > >> people will be learning about forge. Our tools don't make this easy. > >> > >> I don't think the connectivity issue will be a problem. People can > >> always print or download the site for later if they have connectivity > >> issues. It might be nice (on confluence) to be able to have a 1-click > >> download, though. > >> > >> ~Lincoln > >> > >> On Thu, Sep 1, 2011 at 11:51 PM, Shane Bryzak > >> wrote: > >> Yeah, that's a good idea. Do you have plans to provide > >> documentation as part of the Forge download? I'm thinking of > >> the users who might have no/limited connectivity who won't be > >> able to access the Forge docs online. Also, how does > >> confluence work in conjunction with our documentation team? > >> From my understanding all their tools for translating etc are > >> based on Publican/Docbook. > >> > >> > >> > >> On 02/09/11 13:48, Lincoln Baxter, III wrote: > >> > Actually, maybe the best thing to do is just to add a new > >> > section to the Seam umbrella doc, with an HTML link to the > >> > forge confluence space? > >> > > >> > On Thu, Sep 1, 2011 at 7:54 PM, Lincoln Baxter, III > >> > wrote: > >> > Ok. If you include beta1, the artifact for dist is: > >> > > >> > org.jboss.forge:forge-modules:1.0.0.Beta1 > >> > > >> > -- > >> > Lincoln Baxter's Droid > >> > http://ocpsoft.com > >> > "Keep it Simple" > >> > > >> > > >> > On Sep 1, 2011 7:52 PM, "Shane Bryzak" > >> > wrote: > >> > > Yep, I planned on extracting it in the forge > >> > folder. > >> > > > >> > > On 02/09/11 09:43, Lincoln Baxter, III wrote: > >> > >> > >> > >> Also, if forge is unzipped. It should be done so > >> > in its own subfolder. > >> > >> > >> > >> Ill try to catch you online tonight and make sure > >> > you've got the right > >> > >> artifact. (it moved temporarily during the jboss > >> > modules transition. > >> > >> > >> > >> -- > >> > >> Lincoln Baxter's Droid > >> > >> http://ocpsoft.com > >> > >> "Keep it Simple" > >> > >> > >> > >> On Sep 1, 2011 7:41 PM, "Lincoln Baxter, III" > >> > >> > > >> > >> > wrote: > >> > > >> > >> > Well. The forge distribution doesn't contain > >> > docs either. They are > >> > >> purely > >> > >> > online at this point. So I think just don't > >> > worry about it. This > >> > >> confluence > >> > >> > thing is a bit of a pain in that regard. > >> > >> > > >> > >> > -- > >> > >> > Lincoln Baxter's Droid > >> > >> > http://ocpsoft.com > >> > >> > "Keep it Simple" > >> > >> > On Sep 1, 2011 6:05 PM, "Shane Bryzak" > >> > >> > > >> > >> > wrote: > >> > >> >> Unless an export could be automated as part of > >> > the build process, I > >> > >> >> don't think that's a good idea. How about we > >> > just include the Forge > >> > >> >> distribution extracted inside the Seam > >> > distribution? The documentation > >> > >> >> won't be combined with the main Seam docs, but > >> > as long as it's in the > >> > >> >> Forge distribution then a user should be able > >> > to find it without too > >> > >> >> much effort. > >> > >> >> > >> > >> >> On 02/09/11 01:22, Lincoln Baxter, III wrote: > >> > >> >>> > >> > >> >>> I'm not really sure how to do this, then. > >> > There are no sources since > >> > >> >>> the docs are in confluence. > >> > >> >>> > >> > >> >>> I suppose an export could work? > >> > >> >>> > >> > >> >>> -- > >> > >> >>> Lincoln Baxter's Droid > >> > >> >>> http://ocpsoft.com > >> > >> >>> "Keep it Simple" > >> > >> >>> > >> > >> >>> On Aug 31, 2011 5:09 PM, "Shane Bryzak" > >> > >> > >> > >> > > >> > >> >>> >> > >> wrote: > >> > > >> > >> >>> > The source artifact for the Forge docs were > >> > being pulled in like > >> > >> this: > >> > >> >>> > > >> > >> >>> > > >> > >> >>> > org.jboss.seam.forge > >> > >> >>> > > >> > forge-reference-guide > >> > >> >>> > 1.0.0-SNAPSHOT > >> > >> >>> > sources > >> > >> >>> > jar > >> > >> >>> > > >> > >> >>> > > >> > >> >>> > When I update the version to 1.0.0.Beta1, > >> > it can't find the source - > >> > >> >>> was > >> > >> >>> > the Beta1 source artifact published to > >> > Maven? > >> > >> >>> > > >> > >> >>> > > >> > >> >>> > > >> > >> >>> > On 01/09/11 03:02, Lincoln Baxter, III > >> > wrote: > >> > >> >>> >> > >> > https://docs.jboss.org/author/display/SEAMFORGE/Home > >> > >> >>> >> > >> > >> >>> >> On Wed, Aug 31, 2011 at 1:02 PM, Lincoln > >> > Baxter, III > >> > >> >>> >> >> > > >> > >> >> > > > >> > >> >>> >> > > >> > >> >> > >>> wrote: > >> > >> >>> >> > >> > >> >>> >> Just checking - the Forge docs are no > >> > longer in SVN / are in > >> > >> >>> >> Confluence; have you taken this into > >> > account? > >> > >> >>> >> > >> > >> >>> >> Also, the which distribution are you > >> > including? You could choose > >> > >> >>> >> either Beta1 or the latest SNAPSHOT (which > >> > is actually in a new > >> > >> >>> >> location - moved back to the original > >> > >> >>> >> org.jboss.forge:forge-distribution - > >> > though it looks like the > >> > >> >>> >> build hasn't deployed artifacts in a > >> > little while - looking in to > >> > >> >>> >> that) > >> > >> >>> >> > >> > >> >>> >> ~Lincoln > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> On Wed, Aug 31, 2011 at 12:14 AM, Shane > >> > Bryzak > >> > >> > >> > >> >>> >> > > > >> > >> >>> >> >> > > >> > >> >> > >>> wrote: > >> > >> >>> >> > >> > >> >>> >> Module leads, > >> > >> >>> >> > >> > >> >>> >> Can you please review the list below and > >> > confirm that the > >> > >> >>> >> documentation > >> > >> >>> >> chapters are correct for your module. > >> > Also, I would like > >> > >> >>> >> everyone to > >> > >> >>> >> take a moment to review the module > >> > documentation guidelines, > >> > >> >>> >> as there > >> > >> >>> >> were a number of breakages in the bundled > >> > documentation build > >> > >> >>> >> because > >> > >> >>> >> the guidelines weren't adhered to, > >> > particularly in the new > >> > >> >>> >> modules for > >> > >> >>> >> Seam 3.1: > >> > >> >>> >> > >> > >> >>> >> 1) Always prefix the filenames of your > >> > documentation chapters > >> > >> >>> >> with the > >> > >> >>> >> name of your module. E.g. > >> > security-authentication.xml, > >> > >> >>> >> security-authorization.xml, etc. > >> > >> >>> >> > >> > >> >>> >> 2) Whenever you assign an ID to a docbook > >> > element, such as a > >> > >> >>> >> > >> > >> >>> >> or
, ALWAYS prefix the id with > >> > your module name. For > >> > >> >>> >> example, > >> > >> >>> >> or > >> >
>> > >> >>> >> id="security-getting-started">. As all of > >> > the chapters for > >> > >> >>> >> all modules > >> > >> >>> >> are combined when building the bundled > >> > documentation, all IDs > >> > >> >>> >> must be > >> > >> >>> >> unique. This is a particularly time > >> > consuming problem to fix > >> > >> >>> >> because > >> > >> >>> >> the error output from the Maven docbook > >> > plugin doesn't tell > >> > >> >>> >> you which > >> > >> >>> >> files are the problem ones. > >> > >> >>> >> > >> > >> >>> >> 3) When adding, renaming or deleting a > >> > chapter of your > >> > >> >>> >> documentation, > >> > >> >>> >> please notify me of the changes so that I > >> > can update > >> > >> >>> >> bundled_master.xml. This file must be > >> > manually kept up to > >> > >> >>> >> date whenever > >> > >> >>> >> any documentation changes are made. > >> > >> >>> >> > >> > >> >>> >> Thanks, > >> > >> >>> >> Shane > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> >> > DocBook XML V4.5//EN" > >> > >> >>> >> > >> > "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ ]> > >> > >> >>> >> >> > xmlns:xi="http://www.w3.org/2001/XInclude"> > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> Seam 3 > >> > >> >>> >> Bundled Reference > >> > Guide > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> Forge > >> > >> >>> >> > >> > >> >>> >> >> > href="forge-installation.xml" /> > >> > >> >>> >> >> > href="forge-creating-basic-webapp.xml" /> > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> Seam Solder > >> > >> >>> >> > >> > >> >>> >> >> > href="solder-gettingstarted.xml"/> > >> > >> >>> >> >> > href="solder-programmingmodel.xml"/> > >> > >> >>> >> >> > href="solder-annotationliterals.xml"/> > >> > >> >>> >> >> > href="solder-elextensions.xml"/> > >> > >> >>> >> >> > href="solder-resourceloading.xml"/> > >> > >> >>> >> > >> > >> >>> >> >> > href="solder-typeutilities.xml"/> > >> > >> >>> >> >> > href="solder-beanmanagerprovider.xml"/> > >> > >> >>> >> >> > href="solder-beanutilities.xml"/> > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> >> > href="solder-defaultbeans.xml"/> > >> > >> >>> >> >> > href="solder-genericbeans.xml"/> > >> > >> >>> >> >> > href="solder-servicehandler.xml"/> > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> Seam Configuration > >> > >> >>> >> >> > href="config-introduction.xml"/> > >> > >> >>> >> >> > href="config-xml-provider.xml"/> > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> Seam Persistence > >> > >> >>> >> >> > href="persistence-general.xml"/> > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> Seam Transaction > >> > >> >>> >> >> > href="transaction-general.xml"/> > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> Seam Servlet > >> > >> >>> >> >> > href="servlet-introduction.xml"/> > >> > >> >>> >> >> > href="servlet-installation.xml"/> > >> > >> >>> >> > >> > >> >>> >> >> > href="servlet-injectable_refs.xml"/> > >> > >> >>> >> >> > href="servlet-exception_handling.xml" /> > >> > >> >>> >> >> > href="servlet-beanmanager.xml"/> > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> Seam Security > >> > >> >>> >> >> > href="security-introduction.xml"/> > >> > >> >>> >> >> > href="security-authentication.xml"/> > >> > >> >>> >> >> > href="security-identitymanagement.xml"/> > >> > >> >>> >> >> > href="security-authentication-external.xml"/> > >> > >> >>> >> >> > href="security-authorization.xml"/> > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> Seam International > >> > >> >>> >> >> > href="international-preface.xml" /> > >> > >> >>> >> >> > href="international-installation.xml" /> > >> > >> >>> >> >> > href="international-locales.xml" /> > >> > >> >>> >> >> > href="international-timezones.xml" /> > >> > >> >>> >> >> > href="international-messages.xml" /> > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> Seam Faces > >> > >> >>> >> > >> > >> >>> >> >> > href="faces-installation.xml" /> > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> Seam Catch > >> > >> >>> >> >> > href="catch-introduction.xml"/> > >> > >> >>> >> >> > href="catch-installation.xml"/> > >> > >> >>> >> >> > href="catch-client_usage.xml"/> > >> > >> >>> >> >> > href="catch-advanced_usage.xml"/> > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> Seam Reports > >> > >> >>> >> > >> > >> >>> >> >> > href="reports-installation.xml" /> > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> Seam Remoting > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> >> > href="remoting-validation.xml"/> > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> Seam REST > >> > >> >>> >> > >> > >> >>> >> >> > href="rest-installation.xml" /> > >> > >> >>> >> >> > href="rest-exception-mapping.xml" /> > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> >> > href="rest-dependencies.xml" /> > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> Seam JCR > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> Seam JMS > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> >> > href="jms-resource-injection.xml" /> > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> >> > href="jms-mapping-interfaces.xml" /> > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> Seam Validation > >> > >> >>> >> >> > href="validation-introduction.xml"/> > >> > >> >>> >> >> > href="validation-installation.xml"/> > >> > >> >>> >> >> > href="validation-dependency-injection.xml"/> > >> > >> >>> >> >> > href="validation-method-validation.xml"/> > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> Seam Wicket > >> > >> >>> >> > >> > >> >>> >> >> > href="wicket-installation.xml" /> > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> > >> > _______________________________________________ > >> > >> >>> >> seam-dev mailing list > >> > >> >>> >> seam-dev at lists.jboss.org > >> > > >> > >> >> > > > >> > >> >>> >> > > >> > >> >> > >> > >> > >> >>> >> > >> > https://lists.jboss.org/mailman/listinfo/seam-dev > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> -- > >> > >> >>> >> Lincoln Baxter, III > >> > >> >>> >> http://ocpsoft.com > >> > >> >>> >> http://scrumshark.com > >> > >> >>> >> "Keep it Simple" > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> -- > >> > >> >>> >> Lincoln Baxter, III > >> > >> >>> >> http://ocpsoft.com > >> > >> >>> >> http://scrumshark.com > >> > >> >>> >> "Keep it Simple" > >> > >> >>> > > >> > >> >> > >> > > > >> > > >> > > >> > > >> > > >> > -- > >> > Lincoln Baxter, III > >> > http://ocpsoft.com > >> > http://scrumshark.com > >> > "Keep it Simple" > >> > >> > >> > >> > >> > >> -- > >> Lincoln Baxter, III > >> http://ocpsoft.com > >> http://scrumshark.com > >> "Keep it Simple" > >> _______________________________________________ > >> seam-dev mailing list > >> seam-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/seam-dev > -- Marek Novotny -- Seam and WFK Product Lead Red Hat Czech s.r.o. Purkynova 99 612 45 Brno Email: mnovotny at redhat.com Office phone: +420 532 294 287, ext. 82-62 087 mobile: +420 608 509 230 From sbryzak at redhat.com Fri Sep 2 06:57:42 2011 From: sbryzak at redhat.com (Shane Bryzak) Date: Fri, 02 Sep 2011 20:57:42 +1000 Subject: [seam-dev] Bundled distribution documentation In-Reply-To: <1314960721.2908.11.camel@localhost.localdomain> References: <4E5DB50C.3030409@redhat.com> <4E5EA2EA.2000109@redhat.com> <4E6001BD.4070301@redhat.com> <4E601AA2.7090705@redhat.com> <4E6052DD.1090602@redhat.com> <1314956113.2908.9.camel@localhost.localdomain> <4E60B35A.1090504@redhat.com> <1314960721.2908.11.camel@localhost.localdomain> Message-ID: <4E60B6A6.6040604@redhat.com> That might work, but I wonder how long it would take to actually generate the sources during the method call... for substantial documentation I can imagine this might take quite a while. Also, how do image resources work in this case? The challenge is, that we need to be able to automate the Seam distribution build from Jenkins. On 02/09/11 20:52, Marek Novotny wrote: > I guess, it could be done by scripting a Web service > https://issues.jboss.org/browse/ORG-1123 > > > > On Fri, 2011-09-02 at 20:43 +1000, Shane Bryzak wrote: >> This would need to be automated for the Seam distribution build though. >> Currently, all modules have their docbook sources published as Maven >> artifacts, which is what we use to construct the bundled documentation. >> >> On 02/09/11 19:35, Marek Novotny wrote: >>> What about using feature "Export to docbook" and then just generate >>> standard jdocbook output in release process? >>> >>> https://docs.jboss.org/author/display/AUTHGUIDE/Exporting+content+to >>> +DocBook+XML >>> >>> On Fri, 2011-09-02 at 00:15 -0400, Lincoln Baxter, III wrote: >>>> I don't know. I don't really have plans to include docbook in the dist >>>> until we get some better integration there from the .ORG team. I don't >>>> see that happening, though, so until then, online docs are the way >>>> people will be learning about forge. Our tools don't make this easy. >>>> >>>> I don't think the connectivity issue will be a problem. People can >>>> always print or download the site for later if they have connectivity >>>> issues. It might be nice (on confluence) to be able to have a 1-click >>>> download, though. >>>> >>>> ~Lincoln >>>> >>>> On Thu, Sep 1, 2011 at 11:51 PM, Shane Bryzak >>>> wrote: >>>> Yeah, that's a good idea. Do you have plans to provide >>>> documentation as part of the Forge download? I'm thinking of >>>> the users who might have no/limited connectivity who won't be >>>> able to access the Forge docs online. Also, how does >>>> confluence work in conjunction with our documentation team? >>>> From my understanding all their tools for translating etc are >>>> based on Publican/Docbook. >>>> >>>> >>>> >>>> On 02/09/11 13:48, Lincoln Baxter, III wrote: >>>> > Actually, maybe the best thing to do is just to add a new >>>> > section to the Seam umbrella doc, with an HTML link to the >>>> > forge confluence space? >>>> > >>>> > On Thu, Sep 1, 2011 at 7:54 PM, Lincoln Baxter, III >>>> > wrote: >>>> > Ok. If you include beta1, the artifact for dist is: >>>> > >>>> > org.jboss.forge:forge-modules:1.0.0.Beta1 >>>> > >>>> > -- >>>> > Lincoln Baxter's Droid >>>> > http://ocpsoft.com >>>> > "Keep it Simple" >>>> > >>>> > >>>> > On Sep 1, 2011 7:52 PM, "Shane Bryzak" >>>> > wrote: >>>> > > Yep, I planned on extracting it in the forge >>>> > folder. >>>> > > >>>> > > On 02/09/11 09:43, Lincoln Baxter, III wrote: >>>> > >> >>>> > >> Also, if forge is unzipped. It should be done so >>>> > in its own subfolder. >>>> > >> >>>> > >> Ill try to catch you online tonight and make sure >>>> > you've got the right >>>> > >> artifact. (it moved temporarily during the jboss >>>> > modules transition. >>>> > >> >>>> > >> -- >>>> > >> Lincoln Baxter's Droid >>>> > >> http://ocpsoft.com >>>> > >> "Keep it Simple" >>>> > >> >>>> > >> On Sep 1, 2011 7:41 PM, "Lincoln Baxter, III" >>>> > >>> > >>>> > >> > wrote: >>>> > >>>> > >> > Well. The forge distribution doesn't contain >>>> > docs either. They are >>>> > >> purely >>>> > >> > online at this point. So I think just don't >>>> > worry about it. This >>>> > >> confluence >>>> > >> > thing is a bit of a pain in that regard. >>>> > >> > >>>> > >> > -- >>>> > >> > Lincoln Baxter's Droid >>>> > >> > http://ocpsoft.com >>>> > >> > "Keep it Simple" >>>> > >> > On Sep 1, 2011 6:05 PM, "Shane Bryzak" >>>> > >>> > >>>> > >> > wrote: >>>> > >> >> Unless an export could be automated as part of >>>> > the build process, I >>>> > >> >> don't think that's a good idea. How about we >>>> > just include the Forge >>>> > >> >> distribution extracted inside the Seam >>>> > distribution? The documentation >>>> > >> >> won't be combined with the main Seam docs, but >>>> > as long as it's in the >>>> > >> >> Forge distribution then a user should be able >>>> > to find it without too >>>> > >> >> much effort. >>>> > >> >> >>>> > >> >> On 02/09/11 01:22, Lincoln Baxter, III wrote: >>>> > >> >>> >>>> > >> >>> I'm not really sure how to do this, then. >>>> > There are no sources since >>>> > >> >>> the docs are in confluence. >>>> > >> >>> >>>> > >> >>> I suppose an export could work? >>>> > >> >>> >>>> > >> >>> -- >>>> > >> >>> Lincoln Baxter's Droid >>>> > >> >>> http://ocpsoft.com >>>> > >> >>> "Keep it Simple" >>>> > >> >>> >>>> > >> >>> On Aug 31, 2011 5:09 PM, "Shane Bryzak" >>>> > >>> > >> >>>> > >>>> > >> >>> >>> > >> wrote: >>>> > >>>> > >> >>> > The source artifact for the Forge docs were >>>> > being pulled in like >>>> > >> this: >>>> > >> >>> > >>>> > >> >>> > >>>> > >> >>> > org.jboss.seam.forge >>>> > >> >>> > >>>> > forge-reference-guide >>>> > >> >>> > 1.0.0-SNAPSHOT >>>> > >> >>> > sources >>>> > >> >>> > jar >>>> > >> >>> > >>>> > >> >>> > >>>> > >> >>> > When I update the version to 1.0.0.Beta1, >>>> > it can't find the source - >>>> > >> >>> was >>>> > >> >>> > the Beta1 source artifact published to >>>> > Maven? >>>> > >> >>> > >>>> > >> >>> > >>>> > >> >>> > >>>> > >> >>> > On 01/09/11 03:02, Lincoln Baxter, III >>>> > wrote: >>>> > >> >>> >> >>>> > https://docs.jboss.org/author/display/SEAMFORGE/Home >>>> > >> >>> >> >>>> > >> >>> >> On Wed, Aug 31, 2011 at 1:02 PM, Lincoln >>>> > Baxter, III >>>> > >> >>> >> >>> > >>>> > >> >>> > > >>>> > >> >>> >>> > >>>> > >> >>> > >>> wrote: >>>> > >> >>> >> >>>> > >> >>> >> Just checking - the Forge docs are no >>>> > longer in SVN / are in >>>> > >> >>> >> Confluence; have you taken this into >>>> > account? >>>> > >> >>> >> >>>> > >> >>> >> Also, the which distribution are you >>>> > including? You could choose >>>> > >> >>> >> either Beta1 or the latest SNAPSHOT (which >>>> > is actually in a new >>>> > >> >>> >> location - moved back to the original >>>> > >> >>> >> org.jboss.forge:forge-distribution - >>>> > though it looks like the >>>> > >> >>> >> build hasn't deployed artifacts in a >>>> > little while - looking in to >>>> > >> >>> >> that) >>>> > >> >>> >> >>>> > >> >>> >> ~Lincoln >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> On Wed, Aug 31, 2011 at 12:14 AM, Shane >>>> > Bryzak >>>> > >> >>>> > >> >>> >>> > > >>>> > >> >>> >> >>> > >>>> > >> >>> > >>> wrote: >>>> > >> >>> >> >>>> > >> >>> >> Module leads, >>>> > >> >>> >> >>>> > >> >>> >> Can you please review the list below and >>>> > confirm that the >>>> > >> >>> >> documentation >>>> > >> >>> >> chapters are correct for your module. >>>> > Also, I would like >>>> > >> >>> >> everyone to >>>> > >> >>> >> take a moment to review the module >>>> > documentation guidelines, >>>> > >> >>> >> as there >>>> > >> >>> >> were a number of breakages in the bundled >>>> > documentation build >>>> > >> >>> >> because >>>> > >> >>> >> the guidelines weren't adhered to, >>>> > particularly in the new >>>> > >> >>> >> modules for >>>> > >> >>> >> Seam 3.1: >>>> > >> >>> >> >>>> > >> >>> >> 1) Always prefix the filenames of your >>>> > documentation chapters >>>> > >> >>> >> with the >>>> > >> >>> >> name of your module. E.g. >>>> > security-authentication.xml, >>>> > >> >>> >> security-authorization.xml, etc. >>>> > >> >>> >> >>>> > >> >>> >> 2) Whenever you assign an ID to a docbook >>>> > element, such as a >>>> > >> >>> >> >>>> > >> >>> >> or
, ALWAYS prefix the id with >>>> > your module name. For >>>> > >> >>> >> example, >>>> > >> >>> >> or >>>> >
>>> > >> >>> >> id="security-getting-started">. As all of >>>> > the chapters for >>>> > >> >>> >> all modules >>>> > >> >>> >> are combined when building the bundled >>>> > documentation, all IDs >>>> > >> >>> >> must be >>>> > >> >>> >> unique. This is a particularly time >>>> > consuming problem to fix >>>> > >> >>> >> because >>>> > >> >>> >> the error output from the Maven docbook >>>> > plugin doesn't tell >>>> > >> >>> >> you which >>>> > >> >>> >> files are the problem ones. >>>> > >> >>> >> >>>> > >> >>> >> 3) When adding, renaming or deleting a >>>> > chapter of your >>>> > >> >>> >> documentation, >>>> > >> >>> >> please notify me of the changes so that I >>>> > can update >>>> > >> >>> >> bundled_master.xml. This file must be >>>> > manually kept up to >>>> > >> >>> >> date whenever >>>> > >> >>> >> any documentation changes are made. >>>> > >> >>> >> >>>> > >> >>> >> Thanks, >>>> > >> >>> >> Shane >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> >>> > DocBook XML V4.5//EN" >>>> > >> >>> >> >>>> > "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ ]> >>>> > >> >>> >> >>> > xmlns:xi="http://www.w3.org/2001/XInclude"> >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> Seam 3 >>>> > >> >>> >> Bundled Reference >>>> > Guide >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> Forge >>>> > >> >>> >> >>>> > >> >>> >> >>> > href="forge-installation.xml" /> >>>> > >> >>> >> >>> > href="forge-creating-basic-webapp.xml" /> >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> Seam Solder >>>> > >> >>> >> >>>> > >> >>> >> >>> > href="solder-gettingstarted.xml"/> >>>> > >> >>> >> >>> > href="solder-programmingmodel.xml"/> >>>> > >> >>> >> >>> > href="solder-annotationliterals.xml"/> >>>> > >> >>> >> >>> > href="solder-elextensions.xml"/> >>>> > >> >>> >> >>> > href="solder-resourceloading.xml"/> >>>> > >> >>> >> >>>> > >> >>> >> >>> > href="solder-typeutilities.xml"/> >>>> > >> >>> >> >>> > href="solder-beanmanagerprovider.xml"/> >>>> > >> >>> >> >>> > href="solder-beanutilities.xml"/> >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> >>> > href="solder-defaultbeans.xml"/> >>>> > >> >>> >> >>> > href="solder-genericbeans.xml"/> >>>> > >> >>> >> >>> > href="solder-servicehandler.xml"/> >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> Seam Configuration >>>> > >> >>> >> >>> > href="config-introduction.xml"/> >>>> > >> >>> >> >>> > href="config-xml-provider.xml"/> >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> Seam Persistence >>>> > >> >>> >> >>> > href="persistence-general.xml"/> >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> Seam Transaction >>>> > >> >>> >> >>> > href="transaction-general.xml"/> >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> Seam Servlet >>>> > >> >>> >> >>> > href="servlet-introduction.xml"/> >>>> > >> >>> >> >>> > href="servlet-installation.xml"/> >>>> > >> >>> >> >>>> > >> >>> >> >>> > href="servlet-injectable_refs.xml"/> >>>> > >> >>> >> >>> > href="servlet-exception_handling.xml" /> >>>> > >> >>> >> >>> > href="servlet-beanmanager.xml"/> >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> Seam Security >>>> > >> >>> >> >>> > href="security-introduction.xml"/> >>>> > >> >>> >> >>> > href="security-authentication.xml"/> >>>> > >> >>> >> >>> > href="security-identitymanagement.xml"/> >>>> > >> >>> >> >>> > href="security-authentication-external.xml"/> >>>> > >> >>> >> >>> > href="security-authorization.xml"/> >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> Seam International >>>> > >> >>> >> >>> > href="international-preface.xml" /> >>>> > >> >>> >> >>> > href="international-installation.xml" /> >>>> > >> >>> >> >>> > href="international-locales.xml" /> >>>> > >> >>> >> >>> > href="international-timezones.xml" /> >>>> > >> >>> >> >>> > href="international-messages.xml" /> >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> Seam Faces >>>> > >> >>> >> >>>> > >> >>> >> >>> > href="faces-installation.xml" /> >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> Seam Catch >>>> > >> >>> >> >>> > href="catch-introduction.xml"/> >>>> > >> >>> >> >>> > href="catch-installation.xml"/> >>>> > >> >>> >> >>> > href="catch-client_usage.xml"/> >>>> > >> >>> >> >>> > href="catch-advanced_usage.xml"/> >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> Seam Reports >>>> > >> >>> >> >>>> > >> >>> >> >>> > href="reports-installation.xml" /> >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> Seam Remoting >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> >>> > href="remoting-validation.xml"/> >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> Seam REST >>>> > >> >>> >> >>>> > >> >>> >> >>> > href="rest-installation.xml" /> >>>> > >> >>> >> >>> > href="rest-exception-mapping.xml" /> >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> >>> > href="rest-dependencies.xml" /> >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> Seam JCR >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> Seam JMS >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> >>> > href="jms-resource-injection.xml" /> >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> >>> > href="jms-mapping-interfaces.xml" /> >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> Seam Validation >>>> > >> >>> >> >>> > href="validation-introduction.xml"/> >>>> > >> >>> >> >>> > href="validation-installation.xml"/> >>>> > >> >>> >> >>> > href="validation-dependency-injection.xml"/> >>>> > >> >>> >> >>> > href="validation-method-validation.xml"/> >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> Seam Wicket >>>> > >> >>> >> >>>> > >> >>> >> >>> > href="wicket-installation.xml" /> >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> >>>> > _______________________________________________ >>>> > >> >>> >> seam-dev mailing list >>>> > >> >>> >> seam-dev at lists.jboss.org >>>> > >>>> > >> >>> > > >>>> > >> >>> >>> > >>>> > >> >>> > >> >>>> > >> >>> >> >>>> > https://lists.jboss.org/mailman/listinfo/seam-dev >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> -- >>>> > >> >>> >> Lincoln Baxter, III >>>> > >> >>> >> http://ocpsoft.com >>>> > >> >>> >> http://scrumshark.com >>>> > >> >>> >> "Keep it Simple" >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> -- >>>> > >> >>> >> Lincoln Baxter, III >>>> > >> >>> >> http://ocpsoft.com >>>> > >> >>> >> http://scrumshark.com >>>> > >> >>> >> "Keep it Simple" >>>> > >> >>> > >>>> > >> >> >>>> > > >>>> > >>>> > >>>> > >>>> > >>>> > -- >>>> > Lincoln Baxter, III >>>> > http://ocpsoft.com >>>> > http://scrumshark.com >>>> > "Keep it Simple" >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Lincoln Baxter, III >>>> http://ocpsoft.com >>>> http://scrumshark.com >>>> "Keep it Simple" >>>> _______________________________________________ >>>> seam-dev mailing list >>>> seam-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/seam-dev From mnovotny at redhat.com Fri Sep 2 07:05:08 2011 From: mnovotny at redhat.com (Marek Novotny) Date: Fri, 02 Sep 2011 13:05:08 +0200 Subject: [seam-dev] Bundled distribution documentation In-Reply-To: <4E60B6A6.6040604@redhat.com> References: <4E5DB50C.3030409@redhat.com> <4E5EA2EA.2000109@redhat.com> <4E6001BD.4070301@redhat.com> <4E601AA2.7090705@redhat.com> <4E6052DD.1090602@redhat.com> <1314956113.2908.9.camel@localhost.localdomain> <4E60B35A.1090504@redhat.com> <1314960721.2908.11.camel@localhost.localdomain> <4E60B6A6.6040604@redhat.com> Message-ID: <1314961508.2908.15.camel@localhost.localdomain> I don't know, I only read the announce email from jboss.org team about it. I guess you need to ping the author of the feature - velias on IRC #jboss.org On Fri, 2011-09-02 at 20:57 +1000, Shane Bryzak wrote: > That might work, but I wonder how long it would take to actually > generate the sources during the method call... for substantial > documentation I can imagine this might take quite a while. Also, how do > image resources work in this case? The challenge is, that we need to be > able to automate the Seam distribution build from Jenkins. > > > > On 02/09/11 20:52, Marek Novotny wrote: > > I guess, it could be done by scripting a Web service > > https://issues.jboss.org/browse/ORG-1123 > > > > > > > > On Fri, 2011-09-02 at 20:43 +1000, Shane Bryzak wrote: > >> This would need to be automated for the Seam distribution build though. > >> Currently, all modules have their docbook sources published as Maven > >> artifacts, which is what we use to construct the bundled documentation. > >> > >> On 02/09/11 19:35, Marek Novotny wrote: > >>> What about using feature "Export to docbook" and then just generate > >>> standard jdocbook output in release process? > >>> > >>> https://docs.jboss.org/author/display/AUTHGUIDE/Exporting+content+to > >>> +DocBook+XML > >>> > >>> On Fri, 2011-09-02 at 00:15 -0400, Lincoln Baxter, III wrote: > >>>> I don't know. I don't really have plans to include docbook in the dist > >>>> until we get some better integration there from the .ORG team. I don't > >>>> see that happening, though, so until then, online docs are the way > >>>> people will be learning about forge. Our tools don't make this easy. > >>>> > >>>> I don't think the connectivity issue will be a problem. People can > >>>> always print or download the site for later if they have connectivity > >>>> issues. It might be nice (on confluence) to be able to have a 1-click > >>>> download, though. > >>>> > >>>> ~Lincoln > >>>> > >>>> On Thu, Sep 1, 2011 at 11:51 PM, Shane Bryzak > >>>> wrote: > >>>> Yeah, that's a good idea. Do you have plans to provide > >>>> documentation as part of the Forge download? I'm thinking of > >>>> the users who might have no/limited connectivity who won't be > >>>> able to access the Forge docs online. Also, how does > >>>> confluence work in conjunction with our documentation team? > >>>> From my understanding all their tools for translating etc are > >>>> based on Publican/Docbook. > >>>> > >>>> > >>>> > >>>> On 02/09/11 13:48, Lincoln Baxter, III wrote: > >>>> > Actually, maybe the best thing to do is just to add a new > >>>> > section to the Seam umbrella doc, with an HTML link to the > >>>> > forge confluence space? > >>>> > > >>>> > On Thu, Sep 1, 2011 at 7:54 PM, Lincoln Baxter, III > >>>> > wrote: > >>>> > Ok. If you include beta1, the artifact for dist is: > >>>> > > >>>> > org.jboss.forge:forge-modules:1.0.0.Beta1 > >>>> > > >>>> > -- > >>>> > Lincoln Baxter's Droid > >>>> > http://ocpsoft.com > >>>> > "Keep it Simple" > >>>> > > >>>> > > >>>> > On Sep 1, 2011 7:52 PM, "Shane Bryzak" > >>>> > wrote: > >>>> > > Yep, I planned on extracting it in the forge > >>>> > folder. > >>>> > > > >>>> > > On 02/09/11 09:43, Lincoln Baxter, III wrote: > >>>> > >> > >>>> > >> Also, if forge is unzipped. It should be done so > >>>> > in its own subfolder. > >>>> > >> > >>>> > >> Ill try to catch you online tonight and make sure > >>>> > you've got the right > >>>> > >> artifact. (it moved temporarily during the jboss > >>>> > modules transition. > >>>> > >> > >>>> > >> -- > >>>> > >> Lincoln Baxter's Droid > >>>> > >> http://ocpsoft.com > >>>> > >> "Keep it Simple" > >>>> > >> > >>>> > >> On Sep 1, 2011 7:41 PM, "Lincoln Baxter, III" > >>>> > >>>> > > >>>> > >> > wrote: > >>>> > > >>>> > >> > Well. The forge distribution doesn't contain > >>>> > docs either. They are > >>>> > >> purely > >>>> > >> > online at this point. So I think just don't > >>>> > worry about it. This > >>>> > >> confluence > >>>> > >> > thing is a bit of a pain in that regard. > >>>> > >> > > >>>> > >> > -- > >>>> > >> > Lincoln Baxter's Droid > >>>> > >> > http://ocpsoft.com > >>>> > >> > "Keep it Simple" > >>>> > >> > On Sep 1, 2011 6:05 PM, "Shane Bryzak" > >>>> > >>>> > > >>>> > >> > wrote: > >>>> > >> >> Unless an export could be automated as part of > >>>> > the build process, I > >>>> > >> >> don't think that's a good idea. How about we > >>>> > just include the Forge > >>>> > >> >> distribution extracted inside the Seam > >>>> > distribution? The documentation > >>>> > >> >> won't be combined with the main Seam docs, but > >>>> > as long as it's in the > >>>> > >> >> Forge distribution then a user should be able > >>>> > to find it without too > >>>> > >> >> much effort. > >>>> > >> >> > >>>> > >> >> On 02/09/11 01:22, Lincoln Baxter, III wrote: > >>>> > >> >>> > >>>> > >> >>> I'm not really sure how to do this, then. > >>>> > There are no sources since > >>>> > >> >>> the docs are in confluence. > >>>> > >> >>> > >>>> > >> >>> I suppose an export could work? > >>>> > >> >>> > >>>> > >> >>> -- > >>>> > >> >>> Lincoln Baxter's Droid > >>>> > >> >>> http://ocpsoft.com > >>>> > >> >>> "Keep it Simple" > >>>> > >> >>> > >>>> > >> >>> On Aug 31, 2011 5:09 PM, "Shane Bryzak" > >>>> > >>>> > >> > >>>> > > >>>> > >> >>> >>>> > >> wrote: > >>>> > > >>>> > >> >>> > The source artifact for the Forge docs were > >>>> > being pulled in like > >>>> > >> this: > >>>> > >> >>> > > >>>> > >> >>> > > >>>> > >> >>> > org.jboss.seam.forge > >>>> > >> >>> > > >>>> > forge-reference-guide > >>>> > >> >>> > 1.0.0-SNAPSHOT > >>>> > >> >>> > sources > >>>> > >> >>> > jar > >>>> > >> >>> > > >>>> > >> >>> > > >>>> > >> >>> > When I update the version to 1.0.0.Beta1, > >>>> > it can't find the source - > >>>> > >> >>> was > >>>> > >> >>> > the Beta1 source artifact published to > >>>> > Maven? > >>>> > >> >>> > > >>>> > >> >>> > > >>>> > >> >>> > > >>>> > >> >>> > On 01/09/11 03:02, Lincoln Baxter, III > >>>> > wrote: > >>>> > >> >>> >> > >>>> > https://docs.jboss.org/author/display/SEAMFORGE/Home > >>>> > >> >>> >> > >>>> > >> >>> >> On Wed, Aug 31, 2011 at 1:02 PM, Lincoln > >>>> > Baxter, III > >>>> > >> >>> >> >>>> > > >>>> > >> >>>> > > > >>>> > >> >>> >>>> > > >>>> > >> >>>> > >>> wrote: > >>>> > >> >>> >> > >>>> > >> >>> >> Just checking - the Forge docs are no > >>>> > longer in SVN / are in > >>>> > >> >>> >> Confluence; have you taken this into > >>>> > account? > >>>> > >> >>> >> > >>>> > >> >>> >> Also, the which distribution are you > >>>> > including? You could choose > >>>> > >> >>> >> either Beta1 or the latest SNAPSHOT (which > >>>> > is actually in a new > >>>> > >> >>> >> location - moved back to the original > >>>> > >> >>> >> org.jboss.forge:forge-distribution - > >>>> > though it looks like the > >>>> > >> >>> >> build hasn't deployed artifacts in a > >>>> > little while - looking in to > >>>> > >> >>> >> that) > >>>> > >> >>> >> > >>>> > >> >>> >> ~Lincoln > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> On Wed, Aug 31, 2011 at 12:14 AM, Shane > >>>> > Bryzak > >>>> > >> > >>>> > >> >>> >>>> > > > >>>> > >> >>> >> >>>> > > >>>> > >> >>>> > >>> wrote: > >>>> > >> >>> >> > >>>> > >> >>> >> Module leads, > >>>> > >> >>> >> > >>>> > >> >>> >> Can you please review the list below and > >>>> > confirm that the > >>>> > >> >>> >> documentation > >>>> > >> >>> >> chapters are correct for your module. > >>>> > Also, I would like > >>>> > >> >>> >> everyone to > >>>> > >> >>> >> take a moment to review the module > >>>> > documentation guidelines, > >>>> > >> >>> >> as there > >>>> > >> >>> >> were a number of breakages in the bundled > >>>> > documentation build > >>>> > >> >>> >> because > >>>> > >> >>> >> the guidelines weren't adhered to, > >>>> > particularly in the new > >>>> > >> >>> >> modules for > >>>> > >> >>> >> Seam 3.1: > >>>> > >> >>> >> > >>>> > >> >>> >> 1) Always prefix the filenames of your > >>>> > documentation chapters > >>>> > >> >>> >> with the > >>>> > >> >>> >> name of your module. E.g. > >>>> > security-authentication.xml, > >>>> > >> >>> >> security-authorization.xml, etc. > >>>> > >> >>> >> > >>>> > >> >>> >> 2) Whenever you assign an ID to a docbook > >>>> > element, such as a > >>>> > >> >>> >> > >>>> > >> >>> >> or
, ALWAYS prefix the id with > >>>> > your module name. For > >>>> > >> >>> >> example, > >>>> > >> >>> >> or > >>>> >
>>>> > >> >>> >> id="security-getting-started">. As all of > >>>> > the chapters for > >>>> > >> >>> >> all modules > >>>> > >> >>> >> are combined when building the bundled > >>>> > documentation, all IDs > >>>> > >> >>> >> must be > >>>> > >> >>> >> unique. This is a particularly time > >>>> > consuming problem to fix > >>>> > >> >>> >> because > >>>> > >> >>> >> the error output from the Maven docbook > >>>> > plugin doesn't tell > >>>> > >> >>> >> you which > >>>> > >> >>> >> files are the problem ones. > >>>> > >> >>> >> > >>>> > >> >>> >> 3) When adding, renaming or deleting a > >>>> > chapter of your > >>>> > >> >>> >> documentation, > >>>> > >> >>> >> please notify me of the changes so that I > >>>> > can update > >>>> > >> >>> >> bundled_master.xml. This file must be > >>>> > manually kept up to > >>>> > >> >>> >> date whenever > >>>> > >> >>> >> any documentation changes are made. > >>>> > >> >>> >> > >>>> > >> >>> >> Thanks, > >>>> > >> >>> >> Shane > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> >>>> > DocBook XML V4.5//EN" > >>>> > >> >>> >> > >>>> > "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ ]> > >>>> > >> >>> >> >>>> > xmlns:xi="http://www.w3.org/2001/XInclude"> > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> Seam 3 > >>>> > >> >>> >> Bundled Reference > >>>> > Guide > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> Forge > >>>> > >> >>> >> > >>>> > >> >>> >> >>>> > href="forge-installation.xml" /> > >>>> > >> >>> >> >>>> > href="forge-creating-basic-webapp.xml" /> > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> Seam Solder > >>>> > >> >>> >> > >>>> > >> >>> >> >>>> > href="solder-gettingstarted.xml"/> > >>>> > >> >>> >> >>>> > href="solder-programmingmodel.xml"/> > >>>> > >> >>> >> >>>> > href="solder-annotationliterals.xml"/> > >>>> > >> >>> >> >>>> > href="solder-elextensions.xml"/> > >>>> > >> >>> >> >>>> > href="solder-resourceloading.xml"/> > >>>> > >> >>> >> > >>>> > >> >>> >> >>>> > href="solder-typeutilities.xml"/> > >>>> > >> >>> >> >>>> > href="solder-beanmanagerprovider.xml"/> > >>>> > >> >>> >> >>>> > href="solder-beanutilities.xml"/> > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> >>>> > href="solder-defaultbeans.xml"/> > >>>> > >> >>> >> >>>> > href="solder-genericbeans.xml"/> > >>>> > >> >>> >> >>>> > href="solder-servicehandler.xml"/> > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> Seam Configuration > >>>> > >> >>> >> >>>> > href="config-introduction.xml"/> > >>>> > >> >>> >> >>>> > href="config-xml-provider.xml"/> > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> Seam Persistence > >>>> > >> >>> >> >>>> > href="persistence-general.xml"/> > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> Seam Transaction > >>>> > >> >>> >> >>>> > href="transaction-general.xml"/> > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> Seam Servlet > >>>> > >> >>> >> >>>> > href="servlet-introduction.xml"/> > >>>> > >> >>> >> >>>> > href="servlet-installation.xml"/> > >>>> > >> >>> >> > >>>> > >> >>> >> >>>> > href="servlet-injectable_refs.xml"/> > >>>> > >> >>> >> >>>> > href="servlet-exception_handling.xml" /> > >>>> > >> >>> >> >>>> > href="servlet-beanmanager.xml"/> > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> Seam Security > >>>> > >> >>> >> >>>> > href="security-introduction.xml"/> > >>>> > >> >>> >> >>>> > href="security-authentication.xml"/> > >>>> > >> >>> >> >>>> > href="security-identitymanagement.xml"/> > >>>> > >> >>> >> >>>> > href="security-authentication-external.xml"/> > >>>> > >> >>> >> >>>> > href="security-authorization.xml"/> > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> Seam International > >>>> > >> >>> >> >>>> > href="international-preface.xml" /> > >>>> > >> >>> >> >>>> > href="international-installation.xml" /> > >>>> > >> >>> >> >>>> > href="international-locales.xml" /> > >>>> > >> >>> >> >>>> > href="international-timezones.xml" /> > >>>> > >> >>> >> >>>> > href="international-messages.xml" /> > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> Seam Faces > >>>> > >> >>> >> > >>>> > >> >>> >> >>>> > href="faces-installation.xml" /> > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> Seam Catch > >>>> > >> >>> >> >>>> > href="catch-introduction.xml"/> > >>>> > >> >>> >> >>>> > href="catch-installation.xml"/> > >>>> > >> >>> >> >>>> > href="catch-client_usage.xml"/> > >>>> > >> >>> >> >>>> > href="catch-advanced_usage.xml"/> > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> Seam Reports > >>>> > >> >>> >> > >>>> > >> >>> >> >>>> > href="reports-installation.xml" /> > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> Seam Remoting > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> >>>> > href="remoting-validation.xml"/> > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> Seam REST > >>>> > >> >>> >> > >>>> > >> >>> >> >>>> > href="rest-installation.xml" /> > >>>> > >> >>> >> >>>> > href="rest-exception-mapping.xml" /> > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> >>>> > href="rest-dependencies.xml" /> > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> Seam JCR > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> Seam JMS > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> >>>> > href="jms-resource-injection.xml" /> > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> >>>> > href="jms-mapping-interfaces.xml" /> > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> Seam Validation > >>>> > >> >>> >> >>>> > href="validation-introduction.xml"/> > >>>> > >> >>> >> >>>> > href="validation-installation.xml"/> > >>>> > >> >>> >> >>>> > href="validation-dependency-injection.xml"/> > >>>> > >> >>> >> >>>> > href="validation-method-validation.xml"/> > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> Seam Wicket > >>>> > >> >>> >> > >>>> > >> >>> >> >>>> > href="wicket-installation.xml" /> > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > _______________________________________________ > >>>> > >> >>> >> seam-dev mailing list > >>>> > >> >>> >> seam-dev at lists.jboss.org > >>>> > > >>>> > >> >>>> > > > >>>> > >> >>> >>>> > > >>>> > >> >>>> > >> > >>>> > >> >>> >> > >>>> > https://lists.jboss.org/mailman/listinfo/seam-dev > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> -- > >>>> > >> >>> >> Lincoln Baxter, III > >>>> > >> >>> >> http://ocpsoft.com > >>>> > >> >>> >> http://scrumshark.com > >>>> > >> >>> >> "Keep it Simple" > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> > >>>> > >> >>> >> -- > >>>> > >> >>> >> Lincoln Baxter, III > >>>> > >> >>> >> http://ocpsoft.com > >>>> > >> >>> >> http://scrumshark.com > >>>> > >> >>> >> "Keep it Simple" > >>>> > >> >>> > > >>>> > >> >> > >>>> > > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > -- > >>>> > Lincoln Baxter, III > >>>> > http://ocpsoft.com > >>>> > http://scrumshark.com > >>>> > "Keep it Simple" > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> Lincoln Baxter, III > >>>> http://ocpsoft.com > >>>> http://scrumshark.com > >>>> "Keep it Simple" > >>>> _______________________________________________ > >>>> seam-dev mailing list > >>>> seam-dev at lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/seam-dev > -- Marek Novotny -- Seam and WFK Product Lead Red Hat Czech s.r.o. Purkynova 99 612 45 Brno Email: mnovotny at redhat.com Office phone: +420 532 294 287, ext. 82-62 087 mobile: +420 608 509 230 From sbryzak at redhat.com Sun Sep 4 08:48:25 2011 From: sbryzak at redhat.com (Shane Bryzak) Date: Sun, 04 Sep 2011 22:48:25 +1000 Subject: [seam-dev] Maven repository configuration in module poms Message-ID: <4E637399.80103@redhat.com> Hi all, You may have noticed that I've removed all of the repository configuration from the module poms. This was done as a required step on the path to eventually having the Seam artifacts mirrored in the Maven central repository. See Max's explanation on the following page for more information: http://community.jboss.org/wiki/MavenProjectConfigurationRequirements Shane -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110904/a389c604/attachment.html From vivek.katta at 10wickets.com Thu Sep 1 14:48:55 2011 From: vivek.katta at 10wickets.com (vivekkatta) Date: Thu, 1 Sep 2011 11:48:55 -0700 (PDT) Subject: [seam-dev] Solder MessageLogger and IllegalArgumentException In-Reply-To: <31B8398A-1CB5-464B-A26A-B64D56659409@gmail.com> References: <5237533E-F352-4367-BFC6-5748551A6ECF@gmail.com> <0B3A7BE2-9E8E-43D2-8E06-0577F98726BE@gmail.com> <31B8398A-1CB5-464B-A26A-B64D56659409@gmail.com> Message-ID: <1314902935129-3784467.post@n4.nabble.com> I am facing the same problem. Can you please provide more details on setting up seam-solder-tools? thanks.. -- View this message in context: http://seam-framework.2283336.n4.nabble.com/Solder-MessageLogger-and-IllegalArgumentException-tp3715296p3784467.html Sent from the seam-dev mailing list archive at Nabble.com. From lightguard.jp at gmail.com Tue Sep 6 16:03:56 2011 From: lightguard.jp at gmail.com (Jason Porter) Date: Tue, 6 Sep 2011 14:03:56 -0600 Subject: [seam-dev] Meeting 2011-09-07 Message-ID: Agenda - Follow-up from the last meeting (10 min) - Cloudbees - Docs - Mail Tests - Hack Night: Faces (10 min) - Next Seam 3 release (15 min) - I believe the next one is CR1 - Discuss moving to the testing structure (Ken and I believe we have the bugs ironed out) - Next week's meeting (5 min) - All Seam devs will be having a meeting, may hold off -- Jason Porter http://lightguard-jp.blogspot.com http://twitter.com/lightguardjp Software Engineer Open Source Advocate Author of Seam Catch - Next Generation Java Exception Handling PGP key id: 926CCFF5 PGP key available at: keyserver.net, pgp.mit.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110906/c586bf0c/attachment.html From sbryzak at redhat.com Tue Sep 6 20:23:38 2011 From: sbryzak at redhat.com (Shane Bryzak) Date: Wed, 07 Sep 2011 10:23:38 +1000 Subject: [seam-dev] DWG Meeting minutes Message-ID: <4E66B98A.5020303@redhat.com> People present: Jason Porter Ken Finnigan Shane Bryzak 1) Standardised error codes We discussed the idea of implementing standard error codes throughout all Seam modules. These error codes would be unique, and allow Seam developers to reference a central database (such as Seam University) describing each error and possible workarounds. The error codes themselves will be prefixed with a 2 or 3 letter code (that represents the module), followed by a number. For example: [SEC-1234] Invalid credentials supplied The SEC prefix represents an exception in the Seam Security module. Other modules would have different codes, for example CAT = Seam Catch, VAL = Seam Validation, SVL = Seam Servlet, and so forth. The number part of the error code will start at 0000 for each module. The error message itself should support internationalisation, which will be a bonus to our non-english speaking users. Each module will define its own internationalised message resources. Ken is going to work on creating a new API in Solder which we can use to perform the logging of these errors. 2) Inter-module dependencies The second topic we discussed was how we manage dependencies between modules. It was agreed that wherever possible, dependencies should be optional. An example of this is the dependency that seam-faces has on seam-catch. In some cases it may be necessary for a module to have a hard dependency on another module, however if this becomes an issue in the future we may look at alternatives such as creating sub-modules that separate the integration from the rest of the module. If anyone has any questions, feel free to ask. We will be holding the DWG meeting in TeamSpeak once per month, on the first tuesday of the month - details can be found in the seam-dev calendar. Thanks, Shane From lincolnbaxter at gmail.com Wed Sep 7 00:03:03 2011 From: lincolnbaxter at gmail.com (Lincoln Baxter, III) Date: Wed, 7 Sep 2011 00:03:03 -0400 Subject: [seam-dev] DWG Meeting minutes In-Reply-To: <4E66B98A.5020303@redhat.com> References: <4E66B98A.5020303@redhat.com> Message-ID: Sorry I missed this, guys. I ended up getting stuck in traffic on my way to Albany :( -- Lincoln Baxter's Droid http://ocpsoft.com "Keep it Simple" On Sep 6, 2011 8:26 PM, "Shane Bryzak" wrote: > People present: > > Jason Porter > Ken Finnigan > Shane Bryzak > > 1) Standardised error codes > > We discussed the idea of implementing standard error codes throughout > all Seam modules. These error codes would be unique, and allow Seam > developers to reference a central database (such as Seam University) > describing each error and possible workarounds. The error codes > themselves will be prefixed with a 2 or 3 letter code (that represents > the module), followed by a number. For example: > > [SEC-1234] Invalid credentials supplied > > The SEC prefix represents an exception in the Seam Security module. > Other modules would have different codes, for example CAT = Seam Catch, > VAL = Seam Validation, SVL = Seam Servlet, and so forth. The number > part of the error code will start at 0000 for each module. The error > message itself should support internationalisation, which will be a > bonus to our non-english speaking users. Each module will define its > own internationalised message resources. Ken is going to work on > creating a new API in Solder which we can use to perform the logging of > these errors. > > 2) Inter-module dependencies > > The second topic we discussed was how we manage dependencies between > modules. It was agreed that wherever possible, dependencies should be > optional. An example of this is the dependency that seam-faces has on > seam-catch. In some cases it may be necessary for a module to have a > hard dependency on another module, however if this becomes an issue in > the future we may look at alternatives such as creating sub-modules that > separate the integration from the rest of the module. > > If anyone has any questions, feel free to ask. We will be holding the > DWG meeting in TeamSpeak once per month, on the first tuesday of the > month - details can be found in the seam-dev calendar. > > Thanks, > Shane > _______________________________________________ > seam-dev mailing list > seam-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/seam-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110907/a480018c/attachment.html From max.andersen at redhat.com Wed Sep 7 02:10:56 2011 From: max.andersen at redhat.com (Max Rydahl Andersen) Date: Wed, 7 Sep 2011 08:10:56 +0200 Subject: [seam-dev] DWG Meeting minutes In-Reply-To: <4E66B98A.5020303@redhat.com> References: <4E66B98A.5020303@redhat.com> Message-ID: > 1) Standardised error codes > > We discussed the idea of implementing standard error codes throughout > all Seam modules. These error codes would be unique, and allow Seam > developers to reference a central database (such as Seam University) > describing each error and possible workarounds. The error codes > themselves will be prefixed with a 2 or 3 letter code (that represents > the module), followed by a number. For example: > > [SEC-1234] Invalid credentials supplied > > The SEC prefix represents an exception in the Seam Security module. > Other modules would have different codes, for example CAT = Seam Catch, > VAL = Seam Validation, SVL = Seam Servlet, and so forth. The number > part of the error code will start at 0000 for each module. The error > message itself should support internationalisation, which will be a > bonus to our non-english speaking users. Each module will define its > own internationalised message resources. Ken is going to work on > creating a new API in Solder which we can use to perform the logging of > these errors. How does this relate to http://community.jboss.org/wiki/HowToLogInJBossProjects ? I assume this is just the same and you'll need to go grab those prefixes ? btw. what is DWG ? :) /max http://about.me/maxandersen From max.andersen at redhat.com Wed Sep 7 02:11:59 2011 From: max.andersen at redhat.com (Max Rydahl Andersen) Date: Wed, 7 Sep 2011 08:11:59 +0200 Subject: [seam-dev] DWG Meeting minutes In-Reply-To: References: <4E66B98A.5020303@redhat.com> Message-ID: <47644475-7D1D-49EA-B3A0-4BD7F55EB0AF@redhat.com> > btw. what is DWG ? :) Design Working Group - got it ;) /max http://about.me/maxandersen From sbryzak at redhat.com Wed Sep 7 02:21:59 2011 From: sbryzak at redhat.com (Shane Bryzak) Date: Wed, 07 Sep 2011 16:21:59 +1000 Subject: [seam-dev] DWG Meeting minutes In-Reply-To: References: <4E66B98A.5020303@redhat.com> Message-ID: <4E670D87.3030300@redhat.com> On 07/09/11 16:10, Max Rydahl Andersen wrote: >> 1) Standardised error codes >> >> We discussed the idea of implementing standard error codes throughout >> all Seam modules. These error codes would be unique, and allow Seam >> developers to reference a central database (such as Seam University) >> describing each error and possible workarounds. The error codes >> themselves will be prefixed with a 2 or 3 letter code (that represents >> the module), followed by a number. For example: >> >> [SEC-1234] Invalid credentials supplied >> >> The SEC prefix represents an exception in the Seam Security module. >> Other modules would have different codes, for example CAT = Seam Catch, >> VAL = Seam Validation, SVL = Seam Servlet, and so forth. The number >> part of the error code will start at 0000 for each module. The error >> message itself should support internationalisation, which will be a >> bonus to our non-english speaking users. Each module will define its >> own internationalised message resources. Ken is going to work on >> creating a new API in Solder which we can use to perform the logging of >> these errors. > How does this relate to http://community.jboss.org/wiki/HowToLogInJBossProjects ? > > I assume this is just the same and you'll need to go grab those prefixes ? > > btw. what is DWG ? :) > > /max > http://about.me/maxandersen > > > Hmm, I wasn't aware of that document. I guess that we register SM as the Seam Event ID prefix, and then append the module code onto that. So SMSEC for Seam Security, SMSLD for Solder, etc. From ken at kenfinnigan.me Wed Sep 7 15:51:47 2011 From: ken at kenfinnigan.me (Ken Finnigan) Date: Wed, 7 Sep 2011 15:51:47 -0400 Subject: [seam-dev] Meeting 2011-09-07 In-Reply-To: References: Message-ID: Unfortunately I won't be able to make the seam-dev meeting today, I'm blaming it on the newborn! ;-) To briefly mention the below agenda item regarding the testsuite, we've found out that the best solution is to use the unpack plugin for Maven as part of the build process to take the tests from the base module and add them into the test-classes of a container specific module so that Surefire will pick them up for testing. The major problem was always the IDE. I think Jason has discovered a solution for IDEA, and I found one for Eclipse. The Eclipse solution is within the container specific module for the testsuite to "link source" for that project and link to the src/main/java and src/main/resources of the base project module. Doing this enables you to execute a single test, or all the tests in the module, against the specific container of that module. Another added bonus is that editing the test classes that have been linked modifies them within the base module src path, ensuring that changes are not lost and are committed to where they need to be. The one downside to the above approach for Eclipse is that running Maven -> Update Project Configuration removes the source linkages that have been added within the IDE. I haven't had a chance to investigate this yet, but I'm hoping it's possible to script the link source commands so that we can provide those scripts with the modules to make it easy to add them back. Any questions or concerns please drop me a mail. If there's anything from the meeting that I need to look at please let me know. Ken On Tue, Sep 6, 2011 at 4:03 PM, Jason Porter wrote: > Agenda > > - Follow-up from the last meeting (10 min) > - Cloudbees > - Docs > - Mail Tests > - Hack Night: Faces (10 min) > - Next Seam 3 release (15 min) > - I believe the next one is CR1 > - Discuss moving to the testing structure (Ken and I believe we have > the bugs ironed out) > - Next week's meeting (5 min) > - All Seam devs will be having a meeting, may hold off > > > -- > Jason Porter > http://lightguard-jp.blogspot.com > http://twitter.com/lightguardjp > > Software Engineer > Open Source Advocate > Author of Seam Catch - Next Generation Java Exception Handling > > PGP key id: 926CCFF5 > PGP key available at: keyserver.net, pgp.mit.edu > > _______________________________________________ > seam-dev mailing list > seam-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/seam-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110907/14dae1fb/attachment.html From lightguard.jp at gmail.com Wed Sep 7 17:58:58 2011 From: lightguard.jp at gmail.com (Jason Porter) Date: Wed, 7 Sep 2011 15:58:58 -0600 Subject: [seam-dev] Meeting 2011-09-07 In-Reply-To: References: Message-ID: ================= #seam-dev Meeting ================= Meeting started by lightguard_jp at 21:10:43 UTC. The full logs are available athttp://transcripts.jboss.org/meeting/irc.freenode.org/seam-dev/2011/seam-dev.2011-09-07-21.10.log.html . Meeting summary --------------- * Follow up from the last meeting (lightguard_jp, 21:10:58) * I've opened a ticket to upgrade our account to FOSS Professional, however, it seems we're waiting for them to fix something on their end so we can do it ourselves (lightguard_jp, 21:11:30) * I haven't been able to the Report docs (lightguard_jp, 21:11:48) * I think JMS had some doc issues too. (lightguard_jp, 21:11:57) * sbryzak was going to help out with the mail tests, I think that's been figured out. (lightguard_jp, 21:19:43) * ACTION: lightguard_jp Still needs to create the Report docs (lightguard_jp, 21:20:35) * ACTION: sbryzak will continue to help with mail tests (lightguard_jp, 21:20:56) * Giving module leads "voice" in the channel. (lightguard_jp, 21:22:18) * ACTION: lightguard_jp and mojavelinux will give "initative leads" auto voice in the channel. (lightguard_jp, 21:26:01) * Next Hack Night (lightguard_jp, 21:26:14) * I have a list of JIRAs to look at (lightguard_jp, 21:26:53) * LINK: https://issues.jboss.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+SEAMFACES+AND+fixVersion+%3D+%223.1.0.Tracking%22+AND+status+%3D+Open+ORDER+BY+priority+DESC&mode=hide (lightguard_jp, 21:27:24) * the hack nights are in the jboss.org calendar and also in the seam-dev google calendar (lightguard_jp, 21:30:03) * Next Seam 3 release. (lightguard_jp, 21:30:25) * Keep an ear out next week for a date for CR1 (lightguard_jp, 21:37:00) * Next week's meeting (lightguard_jp, 21:49:09) * AGREED: Next week's meeting will be skipped (lightguard_jp, 21:50:11) Meeting ended at 21:56:38 UTC. Action Items ------------ * lightguard_jp Still needs to create the Report docs * sbryzak will continue to help with mail tests * lightguard_jp and mojavelinux will give "initative leads" auto voice in the channel. Action Items, by person ----------------------- * lightguard_jp * lightguard_jp Still needs to create the Report docs * lightguard_jp and mojavelinux will give "initative leads" auto voice in the channel. * mojavelinux * lightguard_jp and mojavelinux will give "initative leads" auto voice in the channel. * sbryzak * sbryzak will continue to help with mail tests * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * lightguard_jp (83) * mojavelinux (53) * sbryzak (46) * lincolnthree (40) * clerum1 (9) * hannelita (9) * rruss (7) * jbott (2) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot On Tue, Sep 6, 2011 at 14:03, Jason Porter wrote: > Agenda > > - Follow-up from the last meeting (10 min) > - Cloudbees > - Docs > - Mail Tests > - Hack Night: Faces (10 min) > - Next Seam 3 release (15 min) > - I believe the next one is CR1 > - Discuss moving to the testing structure (Ken and I believe we have > the bugs ironed out) > - Next week's meeting (5 min) > - All Seam devs will be having a meeting, may hold off > > > -- > Jason Porter > http://lightguard-jp.blogspot.com > http://twitter.com/lightguardjp > > Software Engineer > Open Source Advocate > Author of Seam Catch - Next Generation Java Exception Handling > > PGP key id: 926CCFF5 > PGP key available at: keyserver.net, pgp.mit.edu > -- Jason Porter http://lightguard-jp.blogspot.com http://twitter.com/lightguardjp Software Engineer Open Source Advocate Author of Seam Catch - Next Generation Java Exception Handling PGP key id: 926CCFF5 PGP key available at: keyserver.net, pgp.mit.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110907/9d0a2f67/attachment.html From dan.j.allen at gmail.com Wed Sep 7 18:11:24 2011 From: dan.j.allen at gmail.com (Dan Allen) Date: Wed, 7 Sep 2011 18:11:24 -0400 Subject: [seam-dev] Meeting 2011-09-07 In-Reply-To: References: Message-ID: Thanks for the assessment of the test setup. I'm going to look it over, hopefully sitting down with Aslak at next weeks f2f and really exploring the problem in every way we can. I think we are close to the right solution, but I still want to consider some more options, even if it means modifications to Arquillian to make it work. -Dan On Wed, Sep 7, 2011 at 15:51, Ken Finnigan wrote: > Unfortunately I won't be able to make the seam-dev meeting today, I'm > blaming it on the newborn! ;-) > > To briefly mention the below agenda item regarding the testsuite, we've > found out that the best solution is to use the unpack plugin for Maven as > part of the build process to take the tests from the base module and add > them into the test-classes of a container specific module so that Surefire > will pick them up for testing. > > The major problem was always the IDE. I think Jason has discovered a > solution for IDEA, and I found one for Eclipse. The Eclipse solution is > within the container specific module for the testsuite to "link source" for > that project and link to the src/main/java and src/main/resources of the > base project module. Doing this enables you to execute a single test, or > all the tests in the module, against the specific container of that module. > Another added bonus is that editing the test classes that have been linked > modifies them within the base module src path, ensuring that changes are not > lost and are committed to where they need to be. > > The one downside to the above approach for Eclipse is that running Maven -> > Update Project Configuration removes the source linkages that have been > added within the IDE. I haven't had a chance to investigate this yet, but > I'm hoping it's possible to script the link source commands so that we can > provide those scripts with the modules to make it easy to add them back. > > Any questions or concerns please drop me a mail. > > If there's anything from the meeting that I need to look at please let me > know. > > Ken > > > On Tue, Sep 6, 2011 at 4:03 PM, Jason Porter wrote: > >> Agenda >> >> - Follow-up from the last meeting (10 min) >> - Cloudbees >> - Docs >> - Mail Tests >> - Hack Night: Faces (10 min) >> - Next Seam 3 release (15 min) >> - I believe the next one is CR1 >> - Discuss moving to the testing structure (Ken and I believe we >> have the bugs ironed out) >> - Next week's meeting (5 min) >> - All Seam devs will be having a meeting, may hold off >> >> >> -- >> Jason Porter >> http://lightguard-jp.blogspot.com >> http://twitter.com/lightguardjp >> >> Software Engineer >> Open Source Advocate >> Author of Seam Catch - Next Generation Java Exception Handling >> >> PGP key id: 926CCFF5 >> PGP key available at: keyserver.net, pgp.mit.edu >> >> _______________________________________________ >> seam-dev mailing list >> seam-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/seam-dev >> >> > > _______________________________________________ > seam-dev mailing list > seam-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/seam-dev > > -- Dan Allen Principal Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://www.google.com/profiles/dan.j.allen#about http://mojavelinux.com http://mojavelinux.com/seaminaction -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110907/f6fb6ce6/attachment.html From ken at kenfinnigan.me Wed Sep 7 20:29:24 2011 From: ken at kenfinnigan.me (Ken Finnigan) Date: Wed, 7 Sep 2011 20:29:24 -0400 Subject: [seam-dev] Meeting 2011-09-07 In-Reply-To: References: Message-ID: <71C33C85-B39A-46E1-8031-A6C0F32B3722@kenfinnigan.me> Another option I've thought of is creating our own Maven plugin that does a similar job to unpack, but allows specifying which src dirs to link to in a project. Then see if the JBossTools guys can write an m2e addition that interprets the plugin correctly in the IDE to link the src dirs that were set in the configuration. Ken Sent from my iPhone On Sep 7, 2011, at 18:11, Dan Allen wrote: > Thanks for the assessment of the test setup. I'm going to look it over, hopefully sitting down with Aslak at next weeks f2f and really exploring the problem in every way we can. I think we are close to the right solution, but I still want to consider some more options, even if it means modifications to Arquillian to make it work. > > -Dan > > On Wed, Sep 7, 2011 at 15:51, Ken Finnigan wrote: > Unfortunately I won't be able to make the seam-dev meeting today, I'm blaming it on the newborn! ;-) > > To briefly mention the below agenda item regarding the testsuite, we've found out that the best solution is to use the unpack plugin for Maven as part of the build process to take the tests from the base module and add them into the test-classes of a container specific module so that Surefire will pick them up for testing. > > The major problem was always the IDE. I think Jason has discovered a solution for IDEA, and I found one for Eclipse. The Eclipse solution is within the container specific module for the testsuite to "link source" for that project and link to the src/main/java and src/main/resources of the base project module. Doing this enables you to execute a single test, or all the tests in the module, against the specific container of that module. Another added bonus is that editing the test classes that have been linked modifies them within the base module src path, ensuring that changes are not lost and are committed to where they need to be. > > The one downside to the above approach for Eclipse is that running Maven -> Update Project Configuration removes the source linkages that have been added within the IDE. I haven't had a chance to investigate this yet, but I'm hoping it's possible to script the link source commands so that we can provide those scripts with the modules to make it easy to add them back. > > Any questions or concerns please drop me a mail. > > If there's anything from the meeting that I need to look at please let me know. > > Ken > > > On Tue, Sep 6, 2011 at 4:03 PM, Jason Porter wrote: > Agenda > Follow-up from the last meeting (10 min) > Cloudbees > Docs > Mail Tests > Hack Night: Faces (10 min) > Next Seam 3 release (15 min) > I believe the next one is CR1 > Discuss moving to the testing structure (Ken and I believe we have the bugs ironed out) > Next week's meeting (5 min) > All Seam devs will be having a meeting, may hold off > > -- > Jason Porter > http://lightguard-jp.blogspot.com > http://twitter.com/lightguardjp > > Software Engineer > Open Source Advocate > Author of Seam Catch - Next Generation Java Exception Handling > > PGP key id: 926CCFF5 > PGP key available at: keyserver.net, pgp.mit.edu > > _______________________________________________ > seam-dev mailing list > seam-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/seam-dev > > > > _______________________________________________ > seam-dev mailing list > seam-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/seam-dev > > > > > -- > Dan Allen > Principal Software Engineer, Red Hat | Author of Seam in Action > Registered Linux User #231597 > > http://www.google.com/profiles/dan.j.allen#about > http://mojavelinux.com > http://mojavelinux.com/seaminaction > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110907/da0f9253/attachment-0001.html From lightguard.jp at gmail.com Thu Sep 8 00:26:38 2011 From: lightguard.jp at gmail.com (Jason Porter) Date: Wed, 7 Sep 2011 22:26:38 -0600 Subject: [seam-dev] Meeting 2011-09-07 In-Reply-To: <71C33C85-B39A-46E1-8031-A6C0F32B3722@kenfinnigan.me> References: <71C33C85-B39A-46E1-8031-A6C0F32B3722@kenfinnigan.me> Message-ID: What may actually work well for all of this is if Arquillian supported creating test suites, that may actually make this all go away :) On Wed, Sep 7, 2011 at 18:29, Ken Finnigan wrote: > Another option I've thought of is creating our own Maven plugin that does a > similar job to unpack, but allows specifying which src dirs to link to in a > project. Then see if the JBossTools guys can write an m2e addition that > interprets the plugin correctly in the IDE to link the src dirs that were > set in the configuration. > > Ken > > Sent from my iPhone > > On Sep 7, 2011, at 18:11, Dan Allen wrote: > > Thanks for the assessment of the test setup. I'm going to look it over, > hopefully sitting down with Aslak at next weeks f2f and really exploring the > problem in every way we can. I think we are close to the right solution, but > I still want to consider some more options, even if it means modifications > to Arquillian to make it work. > > -Dan > > On Wed, Sep 7, 2011 at 15:51, Ken Finnigan < > ken at kenfinnigan.me> wrote: > >> Unfortunately I won't be able to make the seam-dev meeting today, I'm >> blaming it on the newborn! ;-) >> >> To briefly mention the below agenda item regarding the testsuite, we've >> found out that the best solution is to use the unpack plugin for Maven as >> part of the build process to take the tests from the base module and add >> them into the test-classes of a container specific module so that Surefire >> will pick them up for testing. >> >> The major problem was always the IDE. I think Jason has discovered a >> solution for IDEA, and I found one for Eclipse. The Eclipse solution is >> within the container specific module for the testsuite to "link source" for >> that project and link to the src/main/java and src/main/resources of the >> base project module. Doing this enables you to execute a single test, or >> all the tests in the module, against the specific container of that module. >> Another added bonus is that editing the test classes that have been linked >> modifies them within the base module src path, ensuring that changes are not >> lost and are committed to where they need to be. >> >> The one downside to the above approach for Eclipse is that running Maven >> -> Update Project Configuration removes the source linkages that have been >> added within the IDE. I haven't had a chance to investigate this yet, but >> I'm hoping it's possible to script the link source commands so that we can >> provide those scripts with the modules to make it easy to add them back. >> >> Any questions or concerns please drop me a mail. >> >> If there's anything from the meeting that I need to look at please let me >> know. >> >> Ken >> >> >> On Tue, Sep 6, 2011 at 4:03 PM, Jason Porter < >> lightguard.jp at gmail.com> wrote: >> >>> Agenda >>> >>> - Follow-up from the last meeting (10 min) >>> - Cloudbees >>> - Docs >>> - Mail Tests >>> - Hack Night: Faces (10 min) >>> - Next Seam 3 release (15 min) >>> - I believe the next one is CR1 >>> - Discuss moving to the testing structure (Ken and I believe we >>> have the bugs ironed out) >>> - Next week's meeting (5 min) >>> - All Seam devs will be having a meeting, may hold off >>> >>> >>> -- >>> Jason Porter >>> http://lightguard-jp.blogspot.com >>> http://twitter.com/lightguardjp >>> >>> Software Engineer >>> Open Source Advocate >>> Author of Seam Catch - Next Generation Java Exception Handling >>> >>> PGP key id: 926CCFF5 >>> PGP key available at: keyserver.net, >>> pgp.mit.edu >>> >>> _______________________________________________ >>> seam-dev mailing list >>> seam-dev at lists.jboss.org >>> >>> https://lists.jboss.org/mailman/listinfo/seam-dev >>> >>> >> >> _______________________________________________ >> seam-dev mailing list >> seam-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/seam-dev >> >> > > > -- > Dan Allen > Principal Software Engineer, Red Hat | Author of Seam in Action > Registered Linux User #231597 > > > http://www.google.com/profiles/dan.j.allen#about > http://mojavelinux.com > http://mojavelinux.com/seaminaction > > -- Jason Porter http://lightguard-jp.blogspot.com http://twitter.com/lightguardjp Software Engineer Open Source Advocate Author of Seam Catch - Next Generation Java Exception Handling PGP key id: 926CCFF5 PGP key available at: keyserver.net, pgp.mit.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110907/da5184e1/attachment.html From pmuir at redhat.com Mon Sep 12 10:51:14 2011 From: pmuir at redhat.com (Pete Muir) Date: Mon, 12 Sep 2011 10:51:14 -0400 Subject: [seam-dev] Enabling extensions Message-ID: <5601C05A-9471-4599-B7E6-2F8DA1BE8B26@redhat.com> Seam team, and others on the CDI EG, Looking for feedback on an issue Marius and I discussed in CDI 1.0. This is potentially an issue - we weren't sure if people had seen it in the real world, hopefully you may have seen feedback in the forums or at conferences. This relates closely to the interceptor/decorator/alternative enabling discussion. Typically an extension class is packaged in a jar, along with a META-INF/services/javax.enterprise.inject.spi.Extension file which enables it. However, this means that an application, or another extension, has no way of disabling extensions. Is this a problem, really? Or just theoretically. From struberg at yahoo.de Mon Sep 12 11:47:02 2011 From: struberg at yahoo.de (Mark Struberg) Date: Mon, 12 Sep 2011 16:47:02 +0100 (BST) Subject: [seam-dev] Enabling extensions In-Reply-To: <5601C05A-9471-4599-B7E6-2F8DA1BE8B26@redhat.com> References: <5601C05A-9471-4599-B7E6-2F8DA1BE8B26@redhat.com> Message-ID: <1315842422.44914.YahooMailNeo@web27807.mail.ukl.yahoo.com> I remember that we discussed this 2 years ago ;) In Apache MyFaces CODI we introduced an internal Deactivatable interface which by default gets implemented via ??? public boolean isActivated() ??? { ??????? return ClassDeactivation.isClassActivated(getClass()); ??? } (another internal class). and in the Extension itself ??? if(!isActivated()) ??????? { ??????????? return; ??????? } A similar mechanism should be available in each bigger Extension library (not only containing 1 single CDI Extension) But would be helpful to have something like that in the standard of course! LieGrue, strub ----- Original Message ----- > From: Pete Muir > To: cdi-dev at lists.jboss.org; "seam-dev >> seam-dev at lists. jboss. org Development List" > Cc: > Sent: Monday, September 12, 2011 4:51 PM > Subject: [seam-dev] Enabling extensions > > Seam team, and others on the CDI EG, > > Looking for feedback on an issue Marius and I discussed in CDI 1.0. This is > potentially an issue - we weren't sure if people had seen it in the real > world, hopefully you may have seen feedback in the forums or at conferences. > > This relates closely to the interceptor/decorator/alternative enabling > discussion. > > Typically an extension class is packaged in a jar, along with a > META-INF/services/javax.enterprise.inject.spi.Extension file which enables it. > However, this means that an application, or another extension, has no way of > disabling extensions. > > Is this a problem, really? Or just theoretically. > _______________________________________________ > seam-dev mailing list > seam-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/seam-dev > From pmuir at redhat.com Mon Sep 12 11:58:06 2011 From: pmuir at redhat.com (Pete Muir) Date: Mon, 12 Sep 2011 11:58:06 -0400 Subject: [seam-dev] Enabling extensions In-Reply-To: <1315842422.44914.YahooMailNeo@web27807.mail.ukl.yahoo.com> References: <5601C05A-9471-4599-B7E6-2F8DA1BE8B26@redhat.com> <1315842422.44914.YahooMailNeo@web27807.mail.ukl.yahoo.com> Message-ID: <95D2192A-6AE5-4D71-ABAB-A091136FECF0@redhat.com> Thanks Jens & Mark, obviously a real issue! https://issues.jboss.org/browse/CDI-157 On 12 Sep 2011, at 11:47, Mark Struberg wrote: > I remember that we discussed this 2 years ago ;) > > In Apache MyFaces CODI we introduced an internal Deactivatable interface which by default gets implemented via > > public boolean isActivated() > { > return ClassDeactivation.isClassActivated(getClass()); > } > > (another internal class). > > and in the Extension itself > if(!isActivated()) > { > return; > } > > > A similar mechanism should be available in each bigger Extension library (not only containing 1 single CDI Extension) > But would be helpful to have something like that in the standard of course! > > LieGrue, > strub > > > ----- Original Message ----- >> From: Pete Muir >> To: cdi-dev at lists.jboss.org; "seam-dev >> seam-dev at lists. jboss. org Development List" >> Cc: >> Sent: Monday, September 12, 2011 4:51 PM >> Subject: [seam-dev] Enabling extensions >> >> Seam team, and others on the CDI EG, >> >> Looking for feedback on an issue Marius and I discussed in CDI 1.0. This is >> potentially an issue - we weren't sure if people had seen it in the real >> world, hopefully you may have seen feedback in the forums or at conferences. >> >> This relates closely to the interceptor/decorator/alternative enabling >> discussion. >> >> Typically an extension class is packaged in a jar, along with a >> META-INF/services/javax.enterprise.inject.spi.Extension file which enables it. >> However, this means that an application, or another extension, has no way of >> disabling extensions. >> >> Is this a problem, really? Or just theoretically. >> _______________________________________________ >> seam-dev mailing list >> seam-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/seam-dev >> From max.andersen at redhat.com Tue Sep 13 07:24:43 2011 From: max.andersen at redhat.com (Max Rydahl Andersen) Date: Tue, 13 Sep 2011 13:24:43 +0200 Subject: [seam-dev] DWG Meeting minutes In-Reply-To: <4E670D87.3030300@redhat.com> References: <4E66B98A.5020303@redhat.com> <4E670D87.3030300@redhat.com> Message-ID: >>> >> How does this relate to http://community.jboss.org/wiki/HowToLogInJBossProjects ? >> >> I assume this is just the same and you'll need to go grab those prefixes ? >> >> btw. what is DWG ? :) >> >> /max >> http://about.me/maxandersen >> >> >> > > Hmm, I wasn't aware of that document. I guess that we register SM as the Seam Event ID prefix, and then append the module code onto that. So SMSEC for Seam Security, SMSLD for Solder, etc. That would probably work ;) i18n (and somewhat tooling) improvements are bound to these Logging and exception errors being handled somewhat uniformly so worth keeping an eye on that doc/TAG work. /max http://about.me/maxandersen From ken at kenfinnigan.me Tue Sep 13 12:09:25 2011 From: ken at kenfinnigan.me (Ken Finnigan) Date: Tue, 13 Sep 2011 12:09:25 -0400 Subject: [seam-dev] DWG Meeting minutes In-Reply-To: <4E66B98A.5020303@redhat.com> References: <4E66B98A.5020303@redhat.com> Message-ID: Shane, Looks good to me. I know we discussed a possible API for Solder to support the error messages, but can't recall (and didn't write it down, doh!) what you suggested. Can you remember? Thanks Ken On Tue, Sep 6, 2011 at 8:23 PM, Shane Bryzak wrote: > People present: > > Jason Porter > Ken Finnigan > Shane Bryzak > > 1) Standardised error codes > > We discussed the idea of implementing standard error codes throughout > all Seam modules. These error codes would be unique, and allow Seam > developers to reference a central database (such as Seam University) > describing each error and possible workarounds. The error codes > themselves will be prefixed with a 2 or 3 letter code (that represents > the module), followed by a number. For example: > > [SEC-1234] Invalid credentials supplied > > The SEC prefix represents an exception in the Seam Security module. > Other modules would have different codes, for example CAT = Seam Catch, > VAL = Seam Validation, SVL = Seam Servlet, and so forth. The number > part of the error code will start at 0000 for each module. The error > message itself should support internationalisation, which will be a > bonus to our non-english speaking users. Each module will define its > own internationalised message resources. Ken is going to work on > creating a new API in Solder which we can use to perform the logging of > these errors. > > 2) Inter-module dependencies > > The second topic we discussed was how we manage dependencies between > modules. It was agreed that wherever possible, dependencies should be > optional. An example of this is the dependency that seam-faces has on > seam-catch. In some cases it may be necessary for a module to have a > hard dependency on another module, however if this becomes an issue in > the future we may look at alternatives such as creating sub-modules that > separate the integration from the rest of the module. > > If anyone has any questions, feel free to ask. We will be holding the > DWG meeting in TeamSpeak once per month, on the first tuesday of the > month - details can be found in the seam-dev calendar. > > Thanks, > Shane > _______________________________________________ > seam-dev mailing list > seam-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/seam-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110913/bb1ad38e/attachment.html From sbryzak at redhat.com Mon Sep 19 18:19:51 2011 From: sbryzak at redhat.com (Shane Bryzak) Date: Tue, 20 Sep 2011 08:19:51 +1000 Subject: [seam-dev] Testsuite discussion notes In-Reply-To: <4E77460E.5070304@redhat.com> References: <4E77460E.5070304@redhat.com> Message-ID: <4E77C007.5070505@redhat.com> Was it decided who would take care of the testsuite restructure? I must admit I wasn't paying much attention during this discussion ;) On 19/09/11 23:39, Jozef Hartinger wrote: > INTEGRATION TESTS > > Structure: > > - api > - impl > - testsuite / src / test / java > > Container-specific issues > - there will be a BaseDeploymentFactory that creates base deployment > based on a system property (arquillian container name) > - there will be no common package scheme for now > > Default profile > - weld embedded > - skipped tests if weld embedded does not make sense in the context of > the module > > > FUNCTIONAL TESTS > - m4 will be used to generate pom files from our templates (stored in > Seam QA github) > From lightguard.jp at gmail.com Mon Sep 19 18:24:42 2011 From: lightguard.jp at gmail.com (Jason Porter) Date: Mon, 19 Sep 2011 16:24:42 -0600 Subject: [seam-dev] Testsuite discussion notes In-Reply-To: <4E77C007.5070505@redhat.com> References: <4E77460E.5070304@redhat.com> <4E77C007.5070505@redhat.com> Message-ID: <255062B5-702B-4721-946A-DA68413BC689@gmail.com> No, we didn't assign it to anyone. Sent from my iPhone On Sep 19, 2011, at 16:19, Shane Bryzak wrote: > Was it decided who would take care of the testsuite restructure? I must > admit I wasn't paying much attention during this discussion ;) > > On 19/09/11 23:39, Jozef Hartinger wrote: >> INTEGRATION TESTS >> >> Structure: >> >> - api >> - impl >> - testsuite / src / test / java >> >> Container-specific issues >> - there will be a BaseDeploymentFactory that creates base deployment >> based on a system property (arquillian container name) >> - there will be no common package scheme for now >> >> Default profile >> - weld embedded >> - skipped tests if weld embedded does not make sense in the context of >> the module >> >> >> FUNCTIONAL TESTS >> - m4 will be used to generate pom files from our templates (stored in >> Seam QA github) >> > > _______________________________________________ > seam-dev mailing list > seam-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/seam-dev From john.d.ament at gmail.com Mon Sep 19 18:45:33 2011 From: john.d.ament at gmail.com (John D. Ament) Date: Mon, 19 Sep 2011 18:45:33 -0400 Subject: [seam-dev] Testsuite discussion notes In-Reply-To: <255062B5-702B-4721-946A-DA68413BC689@gmail.com> References: <4E77460E.5070304@redhat.com> <4E77C007.5070505@redhat.com> <255062B5-702B-4721-946A-DA68413BC689@gmail.com> Message-ID: Good. I'm scratching my head about some of my pull requests. JMS is a bit overly complicated. On Mon, Sep 19, 2011 at 6:24 PM, Jason Porter wrote: > No, we didn't assign it to anyone. > > Sent from my iPhone > > On Sep 19, 2011, at 16:19, Shane Bryzak wrote: > > > Was it decided who would take care of the testsuite restructure? I must > > admit I wasn't paying much attention during this discussion ;) > > > > On 19/09/11 23:39, Jozef Hartinger wrote: > >> INTEGRATION TESTS > >> > >> Structure: > >> > >> - api > >> - impl > >> - testsuite / src / test / java > >> > >> Container-specific issues > >> - there will be a BaseDeploymentFactory that creates base deployment > >> based on a system property (arquillian container name) > >> - there will be no common package scheme for now > >> > >> Default profile > >> - weld embedded > >> - skipped tests if weld embedded does not make sense in the context of > >> the module > >> > >> > >> FUNCTIONAL TESTS > >> - m4 will be used to generate pom files from our templates (stored in > >> Seam QA github) > >> > > > > _______________________________________________ > > seam-dev mailing list > > seam-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/seam-dev > _______________________________________________ > seam-dev mailing list > seam-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/seam-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110919/5f77c985/attachment.html From lightguard.jp at gmail.com Mon Sep 19 23:45:10 2011 From: lightguard.jp at gmail.com (Jason Porter) Date: Mon, 19 Sep 2011 21:45:10 -0600 Subject: [seam-dev] Meeting 2011-09-21 Message-ID: - Community Update about F2F Meeting - Logging - Testing Structure Update - Examples - 3.1.0.Beta3 -- Jason Porter http://lightguard-jp.blogspot.com http://twitter.com/lightguardjp Software Engineer Open Source Advocate Author of Seam Catch - Next Generation Java Exception Handling PGP key id: 926CCFF5 PGP key available at: keyserver.net, pgp.mit.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110919/15876d68/attachment.html From lightguard.jp at gmail.com Tue Sep 20 01:59:54 2011 From: lightguard.jp at gmail.com (Jason Porter) Date: Mon, 19 Sep 2011 23:59:54 -0600 Subject: [seam-dev] SAF (aka Entity Framework) idea in Seam 3 Message-ID: The Home idea https://github.com/seam/seam-example-confbuzz/blob/develop/src/main/java/seam/example/confbuzz/ConferenceInstance.java The Query idea https://github.com/seam/seam-example-confbuzz/blob/develop/src/main/java/seam/example/confbuzz/TodaysConferencesQuery.java The main thing that I would change with the Query class above is to use named queries, thus espousing the generally accepted best practice in default applications. I understand this doesn't fill all the gaps of the older SAF from Seam 2, but I think it works for the majority of cases, and it also helps people understand the best way to do things instead of relying on the magic of SAF from Seam 2 (which I have found to be a major problem in projects and teams I have worked with over the last three years). I've spoken with Lincoln about this and there are two JIRAs ( https://issues.jboss.org/browse/SEAMFORGE-280 and https://issues.jboss.org/browse/SEAMFORGE-279) to have Forge generate this via the JPA plugin or perhaps Seam Persistence plugin. Discuss. -- Jason Porter http://lightguard-jp.blogspot.com http://twitter.com/lightguardjp Software Engineer Open Source Advocate Author of Seam Catch - Next Generation Java Exception Handling PGP key id: 926CCFF5 PGP key available at: keyserver.net, pgp.mit.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110919/89283608/attachment.html From xsalefter at yahoo.com Tue Sep 20 03:47:35 2011 From: xsalefter at yahoo.com (xsalefter) Date: Tue, 20 Sep 2011 00:47:35 -0700 (PDT) Subject: [seam-dev] SAF (aka Entity Framework) idea in Seam 3 In-Reply-To: References: Message-ID: <1316504855.4917.YahooMailNeo@web160812.mail.bf1.yahoo.com> Hi all.. I know that I never involved on this mailing-list so much, nor contribute things to the community. But because I have an experience with seam 2 and used seam gen extensively (and thus use seam's EntityQuery and EntityHome a lot) in some project, I have a thought about this. EntityQuery anda EntityHome is perfect in case you want to creating an simple CRUD application. Well, not as simple as is. I ever involved in a project with 40 more database tables with quite extensive financial transaction, and use an EntityQuery and EntityHome a lot. The main problem with these classes is that, It's hard (well, at least, for me) to make your code consistent.?What I mean by consistent is that, it is confusing to determine whether the classes is a part of your UI layer, or service/domain-model layer. Or where you add new functionality to satisfied a specifics requirement. The study case is maybe like this: Let say that we have a module named accounting transaction. And we want to create a input transaction page, thus we have a TransactionHome.xhtml backed with TransactionHome.java. Now the problems occurs. Because we want a chart of account list in the TransactionHome.xhtml, where is better place to put the logic to call the chart of account list? In the TransactionHome.java, or ChartOfAccountList.java?? In the beginning I put it in the ChartOfAccountList.java, and start to realize that seam's EntityList is specialized class to create a page with contains a rich datatable search option, paging, and sorting. It will be strange to the code if try to add non searching/sorting/paging on it. Then I think to back to good-old DAO object, and thinking again about the backing bean: I need to call/inject the DAO in some backing-bean, but where? TransactionHome.java? Well, TransactionHome already have getEntityManager(), so if I put the DAO in the ***Home, it will looks overlapping, and bit odd. Then when I thinking again about the EntityHome, I'm not sure whether I need to treat this class as UI or Service class.?You see, this is simple case study (don't get me start with "The list of Chart Of Account need to aligning with the logged in user's departments and user's role. And make sure that an user with level A have a $xxx limit transaction, where level B have $xxx limit").? My purpose is not to blame something or rant to something, but instead, give an idea whether is it good enough to leave ***Home and ***Query concept, and back to at least? Entity-Service-BackingBean-View model? It looks "verbose", I know, but at least we have a "service" layer, which is "centralized" place to write a business logic in our application. We could treat the "service" as just-plain-stateless classes (EJB 3.1 classes or only seam-persistence classes with minimal coupled with the front-end layer), and put the richness of Weld and Seam 3 maybe in the UI and view layer. Well, I know this is personal view, from me, and my experience. Thus, just ignore if in case this is annoying and not fit with your purpose/target. Thanks, xsalefter > >The Home ideahttps://github.com/seam/seam-example-confbuzz/blob/develop/src/main/java/seam/example/confbuzz/ConferenceInstance.java > > > >The Query idea >https://github.com/seam/seam-example-confbuzz/blob/develop/src/main/java/seam/example/confbuzz/TodaysConferencesQuery.java > > >The main thing that I would change with the Query class above is to use named queries, thus espousing the generally accepted best practice in default applications. I understand this doesn't fill all the gaps of the older SAF from Seam 2, but I think it works for the majority of cases, and it also helps people understand the best way to do things instead of relying on the magic of SAF from Seam 2 (which I have found to be a major problem in projects and teams I have worked with over the last three years). > > >I've spoken with Lincoln about this and there are two JIRAs (https://issues.jboss.org/browse/SEAMFORGE-280?and?https://issues.jboss.org/browse/SEAMFORGE-279) to have Forge generate this via the JPA plugin or perhaps Seam Persistence plugin. > > >Discuss. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110920/995dd6df/attachment-0001.html From jharting at redhat.com Tue Sep 20 04:09:33 2011 From: jharting at redhat.com (Jozef Hartinger) Date: Tue, 20 Sep 2011 10:09:33 +0200 Subject: [seam-dev] Testsuite discussion notes In-Reply-To: <255062B5-702B-4721-946A-DA68413BC689@gmail.com> References: <4E77460E.5070304@redhat.com> <4E77C007.5070505@redhat.com> <255062B5-702B-4721-946A-DA68413BC689@gmail.com> Message-ID: <4E784A3D.7000402@redhat.com> Marek is working on integration tests while me and Tomas are working on functional tests. On 09/20/2011 12:24 AM, Jason Porter wrote: > No, we didn't assign it to anyone. > > Sent from my iPhone > > On Sep 19, 2011, at 16:19, Shane Bryzak wrote: > >> Was it decided who would take care of the testsuite restructure? I must >> admit I wasn't paying much attention during this discussion ;) >> >> On 19/09/11 23:39, Jozef Hartinger wrote: >>> INTEGRATION TESTS >>> >>> Structure: >>> >>> - api >>> - impl >>> - testsuite / src / test / java >>> >>> Container-specific issues >>> - there will be a BaseDeploymentFactory that creates base deployment >>> based on a system property (arquillian container name) >>> - there will be no common package scheme for now >>> >>> Default profile >>> - weld embedded >>> - skipped tests if weld embedded does not make sense in the context of >>> the module >>> >>> >>> FUNCTIONAL TESTS >>> - m4 will be used to generate pom files from our templates (stored in >>> Seam QA github) >>> >> _______________________________________________ >> seam-dev mailing list >> seam-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/seam-dev From sbryzak at redhat.com Tue Sep 20 04:51:47 2011 From: sbryzak at redhat.com (Shane Bryzak) Date: Tue, 20 Sep 2011 18:51:47 +1000 Subject: [seam-dev] Testsuite discussion notes In-Reply-To: <4E784A3D.7000402@redhat.com> References: <4E77460E.5070304@redhat.com> <4E77C007.5070505@redhat.com> <255062B5-702B-4721-946A-DA68413BC689@gmail.com> <4E784A3D.7000402@redhat.com> Message-ID: <4E785423.7060404@redhat.com> Can we please make it a priority to get the Solder testsuite updated to the new structure and all the tests passing? Once this is done, the rest of the team can help out by updating the other modules to follow the same configuration. Shane On 20/09/11 18:09, Jozef Hartinger wrote: > Marek is working on integration tests while me and Tomas are working > on functional tests. > > On 09/20/2011 12:24 AM, Jason Porter wrote: >> No, we didn't assign it to anyone. >> >> Sent from my iPhone >> >> On Sep 19, 2011, at 16:19, Shane Bryzak wrote: >> >>> Was it decided who would take care of the testsuite restructure? I >>> must >>> admit I wasn't paying much attention during this discussion ;) >>> >>> On 19/09/11 23:39, Jozef Hartinger wrote: >>>> INTEGRATION TESTS >>>> >>>> Structure: >>>> >>>> - api >>>> - impl >>>> - testsuite / src / test / java >>>> >>>> Container-specific issues >>>> - there will be a BaseDeploymentFactory that creates base deployment >>>> based on a system property (arquillian container name) >>>> - there will be no common package scheme for now >>>> >>>> Default profile >>>> - weld embedded >>>> - skipped tests if weld embedded does not make sense in the context of >>>> the module >>>> >>>> >>>> FUNCTIONAL TESTS >>>> - m4 will be used to generate pom files from our templates (stored in >>>> Seam QA github) >>>> >>> _______________________________________________ >>> seam-dev mailing list >>> seam-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/seam-dev > From oskutka at redhat.com Tue Sep 20 09:47:03 2011 From: oskutka at redhat.com (=?utf-8?B?T25kxZllaiBTa3V0a2E=?=) Date: Tue, 20 Sep 2011 15:47:03 +0200 Subject: [seam-dev] Testsuite discussion notes In-Reply-To: <4E785423.7060404@redhat.com> References: <4E77460E.5070304@redhat.com> <4E77C007.5070505@redhat.com> <255062B5-702B-4721-946A-DA68413BC689@gmail.com> <4E784A3D.7000402@redhat.com> <4E785423.7060404@redhat.com> Message-ID: On Tue, 20 Sep 2011 10:51:47 +0200, Shane Bryzak wrote: > Can we please make it a priority to get the Solder testsuite updated to > the new structure and all the tests passing? Once this is done, the > rest of the team can help out by updating the other modules to follow > the same configuration. Sure. Marek, can you please focus on this? Thanks, Ondra From dan.j.allen at gmail.com Tue Sep 20 13:41:17 2011 From: dan.j.allen at gmail.com (Dan Allen) Date: Tue, 20 Sep 2011 13:41:17 -0400 Subject: [seam-dev] Meeting 2011-09-21 In-Reply-To: References: Message-ID: Additional items (perhaps sub-points of the community update): - strategy for kickstarting the migration guide effort - gradle prototyping & future plans -Dan On Mon, Sep 19, 2011 at 23:45, Jason Porter wrote: > > - Community Update about F2F Meeting > - Logging > - Testing Structure Update > - Examples > - 3.1.0.Beta3 > > > -- > Jason Porter > http://lightguard-jp.blogspot.com > http://twitter.com/lightguardjp > > Software Engineer > Open Source Advocate > Author of Seam Catch - Next Generation Java Exception Handling > > PGP key id: 926CCFF5 > PGP key available at: keyserver.net, pgp.mit.edu > > _______________________________________________ > seam-dev mailing list > seam-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/seam-dev > > -- Dan Allen Principal Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://www.google.com/profiles/dan.j.allen#about http://mojavelinux.com http://mojavelinux.com/seaminaction -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110920/bab0f7de/attachment.html From dan.j.allen at gmail.com Tue Sep 20 13:54:44 2011 From: dan.j.allen at gmail.com (Dan Allen) Date: Tue, 20 Sep 2011 13:54:44 -0400 Subject: [seam-dev] SAF (aka Entity Framework) idea in Seam 3 In-Reply-To: <1316504855.4917.YahooMailNeo@web160812.mail.bf1.yahoo.com> References: <1316504855.4917.YahooMailNeo@web160812.mail.bf1.yahoo.com> Message-ID: xsalefter, Thanks, this is valuable feedback and certainly usage patterns to keep in mind when designing the new iteration of these components. In numerous conversations that I've had with developers familiar with Seam 2, the common theme is that *Home and *Query components are not the ideal design. They lead developers into tight corners exactly in the way you are describing. Thus, we likely won't be following the status quo (though, it's not too big of an effort to port the existing functionality to CDI, so if someone would like to work on that, we won't discourage it). Instead, I think these components should provide boilerplate functionality, yet be flexible and easily tuned to the needs of the developer. I think you're right in that going back to a generic DAO design might be a more reasonable strategy. I don't think developer expect to code entirely in XML, they simply don't want to type the same boilerplate over and over again. I like Jason's idea of using named queries. Keep in mind we could read the queries as a suggestion and produce more sophisticated queries in an extension...so we aren't limited to what named queries support today. We've also been considering supporting finder "missing" methods that build a query from the name of the method (or a set of annotations on the method). Whatever we decide, this should be the framework code that forge uses when generating CRUD applications. Let's make it something that we aren't ashamed of having in our projects ;) -Dan p.s. I also recommend renaming SAF, because it's a really confusing term. Something like "entity framework" is far more sensible. On Tue, Sep 20, 2011 at 03:47, xsalefter wrote: > Hi all.. I know that I never involved on this mailing-list so much, nor > contribute things to the community. But because I have an experience with > seam 2 and used seam gen extensively (and thus use seam's EntityQuery and > EntityHome a lot) in some project, I have a thought about this. > > EntityQuery anda EntityHome is perfect in case you want to creating an > simple CRUD application. Well, not as simple as is. I ever involved in a > project with 40 more database tables with quite extensive financial > transaction, and use an EntityQuery and EntityHome a lot. The main problem > with these classes is that, It's hard (well, at least, for me) to make your > code consistent. What I mean by consistent is that, it is confusing to > determine whether the classes is a part of your UI layer, or > service/domain-model layer. Or where you add new functionality to satisfied > a specifics requirement. The study case is maybe like this: > > Let say that we have a module named accounting transaction. And we want to > create a input transaction page, thus we have a TransactionHome.xhtml backed > with TransactionHome.java. Now the problems occurs. Because we want a chart > of account list in the TransactionHome.xhtml, where is better place to put > the logic to call the chart of account list? In the TransactionHome.java, or > ChartOfAccountList.java? > > In the beginning I put it in the ChartOfAccountList.java, and start to > realize that seam's EntityList is specialized class to create a page with > contains a rich datatable search option, paging, and sorting. It will be > strange to the code if try to add non searching/sorting/paging on it. Then I > think to back to good-old DAO object, and thinking again about the backing > bean: I need to call/inject the DAO in some backing-bean, but where? > TransactionHome.java? Well, TransactionHome already have getEntityManager(), > so if I put the DAO in the ***Home, it will looks overlapping, and bit odd. > Then when I thinking again about the EntityHome, I'm not sure whether I need > to treat this class as UI or Service class. You see, this is simple case > study (don't get me start with "The list of Chart Of Account need to > aligning with the logged in user's departments and user's role. And make > sure that an user with level A have a $xxx limit transaction, where level B > have $xxx limit"). > > My purpose is not to blame something or rant to something, but instead, > give an idea whether is it good enough to leave ***Home and ***Query > concept, and back to at least > Entity-Service-BackingBean-View model? It looks "verbose", I know, but at > least we have a "service" layer, which is "centralized" place to write a > business logic in our application. We could treat the "service" as > just-plain-stateless classes (EJB 3.1 classes or only seam-persistence > classes with minimal coupled with the front-end layer), and put the richness > of Weld and Seam 3 maybe in the UI and view layer. > > Well, I know this is personal view, from me, and my experience. Thus, just > ignore if in case this is annoying and not fit with your purpose/target. > > Thanks, > xsalefter > > * > * > The Home idea > > https://github.com/seam/seam-example-confbuzz/blob/develop/src/main/java/seam/example/confbuzz/ConferenceInstance.java > > The Query idea > > https://github.com/seam/seam-example-confbuzz/blob/develop/src/main/java/seam/example/confbuzz/TodaysConferencesQuery.java > > The main thing that I would change with the Query class above is to use > named queries, thus espousing the generally accepted best practice in > default applications. I understand this doesn't fill all the gaps of the > older SAF from Seam 2, but I think it works for the majority of cases, and > it also helps people understand the best way to do things instead of relying > on the magic of SAF from Seam 2 (which I have found to be a major problem in > projects and teams I have worked with over the last three years). > > I've spoken with Lincoln about this and there are two JIRAs ( > https://issues.jboss.org/browse/SEAMFORGE-280 and > https://issues.jboss.org/browse/SEAMFORGE-279) to have Forge generate this > via the JPA plugin or perhaps Seam Persistence plugin. > > Discuss. > > > _______________________________________________ > seam-dev mailing list > seam-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/seam-dev > > -- Dan Allen Principal Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://www.google.com/profiles/dan.j.allen#about http://mojavelinux.com http://mojavelinux.com/seaminaction -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110920/6d932a51/attachment.html From dan.j.allen at gmail.com Tue Sep 20 13:55:09 2011 From: dan.j.allen at gmail.com (Dan Allen) Date: Tue, 20 Sep 2011 13:55:09 -0400 Subject: [seam-dev] SAF (aka Entity Framework) idea in Seam 3 In-Reply-To: References: <1316504855.4917.YahooMailNeo@web160812.mail.bf1.yahoo.com> Message-ID: Cross-posting to forge dev. On Tue, Sep 20, 2011 at 13:54, Dan Allen wrote: > xsalefter, > > Thanks, this is valuable feedback and certainly usage patterns to keep in > mind when designing the new iteration of these components. > > In numerous conversations that I've had with developers familiar with Seam > 2, the common theme is that *Home and *Query components are not the ideal > design. They lead developers into tight corners exactly in the way you are > describing. Thus, we likely won't be following the status quo (though, it's > not too big of an effort to port the existing functionality to CDI, so if > someone would like to work on that, we won't discourage it). > > Instead, I think these components should provide boilerplate functionality, > yet be flexible and easily tuned to the needs of the developer. I think > you're right in that going back to a generic DAO design might be a more > reasonable strategy. I don't think developer expect to code entirely in XML, > they simply don't want to type the same boilerplate over and over again. > > I like Jason's idea of using named queries. Keep in mind we could read the > queries as a suggestion and produce more sophisticated queries in an > extension...so we aren't limited to what named queries support today. We've > also been considering supporting finder "missing" methods that build a query > from the name of the method (or a set of annotations on the method). > > Whatever we decide, this should be the framework code that forge uses when > generating CRUD applications. Let's make it something that we aren't ashamed > of having in our projects ;) > > -Dan > > p.s. I also recommend renaming SAF, because it's a really confusing term. > Something like "entity framework" is far more sensible. > > On Tue, Sep 20, 2011 at 03:47, xsalefter wrote: > >> Hi all.. I know that I never involved on this mailing-list so much, nor >> contribute things to the community. But because I have an experience with >> seam 2 and used seam gen extensively (and thus use seam's EntityQuery and >> EntityHome a lot) in some project, I have a thought about this. >> >> EntityQuery anda EntityHome is perfect in case you want to creating an >> simple CRUD application. Well, not as simple as is. I ever involved in a >> project with 40 more database tables with quite extensive financial >> transaction, and use an EntityQuery and EntityHome a lot. The main problem >> with these classes is that, It's hard (well, at least, for me) to make your >> code consistent. What I mean by consistent is that, it is confusing to >> determine whether the classes is a part of your UI layer, or >> service/domain-model layer. Or where you add new functionality to satisfied >> a specifics requirement. The study case is maybe like this: >> >> Let say that we have a module named accounting transaction. And we want to >> create a input transaction page, thus we have a TransactionHome.xhtml backed >> with TransactionHome.java. Now the problems occurs. Because we want a chart >> of account list in the TransactionHome.xhtml, where is better place to put >> the logic to call the chart of account list? In the TransactionHome.java, or >> ChartOfAccountList.java? >> >> In the beginning I put it in the ChartOfAccountList.java, and start to >> realize that seam's EntityList is specialized class to create a page with >> contains a rich datatable search option, paging, and sorting. It will be >> strange to the code if try to add non searching/sorting/paging on it. Then I >> think to back to good-old DAO object, and thinking again about the backing >> bean: I need to call/inject the DAO in some backing-bean, but where? >> TransactionHome.java? Well, TransactionHome already have getEntityManager(), >> so if I put the DAO in the ***Home, it will looks overlapping, and bit odd. >> Then when I thinking again about the EntityHome, I'm not sure whether I need >> to treat this class as UI or Service class. You see, this is simple case >> study (don't get me start with "The list of Chart Of Account need to >> aligning with the logged in user's departments and user's role. And make >> sure that an user with level A have a $xxx limit transaction, where level B >> have $xxx limit"). >> >> My purpose is not to blame something or rant to something, but instead, >> give an idea whether is it good enough to leave ***Home and ***Query >> concept, and back to at least >> Entity-Service-BackingBean-View model? It looks "verbose", I know, but at >> least we have a "service" layer, which is "centralized" place to write a >> business logic in our application. We could treat the "service" as >> just-plain-stateless classes (EJB 3.1 classes or only seam-persistence >> classes with minimal coupled with the front-end layer), and put the richness >> of Weld and Seam 3 maybe in the UI and view layer. >> >> Well, I know this is personal view, from me, and my experience. Thus, just >> ignore if in case this is annoying and not fit with your purpose/target. >> >> Thanks, >> xsalefter >> >> * >> * >> The Home idea >> >> https://github.com/seam/seam-example-confbuzz/blob/develop/src/main/java/seam/example/confbuzz/ConferenceInstance.java >> >> The Query idea >> >> https://github.com/seam/seam-example-confbuzz/blob/develop/src/main/java/seam/example/confbuzz/TodaysConferencesQuery.java >> >> The main thing that I would change with the Query class above is to use >> named queries, thus espousing the generally accepted best practice in >> default applications. I understand this doesn't fill all the gaps of the >> older SAF from Seam 2, but I think it works for the majority of cases, and >> it also helps people understand the best way to do things instead of relying >> on the magic of SAF from Seam 2 (which I have found to be a major problem in >> projects and teams I have worked with over the last three years). >> >> I've spoken with Lincoln about this and there are two JIRAs ( >> https://issues.jboss.org/browse/SEAMFORGE-280 and >> https://issues.jboss.org/browse/SEAMFORGE-279) to have Forge generate >> this via the JPA plugin or perhaps Seam Persistence plugin. >> >> Discuss. >> >> >> _______________________________________________ >> seam-dev mailing list >> seam-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/seam-dev >> >> > > > -- > Dan Allen > Principal Software Engineer, Red Hat | Author of Seam in Action > Registered Linux User #231597 > > http://www.google.com/profiles/dan.j.allen#about > http://mojavelinux.com > http://mojavelinux.com/seaminaction > > -- Dan Allen Principal Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://www.google.com/profiles/dan.j.allen#about http://mojavelinux.com http://mojavelinux.com/seaminaction -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110920/4f9262ed/attachment-0001.html From maschmid at redhat.com Tue Sep 20 14:29:06 2011 From: maschmid at redhat.com (Marek Schmidt) Date: Tue, 20 Sep 2011 20:29:06 +0200 Subject: [seam-dev] Testsuite discussion notes In-Reply-To: References: <4E77460E.5070304@redhat.com> <4E77C007.5070505@redhat.com> <255062B5-702B-4721-946A-DA68413BC689@gmail.com> <4E784A3D.7000402@redhat.com> <4E785423.7060404@redhat.com> Message-ID: <4E78DB72.4020106@redhat.com> On 09/20/2011 03:47 PM, Ond?ej Skutka wrote: > On Tue, 20 Sep 2011 10:51:47 +0200, Shane Bryzak > wrote: > >> Can we please make it a priority to get the Solder testsuite updated to >> the new structure and all the tests passing? Once this is done, the >> rest of the team can help out by updating the other modules to follow >> the same configuration. > > Sure. Marek, can you please focus on this? Sure, I am on it. Current progress in https://github.com/maschmid/solder/tree/testsuite-update-2 > > Thanks, > Ondra > From sbryzak at redhat.com Tue Sep 20 14:30:58 2011 From: sbryzak at redhat.com (Shane Bryzak) Date: Wed, 21 Sep 2011 04:30:58 +1000 Subject: [seam-dev] Testsuite discussion notes In-Reply-To: <4E78DB72.4020106@redhat.com> References: <4E77460E.5070304@redhat.com> <4E77C007.5070505@redhat.com> <255062B5-702B-4721-946A-DA68413BC689@gmail.com> <4E784A3D.7000402@redhat.com> <4E785423.7060404@redhat.com> <4E78DB72.4020106@redhat.com> Message-ID: <4E78DBE2.1040307@redhat.com> Thanks Marek. Just a heads up - the Catch, Config and Servlet modules are going to be merged with Solder as sub-modules shortly. Would you like me to wait until the testsuite is stable before I move the tests over for these? Shane On 21/09/11 04:29, Marek Schmidt wrote: > On 09/20/2011 03:47 PM, Ond?ej Skutka wrote: >> On Tue, 20 Sep 2011 10:51:47 +0200, Shane Bryzak >> wrote: >> >>> Can we please make it a priority to get the Solder testsuite updated to >>> the new structure and all the tests passing? Once this is done, the >>> rest of the team can help out by updating the other modules to follow >>> the same configuration. >> >> Sure. Marek, can you please focus on this? > > Sure, I am on it. > > Current progress in > > https://github.com/maschmid/solder/tree/testsuite-update-2 > >> >> Thanks, >> Ondra >> > From joserodolfo.freitas at gmail.com Tue Sep 20 15:36:21 2011 From: joserodolfo.freitas at gmail.com (=?ISO-8859-1?Q?Jos=E9_Rodolfo_Freitas?=) Date: Tue, 20 Sep 2011 16:36:21 -0300 Subject: [seam-dev] SAF (aka Entity Framework) idea in Seam 3 In-Reply-To: References: <1316504855.4917.YahooMailNeo@web160812.mail.bf1.yahoo.com> Message-ID: What I like most in CDI and Seam3 is that it's very easy to keep things simple and that's something I strongly advocate. For me when you have a lot of layers that just delegate calls, something is wrong, and you're probably writing that classes(layers) just to satisfy an unnecessary pattern. If we create a Seam Application Framework like that for Seam3, I'm afraid we're going to fall in that hole. IMHO we should avoid that. JEE6 carries the design by simplicity flag and I think we should support that. I know that a lot of people want to have a happy and safe way to achieve a simple CRUD. But I think we should encourage them to enjoy the CDI programming model and use layers only when they're needed to be used. Of course there're still boilerplate code, but I think it's minimal (compared to the JEE generations before), and that's something forge can create without the need to satisfy a "framework". Yes, I admitedly am afraid of that word. On Tue, Sep 20, 2011 at 2:54 PM, Dan Allen wrote: > xsalefter, > > Thanks, this is valuable feedback and certainly usage patterns to keep in > mind when designing the new iteration of these components. > > In numerous conversations that I've had with developers familiar with Seam > 2, the common theme is that *Home and *Query components are not the ideal > design. They lead developers into tight corners exactly in the way you are > describing. Thus, we likely won't be following the status quo (though, it's > not too big of an effort to port the existing functionality to CDI, so if > someone would like to work on that, we won't discourage it). > > Instead, I think these components should provide boilerplate functionality, > yet be flexible and easily tuned to the needs of the developer. I think > you're right in that going back to a generic DAO design might be a more > reasonable strategy. I don't think developer expect to code entirely in XML, > they simply don't want to type the same boilerplate over and over again. > > I like Jason's idea of using named queries. Keep in mind we could read the > queries as a suggestion and produce more sophisticated queries in an > extension...so we aren't limited to what named queries support today. We've > also been considering supporting finder "missing" methods that build a query > from the name of the method (or a set of annotations on the method). > > Whatever we decide, this should be the framework code that forge uses when > generating CRUD applications. Let's make it something that we aren't ashamed > of having in our projects ;) > > -Dan > > p.s. I also recommend renaming SAF, because it's a really confusing term. > Something like "entity framework" is far more sensible. > > On Tue, Sep 20, 2011 at 03:47, xsalefter wrote: > >> Hi all.. I know that I never involved on this mailing-list so much, nor >> contribute things to the community. But because I have an experience with >> seam 2 and used seam gen extensively (and thus use seam's EntityQuery and >> EntityHome a lot) in some project, I have a thought about this. >> >> EntityQuery anda EntityHome is perfect in case you want to creating an >> simple CRUD application. Well, not as simple as is. I ever involved in a >> project with 40 more database tables with quite extensive financial >> transaction, and use an EntityQuery and EntityHome a lot. The main problem >> with these classes is that, It's hard (well, at least, for me) to make your >> code consistent. What I mean by consistent is that, it is confusing to >> determine whether the classes is a part of your UI layer, or >> service/domain-model layer. Or where you add new functionality to satisfied >> a specifics requirement. The study case is maybe like this: >> >> Let say that we have a module named accounting transaction. And we want to >> create a input transaction page, thus we have a TransactionHome.xhtml backed >> with TransactionHome.java. Now the problems occurs. Because we want a chart >> of account list in the TransactionHome.xhtml, where is better place to put >> the logic to call the chart of account list? In the TransactionHome.java, or >> ChartOfAccountList.java? >> >> In the beginning I put it in the ChartOfAccountList.java, and start to >> realize that seam's EntityList is specialized class to create a page with >> contains a rich datatable search option, paging, and sorting. It will be >> strange to the code if try to add non searching/sorting/paging on it. Then I >> think to back to good-old DAO object, and thinking again about the backing >> bean: I need to call/inject the DAO in some backing-bean, but where? >> TransactionHome.java? Well, TransactionHome already have getEntityManager(), >> so if I put the DAO in the ***Home, it will looks overlapping, and bit odd. >> Then when I thinking again about the EntityHome, I'm not sure whether I need >> to treat this class as UI or Service class. You see, this is simple case >> study (don't get me start with "The list of Chart Of Account need to >> aligning with the logged in user's departments and user's role. And make >> sure that an user with level A have a $xxx limit transaction, where level B >> have $xxx limit"). >> >> My purpose is not to blame something or rant to something, but instead, >> give an idea whether is it good enough to leave ***Home and ***Query >> concept, and back to at least >> Entity-Service-BackingBean-View model? It looks "verbose", I know, but at >> least we have a "service" layer, which is "centralized" place to write a >> business logic in our application. We could treat the "service" as >> just-plain-stateless classes (EJB 3.1 classes or only seam-persistence >> classes with minimal coupled with the front-end layer), and put the richness >> of Weld and Seam 3 maybe in the UI and view layer. >> >> Well, I know this is personal view, from me, and my experience. Thus, just >> ignore if in case this is annoying and not fit with your purpose/target. >> >> Thanks, >> xsalefter >> >> * >> * >> The Home idea >> >> https://github.com/seam/seam-example-confbuzz/blob/develop/src/main/java/seam/example/confbuzz/ConferenceInstance.java >> >> The Query idea >> >> https://github.com/seam/seam-example-confbuzz/blob/develop/src/main/java/seam/example/confbuzz/TodaysConferencesQuery.java >> >> The main thing that I would change with the Query class above is to use >> named queries, thus espousing the generally accepted best practice in >> default applications. I understand this doesn't fill all the gaps of the >> older SAF from Seam 2, but I think it works for the majority of cases, and >> it also helps people understand the best way to do things instead of relying >> on the magic of SAF from Seam 2 (which I have found to be a major problem in >> projects and teams I have worked with over the last three years). >> >> I've spoken with Lincoln about this and there are two JIRAs ( >> https://issues.jboss.org/browse/SEAMFORGE-280 and >> https://issues.jboss.org/browse/SEAMFORGE-279) to have Forge generate >> this via the JPA plugin or perhaps Seam Persistence plugin. >> >> Discuss. >> >> >> _______________________________________________ >> seam-dev mailing list >> seam-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/seam-dev >> >> > > > -- > Dan Allen > Principal Software Engineer, Red Hat | Author of Seam in Action > Registered Linux User #231597 > > http://www.google.com/profiles/dan.j.allen#about > http://mojavelinux.com > http://mojavelinux.com/seaminaction > > > _______________________________________________ > seam-dev mailing list > seam-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/seam-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110920/4b1044bb/attachment.html From joserodolfo.freitas at gmail.com Tue Sep 20 15:39:09 2011 From: joserodolfo.freitas at gmail.com (=?ISO-8859-1?Q?Jos=E9_Rodolfo_Freitas?=) Date: Tue, 20 Sep 2011 16:39:09 -0300 Subject: [seam-dev] SAF (aka Entity Framework) idea in Seam 3 In-Reply-To: References: <1316504855.4917.YahooMailNeo@web160812.mail.bf1.yahoo.com> Message-ID: p.s.: I know that's a really polemic opinion. ;) On Tue, Sep 20, 2011 at 4:36 PM, Jos? Rodolfo Freitas < joserodolfo.freitas at gmail.com> wrote: > What I like most in CDI and Seam3 is that it's very easy to keep things > simple and that's something I strongly advocate. > > For me when you have a lot of layers that just delegate calls, something is > wrong, and you're probably writing that classes(layers) just to satisfy an > unnecessary pattern. If we create a Seam Application Framework like that for > Seam3, I'm afraid we're going to fall in that hole. IMHO we should avoid > that. JEE6 carries the design by simplicity flag and I think we should > support that. > > I know that a lot of people want to have a happy and safe way to achieve a > simple CRUD. But I think we should encourage them to enjoy the CDI > programming model and use layers only when they're needed to be used. > > Of course there're still boilerplate code, but I think it's minimal > (compared to the JEE generations before), and that's something forge can > create without the need to satisfy a "framework". Yes, I admitedly am afraid > of that word. > > > > On Tue, Sep 20, 2011 at 2:54 PM, Dan Allen wrote: > >> xsalefter, >> >> Thanks, this is valuable feedback and certainly usage patterns to keep in >> mind when designing the new iteration of these components. >> >> In numerous conversations that I've had with developers familiar with Seam >> 2, the common theme is that *Home and *Query components are not the ideal >> design. They lead developers into tight corners exactly in the way you are >> describing. Thus, we likely won't be following the status quo (though, it's >> not too big of an effort to port the existing functionality to CDI, so if >> someone would like to work on that, we won't discourage it). >> >> Instead, I think these components should provide boilerplate >> functionality, yet be flexible and easily tuned to the needs of the >> developer. I think you're right in that going back to a generic DAO design >> might be a more reasonable strategy. I don't think developer expect to code >> entirely in XML, they simply don't want to type the same boilerplate over >> and over again. >> >> I like Jason's idea of using named queries. Keep in mind we could read the >> queries as a suggestion and produce more sophisticated queries in an >> extension...so we aren't limited to what named queries support today. We've >> also been considering supporting finder "missing" methods that build a query >> from the name of the method (or a set of annotations on the method). >> >> Whatever we decide, this should be the framework code that forge uses when >> generating CRUD applications. Let's make it something that we aren't ashamed >> of having in our projects ;) >> >> -Dan >> >> p.s. I also recommend renaming SAF, because it's a really confusing term. >> Something like "entity framework" is far more sensible. >> >> On Tue, Sep 20, 2011 at 03:47, xsalefter wrote: >> >>> Hi all.. I know that I never involved on this mailing-list so much, nor >>> contribute things to the community. But because I have an experience with >>> seam 2 and used seam gen extensively (and thus use seam's EntityQuery and >>> EntityHome a lot) in some project, I have a thought about this. >>> >>> EntityQuery anda EntityHome is perfect in case you want to creating an >>> simple CRUD application. Well, not as simple as is. I ever involved in a >>> project with 40 more database tables with quite extensive financial >>> transaction, and use an EntityQuery and EntityHome a lot. The main problem >>> with these classes is that, It's hard (well, at least, for me) to make your >>> code consistent. What I mean by consistent is that, it is confusing to >>> determine whether the classes is a part of your UI layer, or >>> service/domain-model layer. Or where you add new functionality to satisfied >>> a specifics requirement. The study case is maybe like this: >>> >>> Let say that we have a module named accounting transaction. And we want >>> to create a input transaction page, thus we have a TransactionHome.xhtml >>> backed with TransactionHome.java. Now the problems occurs. Because we want a >>> chart of account list in the TransactionHome.xhtml, where is better place to >>> put the logic to call the chart of account list? In the >>> TransactionHome.java, or ChartOfAccountList.java? >>> >>> In the beginning I put it in the ChartOfAccountList.java, and start to >>> realize that seam's EntityList is specialized class to create a page with >>> contains a rich datatable search option, paging, and sorting. It will be >>> strange to the code if try to add non searching/sorting/paging on it. Then I >>> think to back to good-old DAO object, and thinking again about the backing >>> bean: I need to call/inject the DAO in some backing-bean, but where? >>> TransactionHome.java? Well, TransactionHome already have getEntityManager(), >>> so if I put the DAO in the ***Home, it will looks overlapping, and bit odd. >>> Then when I thinking again about the EntityHome, I'm not sure whether I need >>> to treat this class as UI or Service class. You see, this is simple case >>> study (don't get me start with "The list of Chart Of Account need to >>> aligning with the logged in user's departments and user's role. And make >>> sure that an user with level A have a $xxx limit transaction, where level B >>> have $xxx limit"). >>> >>> My purpose is not to blame something or rant to something, but instead, >>> give an idea whether is it good enough to leave ***Home and ***Query >>> concept, and back to at least >>> Entity-Service-BackingBean-View model? It looks "verbose", I know, but at >>> least we have a "service" layer, which is "centralized" place to write a >>> business logic in our application. We could treat the "service" as >>> just-plain-stateless classes (EJB 3.1 classes or only seam-persistence >>> classes with minimal coupled with the front-end layer), and put the richness >>> of Weld and Seam 3 maybe in the UI and view layer. >>> >>> Well, I know this is personal view, from me, and my experience. Thus, >>> just ignore if in case this is annoying and not fit with your >>> purpose/target. >>> >>> Thanks, >>> xsalefter >>> >>> * >>> * >>> The Home idea >>> >>> https://github.com/seam/seam-example-confbuzz/blob/develop/src/main/java/seam/example/confbuzz/ConferenceInstance.java >>> >>> The Query idea >>> >>> https://github.com/seam/seam-example-confbuzz/blob/develop/src/main/java/seam/example/confbuzz/TodaysConferencesQuery.java >>> >>> The main thing that I would change with the Query class above is to use >>> named queries, thus espousing the generally accepted best practice in >>> default applications. I understand this doesn't fill all the gaps of the >>> older SAF from Seam 2, but I think it works for the majority of cases, and >>> it also helps people understand the best way to do things instead of relying >>> on the magic of SAF from Seam 2 (which I have found to be a major problem in >>> projects and teams I have worked with over the last three years). >>> >>> I've spoken with Lincoln about this and there are two JIRAs ( >>> https://issues.jboss.org/browse/SEAMFORGE-280 and >>> https://issues.jboss.org/browse/SEAMFORGE-279) to have Forge generate >>> this via the JPA plugin or perhaps Seam Persistence plugin. >>> >>> Discuss. >>> >>> >>> _______________________________________________ >>> seam-dev mailing list >>> seam-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/seam-dev >>> >>> >> >> >> -- >> Dan Allen >> Principal Software Engineer, Red Hat | Author of Seam in Action >> Registered Linux User #231597 >> >> http://www.google.com/profiles/dan.j.allen#about >> http://mojavelinux.com >> http://mojavelinux.com/seaminaction >> >> >> _______________________________________________ >> seam-dev mailing list >> seam-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/seam-dev >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110920/376f2a5d/attachment-0001.html From dan.j.allen at gmail.com Tue Sep 20 15:41:47 2011 From: dan.j.allen at gmail.com (Dan Allen) Date: Tue, 20 Sep 2011 15:41:47 -0400 Subject: [seam-dev] SAF (aka Entity Framework) idea in Seam 3 In-Reply-To: References: <1316504855.4917.YahooMailNeo@web160812.mail.bf1.yahoo.com> Message-ID: On Tue, Sep 20, 2011 at 15:36, Jos? Rodolfo Freitas < joserodolfo.freitas at gmail.com> wrote: > What I like most in CDI and Seam3 is that it's very easy to keep things > simple and that's something I strongly advocate. +1 > Of course there're still boilerplate code, but I think it's minimal > (compared to the JEE generations before), and that's something forge can > create without the need to satisfy a "framework". Yes, I admitedly am afraid > of that word. > That's fine, it doesn't have to be a framework. I do think there is room for having some common scaffolding, though. If we can do that by extending the programming model (annotations, generic beans or interfaces) so that it's declarative, that's probably ideal. I suggest that we brainstorm proposals using gists (http://gist.github.com). That will get the ball rolling. We can start with the idea Jason posted, or feel free to take a different approach. -Dan -- Dan Allen Principal Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://www.google.com/profiles/dan.j.allen#about http://mojavelinux.com http://mojavelinux.com/seaminaction -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110920/baf18b7a/attachment.html From dan.j.allen at gmail.com Tue Sep 20 15:45:22 2011 From: dan.j.allen at gmail.com (Dan Allen) Date: Tue, 20 Sep 2011 15:45:22 -0400 Subject: [seam-dev] SAF (aka Entity Framework) idea in Seam 3 In-Reply-To: References: <1316504855.4917.YahooMailNeo@web160812.mail.bf1.yahoo.com> Message-ID: On Tue, Sep 20, 2011 at 15:39, Jos? Rodolfo Freitas < joserodolfo.freitas at gmail.com> wrote: > p.s.: I know that's a really polemic opinion. ;) Let's turn it into requirements then: - developers should be able to develop a CRUD component without unnecessary boilerplate code - the developer should be able to easily build on the out-of-the-box functionality without the scaffolding code posing unnecessary restrictions - queries should be declarative (at least in the common cases) and managed centrally (or partitioned as needed) -Dan -- Dan Allen Principal Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://www.google.com/profiles/dan.j.allen#about http://mojavelinux.com http://mojavelinux.com/seaminaction -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110920/7077033e/attachment.html From dan.j.allen at gmail.com Tue Sep 20 15:48:00 2011 From: dan.j.allen at gmail.com (Dan Allen) Date: Tue, 20 Sep 2011 15:48:00 -0400 Subject: [seam-dev] SAF (aka Entity Framework) idea in Seam 3 In-Reply-To: References: <1316504855.4917.YahooMailNeo@web160812.mail.bf1.yahoo.com> Message-ID: On Tue, Sep 20, 2011 at 15:45, Dan Allen wrote: > On Tue, Sep 20, 2011 at 15:39, Jos? Rodolfo Freitas < > joserodolfo.freitas at gmail.com> wrote: > >> p.s.: I know that's a really polemic opinion. ;) > > > Let's turn it into requirements then: > > - developers should be able to develop a CRUD component without unnecessary > boilerplate code > - the developer should be able to easily build on the out-of-the-box > functionality without the scaffolding code posing unnecessary restrictions > - queries should be declarative (at least in the common cases) and managed > centrally (or partitioned as needed) > - the scaffolding code/components should be a natural fit with the CDI programming model -Dan -- Dan Allen Principal Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://www.google.com/profiles/dan.j.allen#about http://mojavelinux.com http://mojavelinux.com/seaminaction -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110920/1f2e68d8/attachment.html From mariusb at redhat.com Tue Sep 20 15:54:10 2011 From: mariusb at redhat.com (Marius Bogoevici) Date: Tue, 20 Sep 2011 15:54:10 -0400 Subject: [seam-dev] SAF (aka Entity Framework) idea in Seam 3 In-Reply-To: References: <1316504855.4917.YahooMailNeo@web160812.mail.bf1.yahoo.com> Message-ID: <1316548452.1953.13.camel@localhost.localdomain> Dan, Something worth looking at would be: http://static.springsource.org/spring-data/data-jpa/docs/current/reference/html/ There are a few ideas which one may want to borrow, and I believe that a CDI implementation could make things even easier. On Tue, 2011-09-20 at 15:48 -0400, Dan Allen wrote: > On Tue, Sep 20, 2011 at 15:45, Dan Allen > wrote: > On Tue, Sep 20, 2011 at 15:39, Jos? Rodolfo Freitas > wrote: > > p.s.: I know that's a really polemic opinion. ;) > > > Let's turn it into requirements then: > > > - developers should be able to develop a CRUD component > without unnecessary boilerplate code > - the developer should be able to easily build on the > out-of-the-box functionality without the scaffolding code > posing unnecessary restrictions > - queries should be declarative (at least in the common cases) > and managed centrally (or partitioned as needed) > > > - the scaffolding code/components should be a natural fit with the CDI > programming model > > > -Dan > > -- > Dan Allen > Principal Software Engineer, Red Hat | Author of Seam in Action > Registered Linux User #231597 > > http://www.google.com/profiles/dan.j.allen#about > http://mojavelinux.com > http://mojavelinux.com/seaminaction > > > _______________________________________________ > seam-dev mailing list > seam-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/seam-dev From joserodolfo.freitas at gmail.com Tue Sep 20 16:00:59 2011 From: joserodolfo.freitas at gmail.com (=?ISO-8859-1?Q?Jos=E9_Rodolfo_Freitas?=) Date: Tue, 20 Sep 2011 17:00:59 -0300 Subject: [seam-dev] SAF (aka Entity Framework) idea in Seam 3 In-Reply-To: References: <1316504855.4917.YahooMailNeo@web160812.mail.bf1.yahoo.com> Message-ID: Yeah, I agree that being declarative is the ideal. let's say no to inheritance with generics! hehehe. On Tue, Sep 20, 2011 at 4:41 PM, Dan Allen wrote: > On Tue, Sep 20, 2011 at 15:36, Jos? Rodolfo Freitas < > joserodolfo.freitas at gmail.com> wrote: > >> What I like most in CDI and Seam3 is that it's very easy to keep things >> simple and that's something I strongly advocate. > > > +1 > > >> Of course there're still boilerplate code, but I think it's minimal >> (compared to the JEE generations before), and that's something forge can >> create without the need to satisfy a "framework". Yes, I admitedly am afraid >> of that word. >> > > That's fine, it doesn't have to be a framework. I do think there is room > for having some common scaffolding, though. If we can do that by extending > the programming model (annotations, generic beans or interfaces) so that > it's declarative, that's probably ideal. > > I suggest that we brainstorm proposals using gists (http://gist.github.com). > That will get the ball rolling. We can start with the idea Jason posted, or > feel free to take a different approach. > > -Dan > > -- > Dan Allen > Principal Software Engineer, Red Hat | Author of Seam in Action > Registered Linux User #231597 > > http://www.google.com/profiles/dan.j.allen#about > http://mojavelinux.com > http://mojavelinux.com/seaminaction > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110920/93da7e50/attachment.html From joserodolfo.freitas at gmail.com Tue Sep 20 17:02:04 2011 From: joserodolfo.freitas at gmail.com (=?ISO-8859-1?Q?Jos=E9_Rodolfo_Freitas?=) Date: Tue, 20 Sep 2011 18:02:04 -0300 Subject: [seam-dev] SAF (aka Entity Framework) idea in Seam 3 In-Reply-To: References: <1316504855.4917.YahooMailNeo@web160812.mail.bf1.yahoo.com> Message-ID: I think that my comment sounded a little bit extreme and I'd like to rectify my viewpoint a little bit. I don't know if you guys share my vision, but I think that's "extends genericLayer" e.g. is very invasive. But of course if we can't come out with a better way out of it using annotations, generic beans, decorators or etc... It's an acceptable solution. We're dealing with it for the last 5 years already. On Tue, Sep 20, 2011 at 5:00 PM, Jos? Rodolfo Freitas < joserodolfo.freitas at gmail.com> wrote: > Yeah, I agree that being declarative is the ideal. > let's say no to inheritance with generics! hehehe. > > > On Tue, Sep 20, 2011 at 4:41 PM, Dan Allen wrote: > >> On Tue, Sep 20, 2011 at 15:36, Jos? Rodolfo Freitas < >> joserodolfo.freitas at gmail.com> wrote: >> >>> What I like most in CDI and Seam3 is that it's very easy to keep things >>> simple and that's something I strongly advocate. >> >> >> +1 >> >> >>> Of course there're still boilerplate code, but I think it's minimal >>> (compared to the JEE generations before), and that's something forge can >>> create without the need to satisfy a "framework". Yes, I admitedly am afraid >>> of that word. >>> >> >> That's fine, it doesn't have to be a framework. I do think there is room >> for having some common scaffolding, though. If we can do that by extending >> the programming model (annotations, generic beans or interfaces) so that >> it's declarative, that's probably ideal. >> >> I suggest that we brainstorm proposals using gists ( >> http://gist.github.com). That will get the ball rolling. We can start >> with the idea Jason posted, or feel free to take a different approach. >> >> -Dan >> >> -- >> Dan Allen >> Principal Software Engineer, Red Hat | Author of Seam in Action >> Registered Linux User #231597 >> >> http://www.google.com/profiles/dan.j.allen#about >> http://mojavelinux.com >> http://mojavelinux.com/seaminaction >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110920/1ccd1554/attachment-0001.html From john.d.ament at gmail.com Tue Sep 20 21:57:47 2011 From: john.d.ament at gmail.com (John D. Ament) Date: Tue, 20 Sep 2011 21:57:47 -0400 Subject: [seam-dev] Seam JMS module refactoring/restructuring Message-ID: Gents, I've been working diligently (whenever I have time) to get the seam JMS module up and running on the new test suite format. One thing I've noticed is that because of the caveats of using JMS In SE vs. EE, it didn't just work to run weld ee embedded and within a container tests by themselves. It also became clear that in general this wouldn't work outside of a container because of differences in how to start open mq vs. hornetq vs. activemq. Even working in a remote JNDI provider (similar to how weblogic JMS works) it wouldn't have worked quite right. Soemthing I started a while ago (maybe 4-5 weeks) was to separate various impls to different modules. I want to go ahead and move forward with this approach. This would provide the main api and impl (across all impls) as well as a domain specific impl (e.g. seam-jms-ee-impl) that contains functionality for EE environments. As a result, when running the test suite, you are verifying the api, impl, the domain specific impl and the test suite for that specific combination. Does anyone have any concerns with this approach? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110920/b9368aaf/attachment.html From stuart.w.douglas at gmail.com Tue Sep 20 22:15:18 2011 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Wed, 21 Sep 2011 12:15:18 +1000 Subject: [seam-dev] SAF (aka Entity Framework) idea in Seam 3 In-Reply-To: References: <1316504855.4917.YahooMailNeo@web160812.mail.bf1.yahoo.com> Message-ID: <4E7948B6.604@gmail.com> My original plan for EntityQuery was to use the ServiceHandler stuff in solder: @EntityQuery public interface MyQuery { @Query("Select u from User u where type=:p1") public List users(String type); } Stuart On 09/21/2011 06:00 AM, Jos? Rodolfo Freitas wrote: > Yeah, I agree that being declarative is the ideal. > let's say no to inheritance with generics! hehehe. > > On Tue, Sep 20, 2011 at 4:41 PM, Dan Allen > wrote: > > On Tue, Sep 20, 2011 at 15:36, Jos? Rodolfo Freitas > > wrote: > > What I like most in CDI and Seam3 is that it's very easy to > keep things simple and that's something I strongly advocate. > > > +1 > > Of course there're still boilerplate code, but I think it's > minimal (compared to the JEE generations before), and that's > something forge can create without the need to satisfy a > "framework". Yes, I admitedly am afraid of that word. > > > That's fine, it doesn't have to be a framework. I do think there > is room for having some common scaffolding, though. If we can do > that by extending the programming model (annotations, generic > beans or interfaces) so that it's declarative, that's probably ideal. > > I suggest that we brainstorm proposals using gists > (http://gist.github.com). That will get the ball rolling. We can > start with the idea Jason posted, or feel free to take a different > approach. > > -Dan > > -- > Dan Allen > Principal Software Engineer, Red Hat | Author of Seam in Action > Registered Linux User #231597 > > http://www.google.com/profiles/dan.j.allen#about > http://mojavelinux.com > http://mojavelinux.com/seaminaction > > > > _______________________________________________ > seam-dev mailing list > seam-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/seam-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110921/c046649d/attachment.html From lightguard.jp at gmail.com Tue Sep 20 23:07:46 2011 From: lightguard.jp at gmail.com (Jason Porter) Date: Tue, 20 Sep 2011 21:07:46 -0600 Subject: [seam-dev] SAF (aka Entity Framework) idea in Seam 3 In-Reply-To: <4E7948B6.604@gmail.com> References: <1316504855.4917.YahooMailNeo@web160812.mail.bf1.yahoo.com> <4E7948B6.604@gmail.com> Message-ID: That's a good idea too Stuart. Can we easily make use of something similar for EntityHome, or do you think we have something easy enough with what I posted. Sent from my iPhone On Sep 20, 2011, at 20:15, Stuart Douglas wrote: > My original plan for EntityQuery was to use the ServiceHandler stuff in solder: > > @EntityQuery > public interface MyQuery { > > @Query("Select u from User u where type=:p1") > public List users(String type); > > } > > Stuart > > On 09/21/2011 06:00 AM, Jos? Rodolfo Freitas wrote: >> >> Yeah, I agree that being declarative is the ideal. >> let's say no to inheritance with generics! hehehe. >> >> On Tue, Sep 20, 2011 at 4:41 PM, Dan Allen wrote: >> On Tue, Sep 20, 2011 at 15:36, Jos? Rodolfo Freitas wrote: >> What I like most in CDI and Seam3 is that it's very easy to keep things simple and that's something I strongly advocate. >> >> +1 >> >> Of course there're still boilerplate code, but I think it's minimal (compared to the JEE generations before), and that's something forge can create without the need to satisfy a "framework". Yes, I admitedly am afraid of that word. >> >> That's fine, it doesn't have to be a framework. I do think there is room for having some common scaffolding, though. If we can do that by extending the programming model (annotations, generic beans or interfaces) so that it's declarative, that's probably ideal. >> >> I suggest that we brainstorm proposals using gists (http://gist.github.com). That will get the ball rolling. We can start with the idea Jason posted, or feel free to take a different approach. >> >> -Dan >> >> -- >> Dan Allen >> Principal Software Engineer, Red Hat | Author of Seam in Action >> Registered Linux User #231597 >> >> http://www.google.com/profiles/dan.j.allen#about >> http://mojavelinux.com >> http://mojavelinux.com/seaminaction >> >> >> >> _______________________________________________ >> seam-dev mailing list >> seam-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/seam-dev > > _______________________________________________ > seam-dev mailing list > seam-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/seam-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110920/097a2f63/attachment.html From gegastaldi at gmail.com Wed Sep 21 00:28:17 2011 From: gegastaldi at gmail.com (George Gastaldi) Date: Wed, 21 Sep 2011 01:28:17 -0300 Subject: [seam-dev] SAF (aka Entity Framework) idea in Seam 3 In-Reply-To: References: <1316504855.4917.YahooMailNeo@web160812.mail.bf1.yahoo.com> <4E7948B6.604@gmail.com> Message-ID: Excellent !! I would also add the possibility to pass the first row and also the Max Results parameters as qualifiers. Also, we should use NamedQuery to ease maintenance. 2011/9/21 Jason Porter : > That's a good idea too Stuart. Can we easily make use of something similar > for EntityHome, or do you think we have something easy enough with what I > posted. > > Sent from my iPhone > On Sep 20, 2011, at 20:15, Stuart Douglas > wrote: > > My original plan for EntityQuery was to use the ServiceHandler stuff in > solder: > > @EntityQuery > public interface MyQuery { > > ? @Query("Select u from User u where type=:p1") > ? public List users(String type); > > } > > Stuart > > On 09/21/2011 06:00 AM, Jos? Rodolfo Freitas wrote: > > Yeah, I agree that being declarative is the ideal. > let's say no to inheritance with generics! hehehe. > > On Tue, Sep 20, 2011 at 4:41 PM, Dan Allen wrote: >> >> On Tue, Sep 20, 2011 at 15:36, Jos? Rodolfo Freitas >> wrote: >>> >>> What I like most in CDI and Seam3 is that it's very easy to keep things >>> simple and that's something I strongly advocate. >> >> +1 >> >>> >>> Of course there're still boilerplate code, but I think it's minimal >>> (compared to the JEE generations before), and that's something forge can >>> create without the need to satisfy a "framework". Yes, I admitedly am afraid >>> of that word. >> >> That's fine, it doesn't have to be a framework. I do think there is room >> for having some common scaffolding, though. If we can do that by extending >> the programming model (annotations, generic beans or interfaces) so that >> it's declarative, that's probably ideal. >> I suggest that we brainstorm proposals using gists >> (http://gist.github.com). That will get the ball rolling. We can start with >> the idea Jason posted, or feel free to take a different approach. >> -Dan >> -- >> Dan Allen >> Principal Software Engineer, Red Hat | Author of Seam in Action >> Registered Linux User #231597 >> >> http://www.google.com/profiles/dan.j.allen#about >> http://mojavelinux.com >> http://mojavelinux.com/seaminaction >> > > > _______________________________________________ > seam-dev mailing list > seam-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/seam-dev > > _______________________________________________ > seam-dev mailing list > seam-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/seam-dev > > _______________________________________________ > seam-dev mailing list > seam-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/seam-dev > > From gegastaldi at gmail.com Wed Sep 21 00:43:43 2011 From: gegastaldi at gmail.com (George Gastaldi) Date: Wed, 21 Sep 2011 01:43:43 -0300 Subject: [seam-dev] SAF (aka Entity Framework) idea in Seam 3 In-Reply-To: References: <1316504855.4917.YahooMailNeo@web160812.mail.bf1.yahoo.com> <4E7948B6.604@gmail.com> Message-ID: Also, MyQuery could be an abstract class so when a query is not working right, you could implement by yourself using the same class 2011/9/21 George Gastaldi : > Excellent !! I would also add the possibility to pass the first row > and also the Max Results parameters as qualifiers. Also, we should use > NamedQuery to ease maintenance. > > > > 2011/9/21 Jason Porter : >> That's a good idea too Stuart. Can we easily make use of something similar >> for EntityHome, or do you think we have something easy enough with what I >> posted. >> >> Sent from my iPhone >> On Sep 20, 2011, at 20:15, Stuart Douglas >> wrote: >> >> My original plan for EntityQuery was to use the ServiceHandler stuff in >> solder: >> >> @EntityQuery >> public interface MyQuery { >> >> ? @Query("Select u from User u where type=:p1") >> ? public List users(String type); >> >> } >> >> Stuart >> >> On 09/21/2011 06:00 AM, Jos? Rodolfo Freitas wrote: >> >> Yeah, I agree that being declarative is the ideal. >> let's say no to inheritance with generics! hehehe. >> >> On Tue, Sep 20, 2011 at 4:41 PM, Dan Allen wrote: >>> >>> On Tue, Sep 20, 2011 at 15:36, Jos? Rodolfo Freitas >>> wrote: >>>> >>>> What I like most in CDI and Seam3 is that it's very easy to keep things >>>> simple and that's something I strongly advocate. >>> >>> +1 >>> >>>> >>>> Of course there're still boilerplate code, but I think it's minimal >>>> (compared to the JEE generations before), and that's something forge can >>>> create without the need to satisfy a "framework". Yes, I admitedly am afraid >>>> of that word. >>> >>> That's fine, it doesn't have to be a framework. I do think there is room >>> for having some common scaffolding, though. If we can do that by extending >>> the programming model (annotations, generic beans or interfaces) so that >>> it's declarative, that's probably ideal. >>> I suggest that we brainstorm proposals using gists >>> (http://gist.github.com). That will get the ball rolling. We can start with >>> the idea Jason posted, or feel free to take a different approach. >>> -Dan >>> -- >>> Dan Allen >>> Principal Software Engineer, Red Hat | Author of Seam in Action >>> Registered Linux User #231597 >>> >>> http://www.google.com/profiles/dan.j.allen#about >>> http://mojavelinux.com >>> http://mojavelinux.com/seaminaction >>> >> >> >> _______________________________________________ >> seam-dev mailing list >> seam-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/seam-dev >> >> _______________________________________________ >> seam-dev mailing list >> seam-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/seam-dev >> >> _______________________________________________ >> seam-dev mailing list >> seam-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/seam-dev >> >> > From maschmid at redhat.com Wed Sep 21 03:03:45 2011 From: maschmid at redhat.com (Marek Schmidt) Date: Wed, 21 Sep 2011 09:03:45 +0200 Subject: [seam-dev] Testsuite discussion notes In-Reply-To: <4E78DBE2.1040307@redhat.com> References: <4E77460E.5070304@redhat.com> <4E77C007.5070505@redhat.com> <255062B5-702B-4721-946A-DA68413BC689@gmail.com> <4E784A3D.7000402@redhat.com> <4E785423.7060404@redhat.com> <4E78DB72.4020106@redhat.com> <4E78DBE2.1040307@redhat.com> Message-ID: <4E798C51.706@redhat.com> On 09/20/2011 08:30 PM, Shane Bryzak wrote: > Thanks Marek. Just a heads up - the Catch, Config and Servlet modules > are going to be merged with Solder as sub-modules shortly. Would you > like me to wait until the testsuite is stable before I move the tests > over for these? Go ahead, if you could merge this before, that would be great: https://github.com/seam/solder/pull/49 thanks! Marek > > Shane > > On 21/09/11 04:29, Marek Schmidt wrote: >> On 09/20/2011 03:47 PM, Ond?ej Skutka wrote: >>> On Tue, 20 Sep 2011 10:51:47 +0200, Shane Bryzak >>> wrote: >>> >>>> Can we please make it a priority to get the Solder testsuite updated to >>>> the new structure and all the tests passing? Once this is done, the >>>> rest of the team can help out by updating the other modules to follow >>>> the same configuration. >>> >>> Sure. Marek, can you please focus on this? >> >> Sure, I am on it. >> >> Current progress in >> >> https://github.com/maschmid/solder/tree/testsuite-update-2 >> >>> >>> Thanks, >>> Ondra >>> >> > From mkouba at redhat.com Wed Sep 21 06:54:08 2011 From: mkouba at redhat.com (Martin Kouba) Date: Wed, 21 Sep 2011 12:54:08 +0200 Subject: [seam-dev] cdi/weld/seam - testing failed deployments in arquillian Message-ID: <4E79C250.80207@redhat.com> Hi, recently during CDI TCK arquillian migration (1.1 branch) we had to replace test harness @ExpectedDeploymentException in tests expecting deployment failure. So currently in TCK we use @ShouldThrowException(Exception.class) on arquillian deployment method. Indeed testing generic Exception is not the best solution but in fact right now we cannot test exact deployment causewhile there are no standardized CDI deployment-relatedexceptions (in CDI 1.1 there will be - see CDI-118 Standardize deployment-related exception classes). Also note that "Adding this annotation will force @{@link Deployment} to be testable = false which will force @{@link RunAsClient}". The other possibility is to use something like Assert.fail("Deployment should have failed...") or assert false in test method. Seam Compatibility and Weld use this approach. The question is whether to standardize this among all cdi/weld/seam tests. I think we should use the arquillian way (@ShouldThrowException) while its more obvious that we expect deployment failure and use relevant expected exceptions as soon as CDI 1.1 arrives. WDYT? M -- Martin Kouba JBoss Quality Assurance Engineer E-mail: mkouba at redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110921/2f83c9b8/attachment.html From jharting at redhat.com Wed Sep 21 07:27:25 2011 From: jharting at redhat.com (Jozef Hartinger) Date: Wed, 21 Sep 2011 13:27:25 +0200 Subject: [seam-dev] cdi/weld/seam - testing failed deployments in arquillian In-Reply-To: <4E79C250.80207@redhat.com> References: <4E79C250.80207@redhat.com> Message-ID: <4E79CA1D.7070509@redhat.com> I am for making these types of tests consistent among projects and @ShouldThrowException(Exception.class) seems to be right approach. AFAIK the only reason it's not used in Seam Compat and Weld is that is was not available / reliable enough on different containers at the time the tests were written. If this discussion leads to conclusion that Seam Compat and Weld should align, could you file jira tasks please? On 09/21/2011 12:54 PM, Martin Kouba wrote: > Hi, > recently during CDI TCK arquillian migration (1.1 branch) we had to > replace test harness @ExpectedDeploymentException in tests expecting > deployment failure. > > So currently in TCK we use @ShouldThrowException(Exception.class) on > arquillian deployment method. Indeed testing generic Exception is not > the best solution but in fact right now we cannot test exact > deployment causewhile there are no standardized CDI > deployment-relatedexceptions (in CDI 1.1 there will be - see CDI-118 > Standardize deployment-related exception classes). Also note that > "Adding this annotation will force @{@link Deployment} to be testable > = false which will force @{@link RunAsClient}". > > The other possibility is to use something like Assert.fail("Deployment > should have failed...") or assert false in test method. Seam > Compatibility and Weld use this approach. > > The question is whether to standardize this among all cdi/weld/seam > tests. I think we should use the arquillian way > (@ShouldThrowException) while its more obvious that we expect > deployment failure and use relevant expected exceptions as soon as CDI > 1.1 arrives. > > WDYT? > > M > -- > Martin Kouba > JBoss Quality Assurance Engineer > E-mail:mkouba at redhat.com > Web:www.cz.redhat.com > Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic From ales.justin at gmail.com Wed Sep 21 07:33:58 2011 From: ales.justin at gmail.com (Ales Justin) Date: Wed, 21 Sep 2011 13:33:58 +0200 Subject: [seam-dev] cdi/weld/seam - testing failed deployments in arquillian In-Reply-To: <4E79CA1D.7070509@redhat.com> References: <4E79C250.80207@redhat.com> <4E79CA1D.7070509@redhat.com> Message-ID: <7F00D9EA-D7FD-46C0-A5D3-44E4B7F10213@gmail.com> > I am for making these types of tests consistent among projects and > @ShouldThrowException(Exception.class) seems to be right approach. AFAIK > the only reason it's not used in Seam Compat and Weld is that is was not > available / reliable enough on different containers at the time the > tests were written. > > If this discussion leads to conclusion that Seam Compat and Weld should > align, could you file jira tasks please? Weld master is fully on latest ARQ atm, hence it already uses @STE. From lagoria at alice.it Wed Sep 21 15:09:27 2011 From: lagoria at alice.it (agori) Date: Wed, 21 Sep 2011 12:09:27 -0700 (PDT) Subject: [seam-dev] SAF (aka Entity Framework) idea in Seam 3 In-Reply-To: References: <1316504855.4917.YahooMailNeo@web160812.mail.bf1.yahoo.com> Message-ID: <1316632167138-3831102.post@n4.nabble.com> What do you think about implementing something like this? http://code.google.com/p/lambico/ with some improvements (for example I would prefer if queries are driven by annotations instead of method names) -- View this message in context: http://seam-framework.2283336.n4.nabble.com/SAF-aka-Entity-Framework-idea-in-Seam-3-tp3825919p3831102.html Sent from the seam-dev mailing list archive at Nabble.com. From dan.j.allen at gmail.com Wed Sep 21 17:39:38 2011 From: dan.j.allen at gmail.com (Dan Allen) Date: Wed, 21 Sep 2011 17:39:38 -0400 Subject: [seam-dev] SAF (aka Entity Framework) idea in Seam 3 In-Reply-To: <1316632167138-3831102.post@n4.nabble.com> References: <1316504855.4917.YahooMailNeo@web160812.mail.bf1.yahoo.com> <1316632167138-3831102.post@n4.nabble.com> Message-ID: We are thinking along the same lines :) -Dan On Wed, Sep 21, 2011 at 15:09, agori wrote: > What do you think about implementing something like this? > > http://code.google.com/p/lambico/ > > with some improvements (for example I would prefer if queries are driven by > annotations instead of method names) > > -- > View this message in context: > http://seam-framework.2283336.n4.nabble.com/SAF-aka-Entity-Framework-idea-in-Seam-3-tp3825919p3831102.html > Sent from the seam-dev mailing list archive at Nabble.com. > _______________________________________________ > seam-dev mailing list > seam-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/seam-dev > -- Dan Allen Principal Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://www.google.com/profiles/dan.j.allen#about http://mojavelinux.com http://mojavelinux.com/seaminaction -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110921/d7f9c016/attachment.html From lincolnbaxter at gmail.com Wed Sep 21 17:47:55 2011 From: lincolnbaxter at gmail.com (Lincoln Baxter, III) Date: Wed, 21 Sep 2011 17:47:55 -0400 Subject: [seam-dev] SAF (aka Entity Framework) idea in Seam 3 In-Reply-To: References: <1316504855.4917.YahooMailNeo@web160812.mail.bf1.yahoo.com> <1316632167138-3831102.post@n4.nabble.com> Message-ID: A framework like this would make things incredibly easy for Forge. On Wed, Sep 21, 2011 at 5:39 PM, Dan Allen wrote: > We are thinking along the same lines :) > > -Dan > > > On Wed, Sep 21, 2011 at 15:09, agori wrote: > >> What do you think about implementing something like this? >> >> http://code.google.com/p/lambico/ >> >> with some improvements (for example I would prefer if queries are driven >> by >> annotations instead of method names) >> >> -- >> View this message in context: >> http://seam-framework.2283336.n4.nabble.com/SAF-aka-Entity-Framework-idea-in-Seam-3-tp3825919p3831102.html >> Sent from the seam-dev mailing list archive at Nabble.com. >> _______________________________________________ >> seam-dev mailing list >> seam-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/seam-dev >> > > > > -- > Dan Allen > Principal Software Engineer, Red Hat | Author of Seam in Action > Registered Linux User #231597 > > http://www.google.com/profiles/dan.j.allen#about > http://mojavelinux.com > http://mojavelinux.com/seaminaction > > > _______________________________________________ > seam-dev mailing list > seam-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/seam-dev > > -- Lincoln Baxter, III http://ocpsoft.com http://scrumshark.com "Keep it Simple" -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110921/a5b955f3/attachment.html From dan.j.allen at gmail.com Wed Sep 21 18:10:22 2011 From: dan.j.allen at gmail.com (Dan Allen) Date: Wed, 21 Sep 2011 18:10:22 -0400 Subject: [seam-dev] SAF (aka Entity Framework) idea in Seam 3 In-Reply-To: <4E7948B6.604@gmail.com> References: <1316504855.4917.YahooMailNeo@web160812.mail.bf1.yahoo.com> <4E7948B6.604@gmail.com> Message-ID: Stuart, You also previous mentioned... With portable extensions we could do something like: @Entity @AutoHome public class MyEntity .... and have a portable extension that registers a new home bean for every entity with the @AutoHome annotation. I think we all agree that "Home" is a crappy name, so perhaps @Crud or @Dao would be a sufficient name. -Dan On Tue, Sep 20, 2011 at 22:15, Stuart Douglas wrote: > ** > My original plan for EntityQuery was to use the ServiceHandler stuff in > solder: > > @EntityQuery > public interface MyQuery { > > @Query("Select u from User u where type=:p1") > public List users(String type); > > } > > Stuart > > > On 09/21/2011 06:00 AM, Jos? Rodolfo Freitas wrote: > > Yeah, I agree that being declarative is the ideal. > let's say no to inheritance with generics! hehehe. > > On Tue, Sep 20, 2011 at 4:41 PM, Dan Allen wrote: > >> On Tue, Sep 20, 2011 at 15:36, Jos? Rodolfo Freitas < >> joserodolfo.freitas at gmail.com> wrote: >> >>> What I like most in CDI and Seam3 is that it's very easy to keep things >>> simple and that's something I strongly advocate. >> >> >> +1 >> >> >>> Of course there're still boilerplate code, but I think it's minimal >>> (compared to the JEE generations before), and that's something forge can >>> create without the need to satisfy a "framework". Yes, I admitedly am afraid >>> of that word. >>> >> >> That's fine, it doesn't have to be a framework. I do think there is room >> for having some common scaffolding, though. If we can do that by extending >> the programming model (annotations, generic beans or interfaces) so that >> it's declarative, that's probably ideal. >> >> I suggest that we brainstorm proposals using gists ( >> http://gist.github.com). That will get the ball rolling. We can start >> with the idea Jason posted, or feel free to take a different approach. >> >> -Dan >> >> -- >> Dan Allen >> Principal Software Engineer, Red Hat | Author of Seam in Action >> Registered Linux User #231597 >> >> http://www.google.com/profiles/dan.j.allen#about >> http://mojavelinux.com >> http://mojavelinux.com/seaminaction >> >> > > _______________________________________________ > seam-dev mailing list > seam-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/seam-dev > > > -- Dan Allen Principal Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://www.google.com/profiles/dan.j.allen#about http://mojavelinux.com http://mojavelinux.com/seaminaction -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110921/3c80ac4d/attachment.html From lightguard.jp at gmail.com Wed Sep 21 18:17:19 2011 From: lightguard.jp at gmail.com (Jason Porter) Date: Wed, 21 Sep 2011 16:17:19 -0600 Subject: [seam-dev] SAF (aka Entity Framework) idea in Seam 3 In-Reply-To: References: <1316504855.4917.YahooMailNeo@web160812.mail.bf1.yahoo.com> <4E7948B6.604@gmail.com> Message-ID: That's good at the runtime, but develop time that really doesn't help because it won't compile and you won't get IDE auto complete. On Wed, Sep 21, 2011 at 16:10, Dan Allen wrote: > Stuart, > > You also previous mentioned... > > With portable extensions we could do something like: > > > @Entity > @AutoHome > public class MyEntity .... > > > and have a portable extension that registers a new home bean for every > entity with the @AutoHome annotation. > > I think we all agree that "Home" is a crappy name, so perhaps @Crud or @Dao > would be a sufficient name. > > -Dan > > On Tue, Sep 20, 2011 at 22:15, Stuart Douglas wrote: > >> ** >> My original plan for EntityQuery was to use the ServiceHandler stuff in >> solder: >> >> @EntityQuery >> public interface MyQuery { >> >> @Query("Select u from User u where type=:p1") >> public List users(String type); >> >> } >> >> Stuart >> >> >> On 09/21/2011 06:00 AM, Jos? Rodolfo Freitas wrote: >> >> Yeah, I agree that being declarative is the ideal. >> let's say no to inheritance with generics! hehehe. >> >> On Tue, Sep 20, 2011 at 4:41 PM, Dan Allen wrote: >> >>> On Tue, Sep 20, 2011 at 15:36, Jos? Rodolfo Freitas < >>> joserodolfo.freitas at gmail.com> wrote: >>> >>>> What I like most in CDI and Seam3 is that it's very easy to keep things >>>> simple and that's something I strongly advocate. >>> >>> >>> +1 >>> >>> >>>> Of course there're still boilerplate code, but I think it's minimal >>>> (compared to the JEE generations before), and that's something forge can >>>> create without the need to satisfy a "framework". Yes, I admitedly am afraid >>>> of that word. >>>> >>> >>> That's fine, it doesn't have to be a framework. I do think there is >>> room for having some common scaffolding, though. If we can do that by >>> extending the programming model (annotations, generic beans or interfaces) >>> so that it's declarative, that's probably ideal. >>> >>> I suggest that we brainstorm proposals using gists ( >>> http://gist.github.com). That will get the ball rolling. We can start >>> with the idea Jason posted, or feel free to take a different approach. >>> >>> -Dan >>> >>> -- >>> Dan Allen >>> Principal Software Engineer, Red Hat | Author of Seam in Action >>> Registered Linux User #231597 >>> >>> http://www.google.com/profiles/dan.j.allen#about >>> http://mojavelinux.com >>> http://mojavelinux.com/seaminaction >>> >>> >> >> _______________________________________________ >> seam-dev mailing list >> seam-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/seam-dev >> >> >> > > > -- > Dan Allen > Principal Software Engineer, Red Hat | Author of Seam in Action > Registered Linux User #231597 > > http://www.google.com/profiles/dan.j.allen#about > http://mojavelinux.com > http://mojavelinux.com/seaminaction > > > _______________________________________________ > seam-dev mailing list > seam-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/seam-dev > > -- Jason Porter http://lightguard-jp.blogspot.com http://twitter.com/lightguardjp Software Engineer Open Source Advocate Author of Seam Catch - Next Generation Java Exception Handling PGP key id: 926CCFF5 PGP key available at: keyserver.net, pgp.mit.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110921/96299e76/attachment-0001.html From dan.j.allen at gmail.com Wed Sep 21 18:19:56 2011 From: dan.j.allen at gmail.com (Dan Allen) Date: Wed, 21 Sep 2011 18:19:56 -0400 Subject: [seam-dev] SAF (aka Entity Framework) idea in Seam 3 In-Reply-To: References: <1316504855.4917.YahooMailNeo@web160812.mail.bf1.yahoo.com> <4E7948B6.604@gmail.com> Message-ID: True. I don't really see the problem with having an object that extends a base object, even if it has no additional methods. ...and if that is the solution, then the @AutoCrud could be a hint to forge to generate that class if it doesn't yet exist. Now that's an idea :) -Dan On Wed, Sep 21, 2011 at 18:17, Jason Porter wrote: > That's good at the runtime, but develop time that really doesn't help > because it won't compile and you won't get IDE auto complete. > > > On Wed, Sep 21, 2011 at 16:10, Dan Allen wrote: > >> Stuart, >> >> You also previous mentioned... >> >> With portable extensions we could do something like: >> >> >> @Entity >> @AutoHome >> public class MyEntity .... >> >> >> and have a portable extension that registers a new home bean for every >> entity with the @AutoHome annotation. >> >> I think we all agree that "Home" is a crappy name, so perhaps @Crud or >> @Dao would be a sufficient name. >> >> -Dan >> >> On Tue, Sep 20, 2011 at 22:15, Stuart Douglas > > wrote: >> >>> ** >>> My original plan for EntityQuery was to use the ServiceHandler stuff in >>> solder: >>> >>> @EntityQuery >>> public interface MyQuery { >>> >>> @Query("Select u from User u where type=:p1") >>> public List users(String type); >>> >>> } >>> >>> Stuart >>> >>> >>> On 09/21/2011 06:00 AM, Jos? Rodolfo Freitas wrote: >>> >>> Yeah, I agree that being declarative is the ideal. >>> let's say no to inheritance with generics! hehehe. >>> >>> On Tue, Sep 20, 2011 at 4:41 PM, Dan Allen wrote: >>> >>>> On Tue, Sep 20, 2011 at 15:36, Jos? Rodolfo Freitas < >>>> joserodolfo.freitas at gmail.com> wrote: >>>> >>>>> What I like most in CDI and Seam3 is that it's very easy to keep things >>>>> simple and that's something I strongly advocate. >>>> >>>> >>>> +1 >>>> >>>> >>>>> Of course there're still boilerplate code, but I think it's minimal >>>>> (compared to the JEE generations before), and that's something forge can >>>>> create without the need to satisfy a "framework". Yes, I admitedly am afraid >>>>> of that word. >>>>> >>>> >>>> That's fine, it doesn't have to be a framework. I do think there is >>>> room for having some common scaffolding, though. If we can do that by >>>> extending the programming model (annotations, generic beans or interfaces) >>>> so that it's declarative, that's probably ideal. >>>> >>>> I suggest that we brainstorm proposals using gists ( >>>> http://gist.github.com). That will get the ball rolling. We can start >>>> with the idea Jason posted, or feel free to take a different approach. >>>> >>>> -Dan >>>> >>>> -- >>>> Dan Allen >>>> Principal Software Engineer, Red Hat | Author of Seam in Action >>>> Registered Linux User #231597 >>>> >>>> http://www.google.com/profiles/dan.j.allen#about >>>> http://mojavelinux.com >>>> http://mojavelinux.com/seaminaction >>>> >>>> >>> >>> _______________________________________________ >>> seam-dev mailing list >>> seam-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/seam-dev >>> >>> >>> >> >> >> -- >> Dan Allen >> Principal Software Engineer, Red Hat | Author of Seam in Action >> Registered Linux User #231597 >> >> http://www.google.com/profiles/dan.j.allen#about >> http://mojavelinux.com >> http://mojavelinux.com/seaminaction >> >> >> _______________________________________________ >> seam-dev mailing list >> seam-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/seam-dev >> >> > > > -- > Jason Porter > http://lightguard-jp.blogspot.com > http://twitter.com/lightguardjp > > Software Engineer > Open Source Advocate > Author of Seam Catch - Next Generation Java Exception Handling > > PGP key id: 926CCFF5 > PGP key available at: keyserver.net, pgp.mit.edu > -- Dan Allen Principal Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://www.google.com/profiles/dan.j.allen#about http://mojavelinux.com http://mojavelinux.com/seaminaction -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110921/afc3a657/attachment.html From dan.j.allen at gmail.com Wed Sep 21 18:22:33 2011 From: dan.j.allen at gmail.com (Dan Allen) Date: Wed, 21 Sep 2011 18:22:33 -0400 Subject: [seam-dev] SAF (aka Entity Framework) idea in Seam 3 In-Reply-To: References: <1316504855.4917.YahooMailNeo@web160812.mail.bf1.yahoo.com> Message-ID: Here's some additional feedback I received from a community member a while back...to merge it into this thread. (begin feedback) ...from being burned from 3 seam based customers with apps and maintenance. The "Home" or any other name should be just be put into a grave and slowly cast away to sea ;). It is too heavy and complicated and just about anything inherited (extends) truly causes heartache[Favor Composition over inheritance: Effective Java]. The current seam home has a few super classes above the home and when you try to unit test it (the standard definition of unit-testing including isolation) you get the "No Active Application Context Found (if I remember it right). That happens because it is tightly coupled with the application. But not to be hard on Home, I do realize the history of the home object and know it was developed when EL had no parameters. So I have learned a lot since then and I here are some things that I can impart to Seam 3. 1. My "Home" now is a "ServiceBean", and I have one for each "Major" entity, see below. I have really stewed over this over months and months, and the "Home" of "ServiceBean" should be kept small, focused, reusable, tested and untouched. It's only task is to update, persist, possibly remove, or some other functions that are required. In my example below I have custom close action. Notice also that although these beans are stateful that doesn't mean everything should be, so in these methods I have the parameter of what is being needed to be updated, and not a field. In other words I don't have @In private Job job, I opted for public boolean update(job). Mostly because, again, I want to make this service bean reusable so whether I have a #{newJob}, #{copyOfAJob}, or #{managedJob} or whatever component of job I need to work on I only need one jobServiceBean to cater to all my jobs, in whatever conversation I am using. I also fire events from here if I need to do that. After this is tested, and what I need I usually don't touch it anymore. If I need to enhance I either use a decorator pattern around it, or enhance it in an @Observer. I'll email about that later. @Name("jobServiceBean") @Scope(ScopeType.CONVERSATION) public class JobServiceBean implements JobService { private EntityManager entityManager; private StatusMessages statusMessages; @In public void setEntityManager(EntityManager entityManager) { this.entityManager = entityManager; } @In public void setStatusMessages(StatusMessages statusMessages) { this.statusMessages = statusMessages; } public boolean update(Job job) { this.entityManager.flush(); this.statusMessages.add(StatusMessage.Severity.INFO, "Successfully updated job {0}", job.getName()); return true; } public boolean close(Job job) { job.setJobStatus(JobStatus.CLOSED); this.entityManager.flush(); this.statusMessages.add(StatusMessage.Severity.INFO, "Successfully closed job {0}", job.getName()); return true; } } 2. One thing you may have noticed from above that there is no 'instance' field with corresponding getters or setters like the old 'Home'. So the ServiceBean in my case is not a full crud, but CUD + your own business methods. That's because that too should be decoupled because we never know the source of the object is. Is the object created from a factory? from a copy? is it a mapped component, a managed component? Creation of objects or loading of objects, or the manufacturing of objects from factories should be separate from the "home" or in my case the "ServiceBean". (end feedback) -- Dan Allen Principal Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://www.google.com/profiles/dan.j.allen#about http://mojavelinux.com http://mojavelinux.com/seaminaction -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110921/dfa9b718/attachment.html From stuart.w.douglas at gmail.com Wed Sep 21 18:30:33 2011 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Thu, 22 Sep 2011 08:30:33 +1000 Subject: [seam-dev] SAF (aka Entity Framework) idea in Seam 3 In-Reply-To: References: <1316504855.4917.YahooMailNeo@web160812.mail.bf1.yahoo.com> <4E7948B6.604@gmail.com> Message-ID: I don't really like that idea, as it means that forge then becomes part of your build process. With the @AutoHome it should not really matter about IDE auto completion, the idea is to just register a bean that allows you to lookup beans by ID from the EL. The underlying bean would probably look like: public class AutoHomeBean { private ID id; private T instance; void setId(ID id) { if(!this.id.equals(id) ) { //need NPE check as well this.instance = null; } this.id = id; } ID getId() //getter; public T getInstance() { if(instance == null && id != null) { instance = em.find(...); } return instance } } Then if you put the AutoHome annotation on MyEntity you would get a MyEntityHome bean being registered, and you could then do things like: #{myEntityHome.setId(10)}; #{myEntityHome.instance.name} Not sure how practical / useful it will be in practice, but that was the basic idea. Stuart On 22/09/2011, at 8:19 AM, Dan Allen wrote: > True. I don't really see the problem with having an object that extends a base object, even if it has no additional methods. > > ...and if that is the solution, then the @AutoCrud could be a hint to forge to generate that class if it doesn't yet exist. Now that's an idea :) > > -Dan > > On Wed, Sep 21, 2011 at 18:17, Jason Porter wrote: > That's good at the runtime, but develop time that really doesn't help because it won't compile and you won't get IDE auto complete. > > > On Wed, Sep 21, 2011 at 16:10, Dan Allen wrote: > Stuart, > > You also previous mentioned... > > With portable extensions we could do something like: > > @Entity > @AutoHome > public class MyEntity .... > > and have a portable extension that registers a new home bean for every entity with the @AutoHome annotation. > > I think we all agree that "Home" is a crappy name, so perhaps @Crud or @Dao would be a sufficient name. > > -Dan > > On Tue, Sep 20, 2011 at 22:15, Stuart Douglas wrote: > My original plan for EntityQuery was to use the ServiceHandler stuff in solder: > > @EntityQuery > public interface MyQuery { > > @Query("Select u from User u where type=:p1") > public List users(String type); > > } > > Stuart > > > On 09/21/2011 06:00 AM, Jos? Rodolfo Freitas wrote: >> Yeah, I agree that being declarative is the ideal. >> let's say no to inheritance with generics! hehehe. >> >> On Tue, Sep 20, 2011 at 4:41 PM, Dan Allen wrote: >> On Tue, Sep 20, 2011 at 15:36, Jos? Rodolfo Freitas wrote: >> What I like most in CDI and Seam3 is that it's very easy to keep things simple and that's something I strongly advocate. >> >> +1 >> >> Of course there're still boilerplate code, but I think it's minimal (compared to the JEE generations before), and that's something forge can create without the need to satisfy a "framework". Yes, I admitedly am afraid of that word. >> >> That's fine, it doesn't have to be a framework. I do think there is room for having some common scaffolding, though. If we can do that by extending the programming model (annotations, generic beans or interfaces) so that it's declarative, that's probably ideal. >> >> I suggest that we brainstorm proposals using gists (http://gist.github.com). That will get the ball rolling. We can start with the idea Jason posted, or feel free to take a different approach. >> >> -Dan >> >> -- >> Dan Allen >> Principal Software Engineer, Red Hat | Author of Seam in Action >> Registered Linux User #231597 >> >> http://www.google.com/profiles/dan.j.allen#about >> http://mojavelinux.com >> http://mojavelinux.com/seaminaction >> >> >> >> _______________________________________________ >> seam-dev mailing list >> seam-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/seam-dev > > > > > -- > Dan Allen > Principal Software Engineer, Red Hat | Author of Seam in Action > Registered Linux User #231597 > > http://www.google.com/profiles/dan.j.allen#about > http://mojavelinux.com > http://mojavelinux.com/seaminaction > > > _______________________________________________ > seam-dev mailing list > seam-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/seam-dev > > > > > -- > Jason Porter > http://lightguard-jp.blogspot.com > http://twitter.com/lightguardjp > > Software Engineer > Open Source Advocate > Author of Seam Catch - Next Generation Java Exception Handling > > PGP key id: 926CCFF5 > PGP key available at: keyserver.net, pgp.mit.edu > > > > -- > Dan Allen > Principal Software Engineer, Red Hat | Author of Seam in Action > Registered Linux User #231597 > > http://www.google.com/profiles/dan.j.allen#about > http://mojavelinux.com > http://mojavelinux.com/seaminaction > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110922/7cdcc298/attachment-0001.html From dan.j.allen at gmail.com Wed Sep 21 19:33:20 2011 From: dan.j.allen at gmail.com (Dan Allen) Date: Wed, 21 Sep 2011 19:33:20 -0400 Subject: [seam-dev] SAF (aka Entity Framework) idea in Seam 3 In-Reply-To: References: <1316504855.4917.YahooMailNeo@web160812.mail.bf1.yahoo.com> <4E7948B6.604@gmail.com> Message-ID: On Wed, Sep 21, 2011 at 18:30, Stuart Douglas wrote: > I don't really like that idea, as it means that forge then becomes part of > your build process. > Ah, I was suggesting that you add the annotation, then use Forge as a utility once to create the dao classes. Sort of forward engineering. -- Dan Allen Principal Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://www.google.com/profiles/dan.j.allen#about http://mojavelinux.com http://mojavelinux.com/seaminaction -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110921/2c19e0b3/attachment.html From dan.j.allen at gmail.com Wed Sep 21 19:34:36 2011 From: dan.j.allen at gmail.com (Dan Allen) Date: Wed, 21 Sep 2011 19:34:36 -0400 Subject: [seam-dev] SAF (aka Entity Framework) idea in Seam 3 In-Reply-To: References: <1316504855.4917.YahooMailNeo@web160812.mail.bf1.yahoo.com> <4E7948B6.604@gmail.com> Message-ID: On Wed, Sep 21, 2011 at 19:33, Dan Allen wrote: > On Wed, Sep 21, 2011 at 18:30, Stuart Douglas wrote: > >> I don't really like that idea, as it means that forge then becomes part of >> your build process. >> > > Ah, I was suggesting that you add the annotation, then use Forge as a > utility once to create the dao classes. Sort of forward engineering. > And the reason that's beneficial is because it tells forge which entities should have a dao...instead of it just blindly doing it for all entities. This could also be a hint as to which UI pages to create. -Dan -- Dan Allen Principal Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://www.google.com/profiles/dan.j.allen#about http://mojavelinux.com http://mojavelinux.com/seaminaction -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110921/1d51a318/attachment.html From dan.j.allen at gmail.com Wed Sep 21 19:53:48 2011 From: dan.j.allen at gmail.com (Dan Allen) Date: Wed, 21 Sep 2011 19:53:48 -0400 Subject: [seam-dev] cdi/weld/seam - testing failed deployments in arquillian In-Reply-To: <4E79CA1D.7070509@redhat.com> References: <4E79C250.80207@redhat.com> <4E79CA1D.7070509@redhat.com> Message-ID: 2011/9/21 Jozef Hartinger > I am for making these types of tests consistent among projects and > @ShouldThrowException(Exception.class) seems to be right approach. AFAIK > the only reason it's not used in Seam Compat and Weld is that is was not > available / reliable enough on different containers at the time the > tests were written. > Exactly. -- Dan Allen Principal Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://www.google.com/profiles/dan.j.allen#about http://mojavelinux.com http://mojavelinux.com/seaminaction -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110921/aa6f8a5d/attachment.html From dan.j.allen at gmail.com Wed Sep 21 19:55:04 2011 From: dan.j.allen at gmail.com (Dan Allen) Date: Wed, 21 Sep 2011 19:55:04 -0400 Subject: [seam-dev] Solder Testsuite update 2 Message-ID: Fantastic! Good work. -Dan ---------- Forwarded message ---------- From: Marek Schmidt < reply+i-1691451-c32d2a63f3bd03cabdcf4cb6a304e2d5daf15ab9 at reply.github.com> Date: Tue, Sep 20, 2011 at 16:33 Subject: [solder] Testsuite update 2 (#49) To: Dan Allen Yet another testsuite structure update, now even more simpler. This request includes Ken's changes (rebased) which brings non-arquillian unit tests back into impl/ Working Weld Embedded (default) and AS7 profiles (with one test failure, which I consider a bug in Solder and/or AS7) This patch also removes the hacky MavenArtifactResolver and uses a hard-coded paths, such as ../impl/target/solder-impl.jar to ZipImport Solder Modules. I believe this is now the most robust method for importing artifacts from the same project, for which MavenDependencyResolver cannot be used. That is, until the MavenImporter is ready (which should be Real Soon Now, see SHRINKWRAP-325). The only downside of this is that has been added to solder POMs, so that the build outputs have a reliable file name. You can merge this Pull Request by running: git pull https://github.com/maschmid/solder testsuite-update-2 Or you can view, comment on it, or merge it online at: https://github.com/seam/solder/pull/49 -- Commit Summary -- * yet another testsuite structure * rebase Ken's testsuite updates, moved unit tests back to impl/ -- Dan Allen Principal Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://www.google.com/profiles/dan.j.allen#about http://mojavelinux.com http://mojavelinux.com/seaminaction -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110921/87ed8abb/attachment.html From joserodolfo.freitas at gmail.com Wed Sep 21 22:59:52 2011 From: joserodolfo.freitas at gmail.com (=?ISO-8859-1?Q?Jos=E9_Rodolfo_Freitas?=) Date: Wed, 21 Sep 2011 23:59:52 -0300 Subject: [seam-dev] SAF (aka Entity Framework) idea in Seam 3 In-Reply-To: References: <1316504855.4917.YahooMailNeo@web160812.mail.bf1.yahoo.com> <4E7948B6.604@gmail.com> Message-ID: Hi guys, I see some problems on using extends for this approach: 1) I tend to follow the principle composition over inheritance aka "Composite Reuse Principle", The application design is more flexible when you're not highly tied with "extends". And since we already have something that kinda do some of the boilerplate code we're talking about, the entityManager, AND it works with a simple association (injection), I think that a better way to extend CRUD functionalities would be to wrap the EM up, add what we think is needed and inject in our EntityHandler or Home, or DAO or whatever. Otherwise we're going to create a new class that mostly will delegate calls to entityManager. 2) to keep code simple, I think that organizing classes by use cases (like booking for instance) is a really good approach, instead of having a PersonController, PersonService, PersonDAO and PersonEntity, that accumulates all kind of code related to Person use cases. Very often those classes become bloated. Having a package that handle its own use case, HiringPerson, for instance (dunno if it's a good example, though), seems more natural. The code is more atomic and when maintaining code, you're not swimming at a bunch of code not related to your case, and this in fact gives more value to reuse and code design. than always using the same structure over and over again. IMHO, If we create a genericDAO to be extended, I'm afraid that will encourage that kind of approach (PersonController, PService, PDAO and etc). If we do a more flexible way, we can easier work with both ways as one'd wish. 3) when we force the use of extends to do something that could be done with composition, we're killing other design possibilities. Frequently, we have to do an extends of an extends to workaround that. I mean if we have a class A that extends G and by design it seems logical that A should extends B. People workaround that making B extending G (even though sometimes B has nothing to do with G) so A can use both classes as parents. I really feel intimidated disagreeing with people that know so much like you guys, but I still think it's worth more discussion around that. On Wed, Sep 21, 2011 at 8:34 PM, Dan Allen wrote: > On Wed, Sep 21, 2011 at 19:33, Dan Allen wrote: > >> On Wed, Sep 21, 2011 at 18:30, Stuart Douglas > > wrote: >> >>> I don't really like that idea, as it means that forge then becomes part >>> of your build process. >>> >> >> Ah, I was suggesting that you add the annotation, then use Forge as a >> utility once to create the dao classes. Sort of forward engineering. >> > > And the reason that's beneficial is because it tells forge which entities > should have a dao...instead of it just blindly doing it for all entities. > This could also be a hint as to which UI pages to create. > > -Dan > > -- > Dan Allen > Principal Software Engineer, Red Hat | Author of Seam in Action > Registered Linux User #231597 > > http://www.google.com/profiles/dan.j.allen#about > http://mojavelinux.com > http://mojavelinux.com/seaminaction > > > _______________________________________________ > seam-dev mailing list > seam-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/seam-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110921/e0fc6659/attachment.html From joserodolfo.freitas at gmail.com Wed Sep 21 23:04:57 2011 From: joserodolfo.freitas at gmail.com (=?ISO-8859-1?Q?Jos=E9_Rodolfo_Freitas?=) Date: Thu, 22 Sep 2011 00:04:57 -0300 Subject: [seam-dev] SAF (aka Entity Framework) idea in Seam 3 In-Reply-To: References: <1316504855.4917.YahooMailNeo@web160812.mail.bf1.yahoo.com> <4E7948B6.604@gmail.com> Message-ID: And if something was written in an unclear English, I'd like to remind you that those were my last minutes of a long day. On Wed, Sep 21, 2011 at 11:59 PM, Jos? Rodolfo Freitas < joserodolfo.freitas at gmail.com> wrote: > Hi guys, > > I see some problems on using extends for this approach: > > 1) I tend to follow the principle composition over inheritance aka "Composite > Reuse Principle", > The application design is more flexible when you're not highly tied with > "extends". > And since we already have something that kinda do some of the boilerplate > code we're talking about, the entityManager, AND it works with a simple > association (injection), I think that a better way to extend CRUD > functionalities would be to wrap the EM up, add what we think is needed and > inject in our EntityHandler or Home, or DAO or whatever. Otherwise we're > going to create a new class that mostly will delegate calls to > entityManager. > > 2) to keep code simple, I think that organizing classes by use cases (like > booking for instance) is a really good approach, instead of having a > PersonController, PersonService, PersonDAO and PersonEntity, that > accumulates all kind of code related to Person use cases. Very often those > classes become bloated. > Having a package that handle its own use case, HiringPerson, for instance > (dunno if it's a good example, though), seems more natural. The code is more > atomic and when maintaining code, you're not swimming at a bunch of code not > related to your case, and this in fact gives more value to reuse and code > design. than always using the same structure over and over again. > IMHO, If we create a genericDAO to be extended, I'm afraid that > will encourage that kind of approach (PersonController, PService, PDAO and > etc). If we do a more flexible way, we can easier work with both ways as > one'd wish. > > 3) when we force the use of extends to do something that could be done with > composition, we're killing other design possibilities. Frequently, we have > to do an extends of an extends to workaround that. I mean if we have a class > A that extends G and by design it seems logical that A should extends B. > People workaround that making B extending G (even though sometimes B has > nothing to do with G) so A can use both classes as parents. > > I really feel intimidated disagreeing with people that know so much like > you guys, but I still think it's worth more discussion around that. > > > On Wed, Sep 21, 2011 at 8:34 PM, Dan Allen wrote: > >> On Wed, Sep 21, 2011 at 19:33, Dan Allen wrote: >> >>> On Wed, Sep 21, 2011 at 18:30, Stuart Douglas < >>> stuart.w.douglas at gmail.com> wrote: >>> >>>> I don't really like that idea, as it means that forge then becomes part >>>> of your build process. >>>> >>> >>> Ah, I was suggesting that you add the annotation, then use Forge as a >>> utility once to create the dao classes. Sort of forward engineering. >>> >> >> And the reason that's beneficial is because it tells forge which entities >> should have a dao...instead of it just blindly doing it for all entities. >> This could also be a hint as to which UI pages to create. >> >> -Dan >> >> -- >> Dan Allen >> Principal Software Engineer, Red Hat | Author of Seam in Action >> Registered Linux User #231597 >> >> http://www.google.com/profiles/dan.j.allen#about >> http://mojavelinux.com >> http://mojavelinux.com/seaminaction >> >> >> _______________________________________________ >> seam-dev mailing list >> seam-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/seam-dev >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110922/0040f39d/attachment-0001.html From lightguard.jp at gmail.com Wed Sep 21 23:29:43 2011 From: lightguard.jp at gmail.com (Jason Porter) Date: Wed, 21 Sep 2011 21:29:43 -0600 Subject: [seam-dev] SAF (aka Entity Framework) idea in Seam 3 In-Reply-To: References: <1316504855.4917.YahooMailNeo@web160812.mail.bf1.yahoo.com> <4E7948B6.604@gmail.com> Message-ID: No need to apologize :) your points are all valid and good design IMO. I think it's worth continuing the discussion. I've felt the same way about arguing with some of these guys about coding before. We're all equals here, and many times very simple things can be overlooked, don't feel intimidated, we appreciate the discussions. Sent from my iPhone On Sep 21, 2011, at 21:04, Jos? Rodolfo Freitas wrote: > And if something was written in an unclear English, I'd like to remind you that those were my last minutes of a long day. > > > On Wed, Sep 21, 2011 at 11:59 PM, Jos? Rodolfo Freitas wrote: > Hi guys, > > I see some problems on using extends for this approach: > > 1) I tend to follow the principle composition over inheritance aka "Composite Reuse Principle", > The application design is more flexible when you're not highly tied with "extends". > And since we already have something that kinda do some of the boilerplate code we're talking about, the entityManager, AND it works with a simple association (injection), I think that a better way to extend CRUD functionalities would be to wrap the EM up, add what we think is needed and inject in our EntityHandler or Home, or DAO or whatever. Otherwise we're going to create a new class that mostly will delegate calls to entityManager. > > 2) to keep code simple, I think that organizing classes by use cases (like booking for instance) is a really good approach, instead of having a PersonController, PersonService, PersonDAO and PersonEntity, that accumulates all kind of code related to Person use cases. Very often those classes become bloated. > Having a package that handle its own use case, HiringPerson, for instance (dunno if it's a good example, though), seems more natural. The code is more atomic and when maintaining code, you're not swimming at a bunch of code not related to your case, and this in fact gives more value to reuse and code design. than always using the same structure over and over again. > IMHO, If we create a genericDAO to be extended, I'm afraid that will encourage that kind of approach (PersonController, PService, PDAO and etc). If we do a more flexible way, we can easier work with both ways as one'd wish. > > 3) when we force the use of extends to do something that could be done with composition, we're killing other design possibilities. Frequently, we have to do an extends of an extends to workaround that. I mean if we have a class A that extends G and by design it seems logical that A should extends B. People workaround that making B extending G (even though sometimes B has nothing to do with G) so A can use both classes as parents. > > I really feel intimidated disagreeing with people that know so much like you guys, but I still think it's worth more discussion around that. > > > On Wed, Sep 21, 2011 at 8:34 PM, Dan Allen wrote: > On Wed, Sep 21, 2011 at 19:33, Dan Allen wrote: > On Wed, Sep 21, 2011 at 18:30, Stuart Douglas wrote: > I don't really like that idea, as it means that forge then becomes part of your build process. > > Ah, I was suggesting that you add the annotation, then use Forge as a utility once to create the dao classes. Sort of forward engineering. > > And the reason that's beneficial is because it tells forge which entities should have a dao...instead of it just blindly doing it for all entities. This could also be a hint as to which UI pages to create. > > -Dan > > -- > Dan Allen > Principal Software Engineer, Red Hat | Author of Seam in Action > Registered Linux User #231597 > > http://www.google.com/profiles/dan.j.allen#about > http://mojavelinux.com > http://mojavelinux.com/seaminaction > > > _______________________________________________ > seam-dev mailing list > seam-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/seam-dev > > > > _______________________________________________ > seam-dev mailing list > seam-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/seam-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110921/26e51d4c/attachment.html From lincolnbaxter at gmail.com Wed Sep 21 23:30:18 2011 From: lincolnbaxter at gmail.com (Lincoln Baxter, III) Date: Wed, 21 Sep 2011 23:30:18 -0400 Subject: [seam-dev] SAF (aka Entity Framework) idea in Seam 3 In-Reply-To: References: <1316504855.4917.YahooMailNeo@web160812.mail.bf1.yahoo.com> <4E7948B6.604@gmail.com> Message-ID: I actually have to agree with Jose. (Don't worry, you are a smart guy, and we are not that smart :) The EntityManager wrapper pattern in Forge is OK, but it's not a very strongly architected solution. I used it because it was easy, and I tend to think that solutions like it are done simply because "even though it smells, nobody has a better idea of what to eat." In fact, the only reason Forge uses "extends" via PersistenceUtil is because I need to inject a properly scoped EntityManager into *something* in order to make sure the correct one is used. That being said, perhaps one solution is to offer multiple producers for EntityManagers: - The stateless EntityManager - The request / conversation / session scoped EntityManagers - The application-scoped entity manager I am also actually very much in favor of Jason's idea: https://issues.jboss.org/browse/SEAMFORGE-280 combined, or paired with something like http://code.google.com/p/lambico/ (More the GORM-style approach) for simpler queries. DAOs are so 2005, and nobody liked them then. These objects could be exposed via @Named in EL, and of course be made injectable. There are also other approaches, like "Active Record," but in my opinion, the EntityManager poses a bit of a problem: It requires that it must already know about the entity. And in my experience that is an inherently difficult problem to overcome when attempting to build truly stateless applications - resulting in duplicate calls to the database to fetch data that you already have (just to sync things up.) While this is good for things like transactionality, it is bad for performance, but before I get too far off topic here, I'm just going to stop :) In a sense, we are fighting against JPA combined with a Strongly Typed language. I think that the lambico approach (annotating interfaces, like what Spring did - yep I said it) is actually the best approach I've seen in a long time. When you can't beat 'em, join 'em. (Then beat 'em) My 2 cents, ~Lincoln On Wed, Sep 21, 2011 at 11:04 PM, Jos? Rodolfo Freitas < joserodolfo.freitas at gmail.com> wrote: > And if something was written in an unclear English, I'd like to remind you > that those were my last minutes of a long day. > > > On Wed, Sep 21, 2011 at 11:59 PM, Jos? Rodolfo Freitas < > joserodolfo.freitas at gmail.com> wrote: > >> Hi guys, >> >> I see some problems on using extends for this approach: >> >> 1) I tend to follow the principle composition over inheritance aka "Composite >> Reuse Principle", >> The application design is more flexible when you're not highly tied with >> "extends". >> And since we already have something that kinda do some of the boilerplate >> code we're talking about, the entityManager, AND it works with a simple >> association (injection), I think that a better way to extend CRUD >> functionalities would be to wrap the EM up, add what we think is needed and >> inject in our EntityHandler or Home, or DAO or whatever. Otherwise we're >> going to create a new class that mostly will delegate calls to >> entityManager. >> >> 2) to keep code simple, I think that organizing classes by use cases (like >> booking for instance) is a really good approach, instead of having a >> PersonController, PersonService, PersonDAO and PersonEntity, that >> accumulates all kind of code related to Person use cases. Very often those >> classes become bloated. >> Having a package that handle its own use case, HiringPerson, for instance >> (dunno if it's a good example, though), seems more natural. The code is more >> atomic and when maintaining code, you're not swimming at a bunch of code not >> related to your case, and this in fact gives more value to reuse and code >> design. than always using the same structure over and over again. >> IMHO, If we create a genericDAO to be extended, I'm afraid that >> will encourage that kind of approach (PersonController, PService, PDAO and >> etc). If we do a more flexible way, we can easier work with both ways as >> one'd wish. >> >> 3) when we force the use of extends to do something that could be done >> with composition, we're killing other design possibilities. Frequently, we >> have to do an extends of an extends to workaround that. I mean if we have a >> class A that extends G and by design it seems logical that A should extends >> B. People workaround that making B extending G (even though sometimes B has >> nothing to do with G) so A can use both classes as parents. >> >> I really feel intimidated disagreeing with people that know so much like >> you guys, but I still think it's worth more discussion around that. >> >> >> On Wed, Sep 21, 2011 at 8:34 PM, Dan Allen wrote: >> >>> On Wed, Sep 21, 2011 at 19:33, Dan Allen wrote: >>> >>>> On Wed, Sep 21, 2011 at 18:30, Stuart Douglas < >>>> stuart.w.douglas at gmail.com> wrote: >>>> >>>>> I don't really like that idea, as it means that forge then becomes part >>>>> of your build process. >>>>> >>>> >>>> Ah, I was suggesting that you add the annotation, then use Forge as a >>>> utility once to create the dao classes. Sort of forward engineering. >>>> >>> >>> And the reason that's beneficial is because it tells forge which entities >>> should have a dao...instead of it just blindly doing it for all entities. >>> This could also be a hint as to which UI pages to create. >>> >>> -Dan >>> >>> -- >>> Dan Allen >>> Principal Software Engineer, Red Hat | Author of Seam in Action >>> Registered Linux User #231597 >>> >>> http://www.google.com/profiles/dan.j.allen#about >>> http://mojavelinux.com >>> http://mojavelinux.com/seaminaction >>> >>> >>> _______________________________________________ >>> seam-dev mailing list >>> seam-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/seam-dev >>> >>> >> > > _______________________________________________ > seam-dev mailing list > seam-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/seam-dev > > -- Lincoln Baxter, III http://ocpsoft.com http://scrumshark.com "Keep it Simple" -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110921/60a96653/attachment-0001.html From lightguard.jp at gmail.com Thu Sep 22 00:30:24 2011 From: lightguard.jp at gmail.com (Jason Porter) Date: Wed, 21 Sep 2011 22:30:24 -0600 Subject: [seam-dev] SAF (aka Entity Framework) idea in Seam 3 In-Reply-To: References: <1316504855.4917.YahooMailNeo@web160812.mail.bf1.yahoo.com> <4E7948B6.604@gmail.com> Message-ID: <120DC24C-2EB0-4BFC-8F1E-A5BC0F3B3E3A@gmail.com> I like what I've heard thus far, but do have a question about the multiple scoped EM idea. If you were going to do something like that (session and/or application scoped), wouldn't it make more sense for us to use a more proper architecture and help people understand how to use a cache like Infinispan or ehcache? Infinispan may be a better idea as it already has CDI integration and it'll scale with their application or cluster / cloud. I guess what I'm saying is if we're going to be showing off how to use something in an example or have Forge create it, we need to be doing it right from the first step. It'll save everyone time in the long run and will help educate the mass of less experienced developers that will undoubtably use our software. Sent from my iPhone On Sep 21, 2011, at 21:30, "Lincoln Baxter, III" wrote: > I actually have to agree with Jose. (Don't worry, you are a smart guy, and we are not that smart :) > > The EntityManager wrapper pattern in Forge is OK, but it's not a very strongly architected solution. I used it because it was easy, and I tend to think that solutions like it are done simply because "even though it smells, nobody has a better idea of what to eat." In fact, the only reason Forge uses "extends" via PersistenceUtil is because I need to inject a properly scoped EntityManager into *something* in order to make sure the correct one is used. That being said, perhaps one solution is to offer multiple producers for EntityManagers: > The stateless EntityManager > The request / conversation / session scoped EntityManagers > The application-scoped entity manager > I am also actually very much in favor of Jason's idea: https://issues.jboss.org/browse/SEAMFORGE-280 combined, or paired with something like http://code.google.com/p/lambico/ (More the GORM-style approach) for simpler queries. DAOs are so 2005, and nobody liked them then. > > These objects could be exposed via @Named in EL, and of course be made injectable. > > There are also other approaches, like "Active Record," but in my opinion, the EntityManager poses a bit of a problem: It requires that it must already know about the entity. And in my experience that is an inherently difficult problem to overcome when attempting to build truly stateless applications - resulting in duplicate calls to the database to fetch data that you already have (just to sync things up.) While this is good for things like transactionality, it is bad for performance, but before I get too far off topic here, I'm just going to stop :) In a sense, we are fighting against JPA combined with a Strongly Typed language. I think that the lambico approach (annotating interfaces, like what Spring did - yep I said it) is actually the best approach I've seen in a long time. > > When you can't beat 'em, join 'em. (Then beat 'em) > > My 2 cents, > ~Lincoln > > > > On Wed, Sep 21, 2011 at 11:04 PM, Jos? Rodolfo Freitas wrote: > And if something was written in an unclear English, I'd like to remind you that those were my last minutes of a long day. > > > On Wed, Sep 21, 2011 at 11:59 PM, Jos? Rodolfo Freitas wrote: > Hi guys, > > I see some problems on using extends for this approach: > > 1) I tend to follow the principle composition over inheritance aka "Composite Reuse Principle", > The application design is more flexible when you're not highly tied with "extends". > And since we already have something that kinda do some of the boilerplate code we're talking about, the entityManager, AND it works with a simple association (injection), I think that a better way to extend CRUD functionalities would be to wrap the EM up, add what we think is needed and inject in our EntityHandler or Home, or DAO or whatever. Otherwise we're going to create a new class that mostly will delegate calls to entityManager. > > 2) to keep code simple, I think that organizing classes by use cases (like booking for instance) is a really good approach, instead of having a PersonController, PersonService, PersonDAO and PersonEntity, that accumulates all kind of code related to Person use cases. Very often those classes become bloated. > Having a package that handle its own use case, HiringPerson, for instance (dunno if it's a good example, though), seems more natural. The code is more atomic and when maintaining code, you're not swimming at a bunch of code not related to your case, and this in fact gives more value to reuse and code design. than always using the same structure over and over again. > IMHO, If we create a genericDAO to be extended, I'm afraid that will encourage that kind of approach (PersonController, PService, PDAO and etc). If we do a more flexible way, we can easier work with both ways as one'd wish. > > 3) when we force the use of extends to do something that could be done with composition, we're killing other design possibilities. Frequently, we have to do an extends of an extends to workaround that. I mean if we have a class A that extends G and by design it seems logical that A should extends B. People workaround that making B extending G (even though sometimes B has nothing to do with G) so A can use both classes as parents. > > I really feel intimidated disagreeing with people that know so much like you guys, but I still think it's worth more discussion around that. > > > On Wed, Sep 21, 2011 at 8:34 PM, Dan Allen wrote: > On Wed, Sep 21, 2011 at 19:33, Dan Allen wrote: > On Wed, Sep 21, 2011 at 18:30, Stuart Douglas wrote: > I don't really like that idea, as it means that forge then becomes part of your build process. > > Ah, I was suggesting that you add the annotation, then use Forge as a utility once to create the dao classes. Sort of forward engineering. > > And the reason that's beneficial is because it tells forge which entities should have a dao...instead of it just blindly doing it for all entities. This could also be a hint as to which UI pages to create. > > -Dan > > -- > Dan Allen > Principal Software Engineer, Red Hat | Author of Seam in Action > Registered Linux User #231597 > > http://www.google.com/profiles/dan.j.allen#about > http://mojavelinux.com > http://mojavelinux.com/seaminaction > > > _______________________________________________ > seam-dev mailing list > seam-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/seam-dev > > > > > _______________________________________________ > seam-dev mailing list > seam-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/seam-dev > > > > > -- > Lincoln Baxter, III > http://ocpsoft.com > http://scrumshark.com > "Keep it Simple" > _______________________________________________ > seam-dev mailing list > seam-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/seam-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110921/ac751df6/attachment.html From dan.j.allen at gmail.com Thu Sep 22 01:02:10 2011 From: dan.j.allen at gmail.com (Dan Allen) Date: Thu, 22 Sep 2011 01:02:10 -0400 Subject: [seam-dev] SAF (aka Entity Framework) idea in Seam 3 In-Reply-To: References: <1316504855.4917.YahooMailNeo@web160812.mail.bf1.yahoo.com> <4E7948B6.604@gmail.com> Message-ID: On Wed, Sep 21, 2011 at 23:04, Jos? Rodolfo Freitas < joserodolfo.freitas at gmail.com> wrote: > And if something was written in an unclear English, I'd like to remind you > that those were my last minutes of a long day. Don't worry, we don't get on people about perfect grammar. We will only ask for clarification if the point is not coming through clearly. -Dan -- Dan Allen Principal Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://www.google.com/profiles/dan.j.allen#about http://mojavelinux.com http://mojavelinux.com/seaminaction -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110922/8e3346d4/attachment.html From dan.j.allen at gmail.com Thu Sep 22 01:03:00 2011 From: dan.j.allen at gmail.com (Dan Allen) Date: Thu, 22 Sep 2011 01:03:00 -0400 Subject: [seam-dev] SAF (aka Entity Framework) idea in Seam 3 In-Reply-To: References: <1316504855.4917.YahooMailNeo@web160812.mail.bf1.yahoo.com> <4E7948B6.604@gmail.com> Message-ID: On Thu, Sep 22, 2011 at 01:02, Dan Allen wrote: > On Wed, Sep 21, 2011 at 23:04, Jos? Rodolfo Freitas < > joserodolfo.freitas at gmail.com> wrote: > >> And if something was written in an unclear English, I'd like to remind you >> that those were my last minutes of a long day. > > > Don't worry, we don't get on people about perfect grammar. We will only ask > for clarification if the point is not coming through clearly. > ^ I should say "imperfect grammar". But then I'd be breaking my own rule :) -Dan -- Dan Allen Principal Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://www.google.com/profiles/dan.j.allen#about http://mojavelinux.com http://mojavelinux.com/seaminaction -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110922/aa449e9e/attachment-0001.html From dan.j.allen at gmail.com Thu Sep 22 01:13:01 2011 From: dan.j.allen at gmail.com (Dan Allen) Date: Thu, 22 Sep 2011 01:13:01 -0400 Subject: [seam-dev] SAF (aka Entity Framework) idea in Seam 3 In-Reply-To: References: <1316504855.4917.YahooMailNeo@web160812.mail.bf1.yahoo.com> <4E7948B6.604@gmail.com> Message-ID: On Wed, Sep 21, 2011 at 23:30, Lincoln Baxter, III wrote: > There are also other approaches, like "Active Record," but in my opinion, > the EntityManager poses a bit of a problem: It requires that it must already > know about the entity. And in my experience that is an inherently difficult > problem to overcome when attempting to build truly stateless applications - > resulting in duplicate calls to the database to fetch data that you already > have (just to sync things up.) While this is good for things like > transactionality, it is bad for performance, but before I get too far off > topic here, I'm just going to stop :) In a sense, we are fighting against > JPA combined with a Strongly Typed language. I think that the lambico > approach (annotating interfaces, like what Spring did - yep I said it) is > actually the best approach I've seen in a long time. > > The other point to make here is that the reason we need a class at all is because the EntityManager only gives us part of what we need. It certainly does CRUD. But it does provide transaction boundaries, it does not hold a reference to the active instance and some of it's methods require knowing the context (persist vs merge vs the implicit update). We don't necessarily want to hide the EntityManager, since a philosophy of Seam has always been to keep the native APIs exposed and unwrapped. But we do want to keep the developer's codebase dry. ...with that said, I'm fine with a "smarter" entity manager class that can be used as a delegate. But I do think there is merit in offering a class to extend for rapid development scenarios. Jose, could you make a gist for how you would create a bean for managing an entity instance using the composite pattern? I'm asking so we have something to contrast. (btw, the term EntityHandler sounds reasonable to me. Another approach Jason and I had was EntityInstanceManager, or *Handler. We want to distinguish between the EntityManager which manages all instances and a component that manages just a single instance). -Dan -- Dan Allen Principal Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://www.google.com/profiles/dan.j.allen#about http://mojavelinux.com http://mojavelinux.com/seaminaction -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110922/f56a28d4/attachment.html From lagoria at alice.it Thu Sep 22 02:59:03 2011 From: lagoria at alice.it (agori) Date: Wed, 21 Sep 2011 23:59:03 -0700 (PDT) Subject: [seam-dev] SAF (aka Entity Framework) idea in Seam 3 In-Reply-To: <4E7948B6.604@gmail.com> References: <1316504855.4917.YahooMailNeo@web160812.mail.bf1.yahoo.com> <4E7948B6.604@gmail.com> Message-ID: <1316674743887-3832580.post@n4.nabble.com> An interterface is surely a nice choise, but sometimes it would be better an abtract class to insert custom code in the class. Is possible to implement it throught ServerHandler extension? -- View this message in context: http://seam-framework.2283336.n4.nabble.com/SAF-aka-Entity-Framework-idea-in-Seam-3-tp3825919p3832580.html Sent from the seam-dev mailing list archive at Nabble.com. From joserodolfo.freitas at gmail.com Thu Sep 22 09:02:56 2011 From: joserodolfo.freitas at gmail.com (=?ISO-8859-1?Q?Jos=E9_Rodolfo_Freitas?=) Date: Thu, 22 Sep 2011 10:02:56 -0300 Subject: [seam-dev] SAF (aka Entity Framework) idea in Seam 3 In-Reply-To: References: <1316504855.4917.YahooMailNeo@web160812.mail.bf1.yahoo.com> <4E7948B6.604@gmail.com> Message-ID: Ok, I'll try to do that today. On Thu, Sep 22, 2011 at 2:13 AM, Dan Allen wrote: > On Wed, Sep 21, 2011 at 23:30, Lincoln Baxter, III < > lincolnbaxter at gmail.com> wrote: > >> There are also other approaches, like "Active Record," but in my opinion, >> the EntityManager poses a bit of a problem: It requires that it must already >> know about the entity. And in my experience that is an inherently difficult >> problem to overcome when attempting to build truly stateless applications - >> resulting in duplicate calls to the database to fetch data that you already >> have (just to sync things up.) While this is good for things like >> transactionality, it is bad for performance, but before I get too far off >> topic here, I'm just going to stop :) In a sense, we are fighting against >> JPA combined with a Strongly Typed language. I think that the lambico >> approach (annotating interfaces, like what Spring did - yep I said it) is >> actually the best approach I've seen in a long time. >> >> > The other point to make here is that the reason we need a class at all is > because the EntityManager only gives us part of what we need. It certainly > does CRUD. But it does provide transaction boundaries, it does not hold a > reference to the active instance and some of it's methods require knowing > the context (persist vs merge vs the implicit update). We don't necessarily > want to hide the EntityManager, since a philosophy of Seam has always been > to keep the native APIs exposed and unwrapped. But we do want to keep the > developer's codebase dry. > > ...with that said, I'm fine with a "smarter" entity manager class that can > be used as a delegate. But I do think there is merit in offering a class to > extend for rapid development scenarios. > > Jose, could you make a gist for how you would create a bean for managing an > entity instance using the composite pattern? I'm asking so we have something > to contrast. > > (btw, the term EntityHandler sounds reasonable to me. Another approach > Jason and I had was EntityInstanceManager, or *Handler. We want to > distinguish between the EntityManager which manages all instances and a > component that manages just a single instance). > > -Dan > > -- > Dan Allen > Principal Software Engineer, Red Hat | Author of Seam in Action > Registered Linux User #231597 > > http://www.google.com/profiles/dan.j.allen#about > http://mojavelinux.com > http://mojavelinux.com/seaminaction > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110922/5eb909e1/attachment.html From max.andersen at redhat.com Thu Sep 22 10:52:04 2011 From: max.andersen at redhat.com (Max Rydahl Andersen) Date: Thu, 22 Sep 2011 16:52:04 +0200 Subject: [seam-dev] [forge-dev] SAF (aka Entity Framework) idea in Seam 3 In-Reply-To: References: <1316504855.4917.YahooMailNeo@web160812.mail.bf1.yahoo.com> Message-ID: <9BB1592F-4558-484F-99EF-FD825D56E456@redhat.com> just one comment: Calling .flush() on every alteration really should not be promoted as a good practice. /max On Sep 22, 2011, at 24:22, Dan Allen wrote: > Here's some additional feedback I received from a community member a while back...to merge it into this thread. > > (begin feedback) > > ...from being burned from 3 seam based customers with apps and maintenance. The "Home" or any other name should be just be put into a grave and slowly cast away to sea ;). It is too heavy and complicated and just about anything inherited (extends) truly causes heartache[Favor Composition over inheritance: Effective Java]. The current seam home has a few super classes above the home and when you try to unit test it (the standard definition of unit-testing including isolation) you get the "No Active Application Context Found (if I remember it right). That happens because it is tightly coupled with the application. But not to be hard on Home, I do realize the history of the home object and know it was developed when EL had no parameters. So I have learned a lot since then and I here are some things that I can impart to Seam 3. > > 1. My "Home" now is a "ServiceBean", and I have one for each "Major" entity, see below. I have really stewed over this over months and months, and the "Home" of "ServiceBean" should be kept small, focused, reusable, tested and untouched. It's only task is to update, persist, possibly remove, or some other functions that are required. In my example below I have custom close action. Notice also that although these beans are stateful that doesn't mean everything should be, so in these methods I have the parameter of what is being needed to be updated, and not a field. In other words I don't have @In private Job job, I opted for public boolean update(job). Mostly because, again, I want to make this service bean reusable so whether I have a #{newJob}, #{copyOfAJob}, or #{managedJob} or whatever component of job I need to work on I only need one jobServiceBean to cater to all my jobs, in whatever conversation I am using. I also fire events from here if I need to do that. After this is tested, and what I need I usually don't touch it anymore. If I need to enhance I either use a decorator pattern around it, or enhance it in an @Observer. I'll email about that later. > > @Name("jobServiceBean") > @Scope(ScopeType.CONVERSATION) > public class JobServiceBean implements JobService { > private EntityManager entityManager; > private StatusMessages statusMessages; > > @In > public void setEntityManager(EntityManager entityManager) { > this.entityManager = entityManager; > } > > @In > public void setStatusMessages(StatusMessages statusMessages) { > this.statusMessages = statusMessages; > } > > public boolean update(Job job) { > this.entityManager.flush(); > this.statusMessages.add(StatusMessage.Severity.INFO, "Successfully updated job {0}", job.getName()); > return true; > } > > public boolean close(Job job) { > job.setJobStatus(JobStatus.CLOSED); > this.entityManager.flush(); > this.statusMessages.add(StatusMessage.Severity.INFO, "Successfully closed job {0}", job.getName()); > return true; > } > } > > 2. One thing you may have noticed from above that there is no 'instance' field with corresponding getters or setters like the old 'Home'. So the ServiceBean in my case is not a full crud, but CUD + your own business methods. That's because that too should be decoupled because we never know the source of the object is. Is the object created from a factory? from a copy? is it a mapped component, a managed component? Creation of objects or loading of objects, or the manufacturing of objects from factories should be separate from the "home" or in my case the "ServiceBean". > > (end feedback) > > -- > Dan Allen > Principal Software Engineer, Red Hat | Author of Seam in Action > Registered Linux User #231597 > > http://www.google.com/profiles/dan.j.allen#about > http://mojavelinux.com > http://mojavelinux.com/seaminaction > > _______________________________________________ > forge-dev mailing list > forge-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev /max http://about.me/maxandersen From dan.j.allen at gmail.com Thu Sep 22 13:12:24 2011 From: dan.j.allen at gmail.com (Dan Allen) Date: Thu, 22 Sep 2011 13:12:24 -0400 Subject: [seam-dev] [forge-dev] SAF (aka Entity Framework) idea in Seam 3 In-Reply-To: <9BB1592F-4558-484F-99EF-FD825D56E456@redhat.com> References: <1316504855.4917.YahooMailNeo@web160812.mail.bf1.yahoo.com> <9BB1592F-4558-484F-99EF-FD825D56E456@redhat.com> Message-ID: Exactly. flush() has a specific purpose and really doesn't belong in boilerplate code. - Dan Allen Sent from my Android-powered phone: An open platform for carriers, consumers and developers On Sep 22, 2011 11:19 AM, "Max Rydahl Andersen" wrote: > just one comment: > > Calling .flush() on every alteration really should not be promoted as a good practice. > > /max > > On Sep 22, 2011, at 24:22, Dan Allen wrote: > >> Here's some additional feedback I received from a community member a while back...to merge it into this thread. >> >> (begin feedback) >> >> ...from being burned from 3 seam based customers with apps and maintenance. The "Home" or any other name should be just be put into a grave and slowly cast away to sea ;). It is too heavy and complicated and just about anything inherited (extends) truly causes heartache[Favor Composition over inheritance: Effective Java]. The current seam home has a few super classes above the home and when you try to unit test it (the standard definition of unit-testing including isolation) you get the "No Active Application Context Found (if I remember it right). That happens because it is tightly coupled with the application. But not to be hard on Home, I do realize the history of the home object and know it was developed when EL had no parameters. So I have learned a lot since then and I here are some things that I can impart to Seam 3. >> >> 1. My "Home" now is a "ServiceBean", and I have one for each "Major" entity, see below. I have really stewed over this over months and months, and the "Home" of "ServiceBean" should be kept small, focused, reusable, tested and untouched. It's only task is to update, persist, possibly remove, or some other functions that are required. In my example below I have custom close action. Notice also that although these beans are stateful that doesn't mean everything should be, so in these methods I have the parameter of what is being needed to be updated, and not a field. In other words I don't have @In private Job job, I opted for public boolean update(job). Mostly because, again, I want to make this service bean reusable so whether I have a #{newJob}, #{copyOfAJob}, or #{managedJob} or whatever component of job I need to work on I only need one jobServiceBean to cater to all my jobs, in whatever conversation I am using. I also fire events from here if I need to do that. ! > After this is tested, and what I need I usually don't touch it anymore. If I need to enhance I either use a decorator pattern around it, or enhance it in an @Observer. I'll email about that later. >> >> @Name("jobServiceBean") >> @Scope(ScopeType.CONVERSATION) >> public class JobServiceBean implements JobService { >> private EntityManager entityManager; >> private StatusMessages statusMessages; >> >> @In >> public void setEntityManager(EntityManager entityManager) { >> this.entityManager = entityManager; >> } >> >> @In >> public void setStatusMessages(StatusMessages statusMessages) { >> this.statusMessages = statusMessages; >> } >> >> public boolean update(Job job) { >> this.entityManager.flush(); >> this.statusMessages.add(StatusMessage.Severity.INFO, "Successfully updated job {0}", job.getName()); >> return true; >> } >> >> public boolean close(Job job) { >> job.setJobStatus(JobStatus.CLOSED); >> this.entityManager.flush(); >> this.statusMessages.add(StatusMessage.Severity.INFO, "Successfully closed job {0}", job.getName()); >> return true; >> } >> } >> >> 2. One thing you may have noticed from above that there is no 'instance' field with corresponding getters or setters like the old 'Home'. So the ServiceBean in my case is not a full crud, but CUD + your own business methods. That's because that too should be decoupled because we never know the source of the object is. Is the object created from a factory? from a copy? is it a mapped component, a managed component? Creation of objects or loading of objects, or the manufacturing of objects from factories should be separate from the "home" or in my case the "ServiceBean". >> >> (end feedback) >> >> -- >> Dan Allen >> Principal Software Engineer, Red Hat | Author of Seam in Action >> Registered Linux User #231597 >> >> http://www.google.com/profiles/dan.j.allen#about >> http://mojavelinux.com >> http://mojavelinux.com/seaminaction >> >> _______________________________________________ >> forge-dev mailing list >> forge-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/forge-dev > > /max > http://about.me/maxandersen > > > > > _______________________________________________ > forge-dev mailing list > forge-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110922/5d001327/attachment.html From mkouba at redhat.com Fri Sep 23 04:46:10 2011 From: mkouba at redhat.com (Martin Kouba) Date: Fri, 23 Sep 2011 10:46:10 +0200 Subject: [seam-dev] cdi/weld/seam - testing failed deployments in arquillian In-Reply-To: <7F00D9EA-D7FD-46C0-A5D3-44E4B7F10213@gmail.com> References: <4E79C250.80207@redhat.com> <4E79CA1D.7070509@redhat.com> <7F00D9EA-D7FD-46C0-A5D3-44E4B7F10213@gmail.com> Message-ID: <4E7C4752.2050907@redhat.com> Very well then we agreed. JIRA issue for Josef: https://issues.jboss.org/browse/SEAM-100 Ales there is one last remaining: org.jboss.weld.tests.decorators.abstractDecorator.broken.SimpleAbstractDecoratorWithInvalidAbstractMethodTest :-) Martin Dne 21.9.2011 13:33, Ales Justin napsal(a): >> I am for making these types of tests consistent among projects and >> @ShouldThrowException(Exception.class) seems to be right approach. AFAIK >> the only reason it's not used in Seam Compat and Weld is that is was not >> available / reliable enough on different containers at the time the >> tests were written. >> >> If this discussion leads to conclusion that Seam Compat and Weld should >> align, could you file jira tasks please? > Weld master is fully on latest ARQ atm, hence it already uses @STE. > From ales.justin at gmail.com Fri Sep 23 04:56:44 2011 From: ales.justin at gmail.com (Ales Justin) Date: Fri, 23 Sep 2011 10:56:44 +0200 Subject: [seam-dev] cdi/weld/seam - testing failed deployments in arquillian In-Reply-To: <4E7C4752.2050907@redhat.com> References: <4E79C250.80207@redhat.com> <4E79CA1D.7070509@redhat.com> <7F00D9EA-D7FD-46C0-A5D3-44E4B7F10213@gmail.com> <4E7C4752.2050907@redhat.com> Message-ID: > Very well then we agreed. > > JIRA issue for Josef: https://issues.jboss.org/browse/SEAM-100 > > Ales there is one last remaining: org.jboss.weld.tests.decorators.abstractDecorator.broken.SimpleAbstractDecoratorWithInvalidAbstractMethodTest :-) Remaining in what way? Not marked with @STE? >>> I am for making these types of tests consistent among projects and >>> @ShouldThrowException(Exception.class) seems to be right approach. AFAIK >>> the only reason it's not used in Seam Compat and Weld is that is was not >>> available / reliable enough on different containers at the time the >>> tests were written. >>> >>> If this discussion leads to conclusion that Seam Compat and Weld should >>> align, could you file jira tasks please? >> Weld master is fully on latest ARQ atm, hence it already uses @STE. >> From mkouba at redhat.com Fri Sep 23 05:02:54 2011 From: mkouba at redhat.com (Martin Kouba) Date: Fri, 23 Sep 2011 11:02:54 +0200 Subject: [seam-dev] cdi/weld/seam - testing failed deployments in arquillian In-Reply-To: References: <4E79C250.80207@redhat.com> <4E79CA1D.7070509@redhat.com> <7F00D9EA-D7FD-46C0-A5D3-44E4B7F10213@gmail.com> <4E7C4752.2050907@redhat.com> Message-ID: <4E7C4B3E.6050002@redhat.com> Dne 23.9.2011 10:56, Ales Justin napsal(a): >> Very well then we agreed. >> >> JIRA issue for Josef: https://issues.jboss.org/browse/SEAM-100 >> >> Ales there is one last remaining: org.jboss.weld.tests.decorators.abstractDecorator.broken.SimpleAbstractDecoratorWithInvalidAbstractMethodTest :-) > Remaining in what way? > Not marked with @STE? Exactly - not marked with @STE. Sorry for vague expression... >>>> I am for making these types of tests consistent among projects and >>>> @ShouldThrowException(Exception.class) seems to be right approach. AFAIK >>>> the only reason it's not used in Seam Compat and Weld is that is was not >>>> available / reliable enough on different containers at the time the >>>> tests were written. >>>> >>>> If this discussion leads to conclusion that Seam Compat and Weld should >>>> align, could you file jira tasks please? >>> Weld master is fully on latest ARQ atm, hence it already uses @STE. >>> From sbryzak at redhat.com Sun Sep 25 20:02:36 2011 From: sbryzak at redhat.com (Shane Bryzak) Date: Mon, 26 Sep 2011 10:02:36 +1000 Subject: [seam-dev] Catch, Config and Servlet modules merged with Solder Message-ID: <4E7FC11C.9000000@redhat.com> Just a heads up to everyone, I've merged the catch, config and servlet modules into Solder, so committers/integrators for these modules should no longer send any pull requests or merge any changes for these modules, instead they should now go into Solder. There's still a few additional steps that need to be carried out - 1) documentation still needs to be merged 2) JIRA issues merged and the old modules deleted 3) sfwk.org updated to reflect the change 4) seam-bom updated 5) modules or examples that use catch, config or servlet need to be updated FYI, the new package names are: Seam Catch - org.jboss.solder.exception Seam Config - org.jboss.solder.config Seam Servlet - org.jboss.solder.servlet Any questions or concerns, ask away. We'll be hammering out the remaining items that I listed above over the next couple of days. Shane From lightguard.jp at gmail.com Mon Sep 26 18:56:32 2011 From: lightguard.jp at gmail.com (Jason Porter) Date: Mon, 26 Sep 2011 16:56:32 -0600 Subject: [seam-dev] Meeting 2011-09-28 Message-ID: Agenda - Logging (assuming Ken is around) - 10 min - Jenkins - 10 min - What happens after 3.1.0 - 15 min -- Jason Porter http://lightguard-jp.blogspot.com http://twitter.com/lightguardjp Software Engineer Open Source Advocate Author of Seam Catch - Next Generation Java Exception Handling PGP key id: 926CCFF5 PGP key available at: keyserver.net, pgp.mit.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110926/67386b6a/attachment.html From lightguard.jp at gmail.com Mon Sep 26 18:58:44 2011 From: lightguard.jp at gmail.com (Jason Porter) Date: Mon, 26 Sep 2011 16:58:44 -0600 Subject: [seam-dev] Meeting 2011-09-28 In-Reply-To: References: Message-ID: Also we need to talk about the next Seam Hack Night On Mon, Sep 26, 2011 at 16:56, Jason Porter wrote: > Logging (assuming Ken is around) - 10 min > Jenkins - 10 min > What happens after 3.1.0 - 15 min -- Jason Porter http://lightguard-jp.blogspot.com http://twitter.com/lightguardjp Software Engineer Open Source Advocate Author of Seam Catch - Next Generation Java Exception Handling PGP key id: 926CCFF5 PGP key available at: keyserver.net, pgp.mit.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110926/24af7d18/attachment.html From joserodolfo.freitas at gmail.com Tue Sep 27 09:32:50 2011 From: joserodolfo.freitas at gmail.com (=?ISO-8859-1?Q?Jos=E9_Rodolfo_Freitas?=) Date: Tue, 27 Sep 2011 10:32:50 -0300 Subject: [seam-dev] [forge-dev] SAF (aka Entity Framework) idea in Seam 3 In-Reply-To: References: <1316504855.4917.YahooMailNeo@web160812.mail.bf1.yahoo.com> <9BB1592F-4558-484F-99EF-FD825D56E456@redhat.com> Message-ID: Sorry for not being able to post my gist. After writting some "sketches", I realized that I don't have it very clear in my mind yet. just to move from zero I posted something: https://gist.github.com/1245041 It's a really simple example on how we could avoid inheritance, but it's not contemplating a lot of needed features, so I'm not even near to be convinced with that gist. btw, the @AutoHome approach seems very nice. On Thu, Sep 22, 2011 at 2:12 PM, Dan Allen wrote: > Exactly. flush() has a specific purpose and really doesn't belong in > boilerplate code. > > - Dan Allen > > Sent from my Android-powered phone: > An open platform for carriers, consumers and developers > On Sep 22, 2011 11:19 AM, "Max Rydahl Andersen" > wrote: > > just one comment: > > > > Calling .flush() on every alteration really should not be promoted as a > good practice. > > > > /max > > > > On Sep 22, 2011, at 24:22, Dan Allen wrote: > > > >> Here's some additional feedback I received from a community member a > while back...to merge it into this thread. > >> > >> (begin feedback) > >> > >> ...from being burned from 3 seam based customers with apps and > maintenance. The "Home" or any other name should be just be put into a grave > and slowly cast away to sea ;). It is too heavy and complicated and just > about anything inherited (extends) truly causes heartache[Favor Composition > over inheritance: Effective Java]. The current seam home has a few super > classes above the home and when you try to unit test it (the standard > definition of unit-testing including isolation) you get the "No Active > Application Context Found (if I remember it right). That happens because it > is tightly coupled with the application. But not to be hard on Home, I do > realize the history of the home object and know it was developed when EL had > no parameters. So I have learned a lot since then and I here are some things > that I can impart to Seam 3. > >> > >> 1. My "Home" now is a "ServiceBean", and I have one for each "Major" > entity, see below. I have really stewed over this over months and months, > and the "Home" of "ServiceBean" should be kept small, focused, reusable, > tested and untouched. It's only task is to update, persist, possibly remove, > or some other functions that are required. In my example below I have custom > close action. Notice also that although these beans are stateful that > doesn't mean everything should be, so in these methods I have the parameter > of what is being needed to be updated, and not a field. In other words I > don't have @In private Job job, I opted for public boolean update(job). > Mostly because, again, I want to make this service bean reusable so whether > I have a #{newJob}, #{copyOfAJob}, or #{managedJob} or whatever component of > job I need to work on I only need one jobServiceBean to cater to all my > jobs, in whatever conversation I am using. I also fire events from here if I > need to do that. ! > > After this is tested, and what I need I usually don't touch it anymore. > If I need to enhance I either use a decorator pattern around it, or enhance > it in an @Observer. I'll email about that later. > >> > >> @Name("jobServiceBean") > >> @Scope(ScopeType.CONVERSATION) > >> public class JobServiceBean implements JobService { > >> private EntityManager entityManager; > >> private StatusMessages statusMessages; > >> > >> @In > >> public void setEntityManager(EntityManager entityManager) { > >> this.entityManager = entityManager; > >> } > >> > >> @In > >> public void setStatusMessages(StatusMessages statusMessages) { > >> this.statusMessages = statusMessages; > >> } > >> > >> public boolean update(Job job) { > >> this.entityManager.flush(); > >> this.statusMessages.add(StatusMessage.Severity.INFO, "Successfully > updated job {0}", job.getName()); > >> return true; > >> } > >> > >> public boolean close(Job job) { > >> job.setJobStatus(JobStatus.CLOSED); > >> this.entityManager.flush(); > >> this.statusMessages.add(StatusMessage.Severity.INFO, "Successfully > closed job {0}", job.getName()); > >> return true; > >> } > >> } > >> > >> 2. One thing you may have noticed from above that there is no 'instance' > field with corresponding getters or setters like the old 'Home'. So the > ServiceBean in my case is not a full crud, but CUD + your own business > methods. That's because that too should be decoupled because we never know > the source of the object is. Is the object created from a factory? from a > copy? is it a mapped component, a managed component? Creation of objects or > loading of objects, or the manufacturing of objects from factories should be > separate from the "home" or in my case the "ServiceBean". > >> > >> (end feedback) > >> > >> -- > >> Dan Allen > >> Principal Software Engineer, Red Hat | Author of Seam in Action > >> Registered Linux User #231597 > >> > >> http://www.google.com/profiles/dan.j.allen#about > >> http://mojavelinux.com > >> http://mojavelinux.com/seaminaction > >> > >> _______________________________________________ > >> forge-dev mailing list > >> forge-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/forge-dev > > > > /max > > http://about.me/maxandersen > > > > > > > > > > _______________________________________________ > > forge-dev mailing list > > forge-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/forge-dev > > _______________________________________________ > seam-dev mailing list > seam-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/seam-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110927/5103ff0d/attachment.html From lightguard.jp at gmail.com Tue Sep 27 11:57:08 2011 From: lightguard.jp at gmail.com (Jason Porter) Date: Tue, 27 Sep 2011 09:57:08 -0600 Subject: [seam-dev] [forge-dev] SAF (aka Entity Framework) idea in Seam 3 In-Reply-To: References: <1316504855.4917.YahooMailNeo@web160812.mail.bf1.yahoo.com> <9BB1592F-4558-484F-99EF-FD825D56E456@redhat.com> Message-ID: <4AA8021C-953A-467E-B25C-D9B7E59597B4@gmail.com> I prefer the idea that there's a class that manages one instance and that's all it does, and another object (or objects) to handle collections of those objects. I think separating them out makes for better reusability. If we'd like to have a save method I'm okay with that, but don't really see the need. Sent from my iPhone On Sep 27, 2011, at 7:32, Jos? Rodolfo Freitas wrote: > Sorry for not being able to post my gist. After writting some "sketches", I realized that I don't have it very clear in my mind yet. > > just to move from zero I posted something: > > https://gist.github.com/1245041 > > It's a really simple example on how we could avoid inheritance, but it's not contemplating a lot of needed features, > so I'm not even near to be convinced with that gist. > > btw, the @AutoHome approach seems very nice. > > > On Thu, Sep 22, 2011 at 2:12 PM, Dan Allen wrote: > Exactly. flush() has a specific purpose and really doesn't belong in boilerplate code. > > - Dan Allen > > Sent from my Android-powered phone: > An open platform for carriers, consumers and developers > > On Sep 22, 2011 11:19 AM, "Max Rydahl Andersen" wrote: > > just one comment: > > > > Calling .flush() on every alteration really should not be promoted as a good practice. > > > > /max > > > > On Sep 22, 2011, at 24:22, Dan Allen wrote: > > > >> Here's some additional feedback I received from a community member a while back...to merge it into this thread. > >> > >> (begin feedback) > >> > >> ...from being burned from 3 seam based customers with apps and maintenance. The "Home" or any other name should be just be put into a grave and slowly cast away to sea ;). It is too heavy and complicated and just about anything inherited (extends) truly causes heartache[Favor Composition over inheritance: Effective Java]. The current seam home has a few super classes above the home and when you try to unit test it (the standard definition of unit-testing including isolation) you get the "No Active Application Context Found (if I remember it right). That happens because it is tightly coupled with the application. But not to be hard on Home, I do realize the history of the home object and know it was developed when EL had no parameters. So I have learned a lot since then and I here are some things that I can impart to Seam 3. > >> > >> 1. My "Home" now is a "ServiceBean", and I have one for each "Major" entity, see below. I have really stewed over this over months and months, and the "Home" of "ServiceBean" should be kept small, focused, reusable, tested and untouched. It's only task is to update, persist, possibly remove, or some other functions that are required. In my example below I have custom close action. Notice also that although these beans are stateful that doesn't mean everything should be, so in these methods I have the parameter of what is being needed to be updated, and not a field. In other words I don't have @In private Job job, I opted for public boolean update(job). Mostly because, again, I want to make this service bean reusable so whether I have a #{newJob}, #{copyOfAJob}, or #{managedJob} or whatever component of job I need to work on I only need one jobServiceBean to cater to all my jobs, in whatever conversation I am using. I also fire events from here if I need to do that. ! > > After this is tested, and what I need I usually don't touch it anymore. If I need to enhance I either use a decorator pattern around it, or enhance it in an @Observer. I'll email about that later. > >> > >> @Name("jobServiceBean") > >> @Scope(ScopeType.CONVERSATION) > >> public class JobServiceBean implements JobService { > >> private EntityManager entityManager; > >> private StatusMessages statusMessages; > >> > >> @In > >> public void setEntityManager(EntityManager entityManager) { > >> this.entityManager = entityManager; > >> } > >> > >> @In > >> public void setStatusMessages(StatusMessages statusMessages) { > >> this.statusMessages = statusMessages; > >> } > >> > >> public boolean update(Job job) { > >> this.entityManager.flush(); > >> this.statusMessages.add(StatusMessage.Severity.INFO, "Successfully updated job {0}", job.getName()); > >> return true; > >> } > >> > >> public boolean close(Job job) { > >> job.setJobStatus(JobStatus.CLOSED); > >> this.entityManager.flush(); > >> this.statusMessages.add(StatusMessage.Severity.INFO, "Successfully closed job {0}", job.getName()); > >> return true; > >> } > >> } > >> > >> 2. One thing you may have noticed from above that there is no 'instance' field with corresponding getters or setters like the old 'Home'. So the ServiceBean in my case is not a full crud, but CUD + your own business methods. That's because that too should be decoupled because we never know the source of the object is. Is the object created from a factory? from a copy? is it a mapped component, a managed component? Creation of objects or loading of objects, or the manufacturing of objects from factories should be separate from the "home" or in my case the "ServiceBean". > >> > >> (end feedback) > >> > >> -- > >> Dan Allen > >> Principal Software Engineer, Red Hat | Author of Seam in Action > >> Registered Linux User #231597 > >> > >> http://www.google.com/profiles/dan.j.allen#about > >> http://mojavelinux.com > >> http://mojavelinux.com/seaminaction > >> > >> _______________________________________________ > >> forge-dev mailing list > >> forge-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/forge-dev > > > > /max > > http://about.me/maxandersen > > > > > > > > > > _______________________________________________ > > forge-dev mailing list > > forge-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/forge-dev > > _______________________________________________ > seam-dev mailing list > seam-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/seam-dev > > > _______________________________________________ > seam-dev mailing list > seam-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/seam-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110927/1fe98cca/attachment-0001.html From max.andersen at redhat.com Tue Sep 27 12:55:58 2011 From: max.andersen at redhat.com (Max Rydahl Andersen) Date: Tue, 27 Sep 2011 18:55:58 +0200 Subject: [seam-dev] [forge-dev] SAF (aka Entity Framework) idea in Seam 3 In-Reply-To: <4AA8021C-953A-467E-B25C-D9B7E59597B4@gmail.com> References: <1316504855.4917.YahooMailNeo@web160812.mail.bf1.yahoo.com> <9BB1592F-4558-484F-99EF-FD825D56E456@redhat.com> <4AA8021C-953A-467E-B25C-D9B7E59597B4@gmail.com> Message-ID: don't use save or saveOrUpdate - those are old Hibernate API methods which doesn't do the same as what update/persist does. The semantics are similar but different enough to not overload the words since it requires a different usage of the API. My 2 cents ;) /max On Sep 27, 2011, at 17:57, Jason Porter wrote: > I prefer the idea that there's a class that manages one instance and that's all it does, and another object (or objects) to handle collections of those objects. I think separating them out makes for better reusability. If we'd like to have a save method I'm okay with that, but don't really see the need. > > Sent from my iPhone > > On Sep 27, 2011, at 7:32, Jos? Rodolfo Freitas wrote: > >> Sorry for not being able to post my gist. After writting some "sketches", I realized that I don't have it very clear in my mind yet. >> >> just to move from zero I posted something: >> >> https://gist.github.com/1245041 >> >> It's a really simple example on how we could avoid inheritance, but it's not contemplating a lot of needed features, >> so I'm not even near to be convinced with that gist. >> >> btw, the @AutoHome approach seems very nice. >> >> >> On Thu, Sep 22, 2011 at 2:12 PM, Dan Allen wrote: >> Exactly. flush() has a specific purpose and really doesn't belong in boilerplate code. >> >> - Dan Allen >> >> Sent from my Android-powered phone: >> An open platform for carriers, consumers and developers >> >> On Sep 22, 2011 11:19 AM, "Max Rydahl Andersen" wrote: >> > just one comment: >> > >> > Calling .flush() on every alteration really should not be promoted as a good practice. >> > >> > /max >> > >> > On Sep 22, 2011, at 24:22, Dan Allen wrote: >> > >> >> Here's some additional feedback I received from a community member a while back...to merge it into this thread. >> >> >> >> (begin feedback) >> >> >> >> ...from being burned from 3 seam based customers with apps and maintenance. The "Home" or any other name should be just be put into a grave and slowly cast away to sea ;). It is too heavy and complicated and just about anything inherited (extends) truly causes heartache[Favor Composition over inheritance: Effective Java]. The current seam home has a few super classes above the home and when you try to unit test it (the standard definition of unit-testing including isolation) you get the "No Active Application Context Found (if I remember it right). That happens because it is tightly coupled with the application. But not to be hard on Home, I do realize the history of the home object and know it was developed when EL had no parameters. So I have learned a lot since then and I here are some things that I can impart to Seam 3. >> >> >> >> 1. My "Home" now is a "ServiceBean", and I have one for each "Major" entity, see below. I have really stewed over this over months and months, and the "Home" of "ServiceBean" should be kept small, focused, reusable, tested and untouched. It's only task is to update, persist, possibly remove, or some other functions that are required. In my example below I have custom close action. Notice also that although these beans are stateful that doesn't mean everything should be, so in these methods I have the parameter of what is being needed to be updated, and not a field. In other words I don't have @In private Job job, I opted for public boolean update(job). Mostly because, again, I want to make this service bean reusable so whether I have a #{newJob}, #{copyOfAJob}, or #{managedJob} or whatever component of job I need to work on I only need one jobServiceBean to cater to all my jobs, in whatever conversation I am using. I also fire events from here if I need to do that. ! >> > After this is tested, and what I need I usually don't touch it anymore. If I need to enhance I either use a decorator pattern around it, or enhance it in an @Observer. I'll email about that later. >> >> >> >> @Name("jobServiceBean") >> >> @Scope(ScopeType.CONVERSATION) >> >> public class JobServiceBean implements JobService { >> >> private EntityManager entityManager; >> >> private StatusMessages statusMessages; >> >> >> >> @In >> >> public void setEntityManager(EntityManager entityManager) { >> >> this.entityManager = entityManager; >> >> } >> >> >> >> @In >> >> public void setStatusMessages(StatusMessages statusMessages) { >> >> this.statusMessages = statusMessages; >> >> } >> >> >> >> public boolean update(Job job) { >> >> this.entityManager.flush(); >> >> this.statusMessages.add(StatusMessage.Severity.INFO, "Successfully updated job {0}", job.getName()); >> >> return true; >> >> } >> >> >> >> public boolean close(Job job) { >> >> job.setJobStatus(JobStatus.CLOSED); >> >> this.entityManager.flush(); >> >> this.statusMessages.add(StatusMessage.Severity.INFO, "Successfully closed job {0}", job.getName()); >> >> return true; >> >> } >> >> } >> >> >> >> 2. One thing you may have noticed from above that there is no 'instance' field with corresponding getters or setters like the old 'Home'. So the ServiceBean in my case is not a full crud, but CUD + your own business methods. That's because that too should be decoupled because we never know the source of the object is. Is the object created from a factory? from a copy? is it a mapped component, a managed component? Creation of objects or loading of objects, or the manufacturing of objects from factories should be separate from the "home" or in my case the "ServiceBean". >> >> >> >> (end feedback) >> >> >> >> -- >> >> Dan Allen >> >> Principal Software Engineer, Red Hat | Author of Seam in Action >> >> Registered Linux User #231597 >> >> >> >> http://www.google.com/profiles/dan.j.allen#about >> >> http://mojavelinux.com >> >> http://mojavelinux.com/seaminaction >> >> >> >> _______________________________________________ >> >> forge-dev mailing list >> >> forge-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/forge-dev >> > >> > /max >> > http://about.me/maxandersen >> > >> > >> > >> > >> > _______________________________________________ >> > forge-dev mailing list >> > forge-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/forge-dev >> >> _______________________________________________ >> seam-dev mailing list >> seam-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/seam-dev >> >> >> _______________________________________________ >> seam-dev mailing list >> seam-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/seam-dev > _______________________________________________ > forge-dev mailing list > forge-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev /max http://about.me/maxandersen From joserodolfo.freitas at gmail.com Tue Sep 27 12:59:43 2011 From: joserodolfo.freitas at gmail.com (=?ISO-8859-1?Q?Jos=E9_Rodolfo_Freitas?=) Date: Tue, 27 Sep 2011 13:59:43 -0300 Subject: [seam-dev] [forge-dev] SAF (aka Entity Framework) idea in Seam 3 In-Reply-To: References: <1316504855.4917.YahooMailNeo@web160812.mail.bf1.yahoo.com> <9BB1592F-4558-484F-99EF-FD825D56E456@redhat.com> <4AA8021C-953A-467E-B25C-D9B7E59597B4@gmail.com> Message-ID: good point. Naming was not my focus here though, it was just a quick example. On Tue, Sep 27, 2011 at 1:55 PM, Max Rydahl Andersen < max.andersen at redhat.com> wrote: > don't use save or saveOrUpdate - those are old Hibernate API methods which > doesn't do the same as what update/persist does. > > The semantics are similar but different enough to not overload the words > since it requires a different usage of the API. > > My 2 cents ;) > > /max > > On Sep 27, 2011, at 17:57, Jason Porter wrote: > > > I prefer the idea that there's a class that manages one instance and > that's all it does, and another object (or objects) to handle collections of > those objects. I think separating them out makes for better reusability. If > we'd like to have a save method I'm okay with that, but don't really see the > need. > > > > Sent from my iPhone > > > > On Sep 27, 2011, at 7:32, Jos? Rodolfo Freitas < > joserodolfo.freitas at gmail.com> wrote: > > > >> Sorry for not being able to post my gist. After writting some > "sketches", I realized that I don't have it very clear in my mind yet. > >> > >> just to move from zero I posted something: > >> > >> https://gist.github.com/1245041 > >> > >> It's a really simple example on how we could avoid inheritance, but > it's not contemplating a lot of needed features, > >> so I'm not even near to be convinced with that gist. > >> > >> btw, the @AutoHome approach seems very nice. > >> > >> > >> On Thu, Sep 22, 2011 at 2:12 PM, Dan Allen > wrote: > >> Exactly. flush() has a specific purpose and really doesn't belong in > boilerplate code. > >> > >> - Dan Allen > >> > >> Sent from my Android-powered phone: > >> An open platform for carriers, consumers and developers > >> > >> On Sep 22, 2011 11:19 AM, "Max Rydahl Andersen" < > max.andersen at redhat.com> wrote: > >> > just one comment: > >> > > >> > Calling .flush() on every alteration really should not be promoted as > a good practice. > >> > > >> > /max > >> > > >> > On Sep 22, 2011, at 24:22, Dan Allen wrote: > >> > > >> >> Here's some additional feedback I received from a community member a > while back...to merge it into this thread. > >> >> > >> >> (begin feedback) > >> >> > >> >> ...from being burned from 3 seam based customers with apps and > maintenance. The "Home" or any other name should be just be put into a grave > and slowly cast away to sea ;). It is too heavy and complicated and just > about anything inherited (extends) truly causes heartache[Favor Composition > over inheritance: Effective Java]. The current seam home has a few super > classes above the home and when you try to unit test it (the standard > definition of unit-testing including isolation) you get the "No Active > Application Context Found (if I remember it right). That happens because it > is tightly coupled with the application. But not to be hard on Home, I do > realize the history of the home object and know it was developed when EL had > no parameters. So I have learned a lot since then and I here are some things > that I can impart to Seam 3. > >> >> > >> >> 1. My "Home" now is a "ServiceBean", and I have one for each "Major" > entity, see below. I have really stewed over this over months and months, > and the "Home" of "ServiceBean" should be kept small, focused, reusable, > tested and untouched. It's only task is to update, persist, possibly remove, > or some other functions that are required. In my example below I have custom > close action. Notice also that although these beans are stateful that > doesn't mean everything should be, so in these methods I have the parameter > of what is being needed to be updated, and not a field. In other words I > don't have @In private Job job, I opted for public boolean update(job). > Mostly because, again, I want to make this service bean reusable so whether > I have a #{newJob}, #{copyOfAJob}, or #{managedJob} or whatever component of > job I need to work on I only need one jobServiceBean to cater to all my > jobs, in whatever conversation I am using. I also fire events from here if I > need to do that. ! > >> > After this is tested, and what I need I usually don't touch it > anymore. If I need to enhance I either use a decorator pattern around it, or > enhance it in an @Observer. I'll email about that later. > >> >> > >> >> @Name("jobServiceBean") > >> >> @Scope(ScopeType.CONVERSATION) > >> >> public class JobServiceBean implements JobService { > >> >> private EntityManager entityManager; > >> >> private StatusMessages statusMessages; > >> >> > >> >> @In > >> >> public void setEntityManager(EntityManager entityManager) { > >> >> this.entityManager = entityManager; > >> >> } > >> >> > >> >> @In > >> >> public void setStatusMessages(StatusMessages statusMessages) { > >> >> this.statusMessages = statusMessages; > >> >> } > >> >> > >> >> public boolean update(Job job) { > >> >> this.entityManager.flush(); > >> >> this.statusMessages.add(StatusMessage.Severity.INFO, "Successfully > updated job {0}", job.getName()); > >> >> return true; > >> >> } > >> >> > >> >> public boolean close(Job job) { > >> >> job.setJobStatus(JobStatus.CLOSED); > >> >> this.entityManager.flush(); > >> >> this.statusMessages.add(StatusMessage.Severity.INFO, "Successfully > closed job {0}", job.getName()); > >> >> return true; > >> >> } > >> >> } > >> >> > >> >> 2. One thing you may have noticed from above that there is no > 'instance' field with corresponding getters or setters like the old 'Home'. > So the ServiceBean in my case is not a full crud, but CUD + your own > business methods. That's because that too should be decoupled because we > never know the source of the object is. Is the object created from a > factory? from a copy? is it a mapped component, a managed component? > Creation of objects or loading of objects, or the manufacturing of objects > from factories should be separate from the "home" or in my case the > "ServiceBean". > >> >> > >> >> (end feedback) > >> >> > >> >> -- > >> >> Dan Allen > >> >> Principal Software Engineer, Red Hat | Author of Seam in Action > >> >> Registered Linux User #231597 > >> >> > >> >> http://www.google.com/profiles/dan.j.allen#about > >> >> http://mojavelinux.com > >> >> http://mojavelinux.com/seaminaction > >> >> > >> >> _______________________________________________ > >> >> forge-dev mailing list > >> >> forge-dev at lists.jboss.org > >> >> https://lists.jboss.org/mailman/listinfo/forge-dev > >> > > >> > /max > >> > http://about.me/maxandersen > >> > > >> > > >> > > >> > > >> > _______________________________________________ > >> > forge-dev mailing list > >> > forge-dev at lists.jboss.org > >> > https://lists.jboss.org/mailman/listinfo/forge-dev > >> > >> _______________________________________________ > >> seam-dev mailing list > >> seam-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/seam-dev > >> > >> > >> _______________________________________________ > >> seam-dev mailing list > >> seam-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/seam-dev > > _______________________________________________ > > forge-dev mailing list > > forge-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/forge-dev > > /max > http://about.me/maxandersen > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110927/c3c34c47/attachment.html From jens.schumann at openknowledge.de Mon Sep 12 11:25:38 2011 From: jens.schumann at openknowledge.de (Jens Schumann) Date: Mon, 12 Sep 2011 15:25:38 -0000 Subject: [seam-dev] [cdi-dev] Enabling extensions In-Reply-To: <5601C05A-9471-4599-B7E6-2F8DA1BE8B26@redhat.com> Message-ID: Hi Pete, >From my experience this is a problem, especially for (partial) integration tests within a maven based build infrastructure. In the end we had to move certain META-INF/services/javax.enterprise.inject.spi.Extension files from extension jars to the final deployment artifact or use System Properties (!) to disable them;(. Jens On 12.09.11 16:51 "Pete Muir" wrote: >Seam team, and others on the CDI EG, > >Looking for feedback on an issue Marius and I discussed in CDI 1.0. This >is potentially an issue - we weren't sure if people had seen it in the >real world, hopefully you may have seen feedback in the forums or at >conferences. > >This relates closely to the interceptor/decorator/alternative enabling >discussion. > >Typically an extension class is packaged in a jar, along with a >META-INF/services/javax.enterprise.inject.spi.Extension file which >enables it. However, this means that an application, or another >extension, has no way of disabling extensions. > >Is this a problem, really? Or just theoretically. >_______________________________________________ >cdi-dev mailing list >cdi-dev at lists.jboss.org >https://lists.jboss.org/mailman/listinfo/cdi-dev