Re: Merging Shale into MyFaces
I did a better version of the tiles-integration for tomahawk (also works with Tiles2 now). regards, Martin On 12/6/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: On Dec 6, 2007 4:50 PM, Kito D. Mann [EMAIL PROTECTED] wrote: Paul, That's good to hear. There's a lot more value that just the testing framework FWIW. I think we've discussed this already. ya, we did Honestly, I think the best thing to do is let Shale continue to exist for the time being and move relevant portions into MyFaces, either as separate subprojects (such as test and dialog) or pieces of other projects. Annotations and Remoting could be part of Tomahawk or common, and the ViewController could be part of Orchestra. I summarized today the same bits, makes sense to me. I'd prefer to see Orchestra's ViewController the one we use :) (Not sure about the Tiles integration stuff.) we don't need that ~~~ Kito D. Mann - Author, JavaServer Faces in Action http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info -Original Message- From: Paul Spencer [mailto:[EMAIL PROTECTED] Sent: Thursday, December 06, 2007 9:59 AM To: MyFaces Development Subject: Re: Merging Shale into MyFaces Matthias, I made this same request, in addition to moving parts or all of Shale into MyFaces, to Wendy Smoak at ApacheCon in Atlanta. She said that she would look into it. Paul Spencer Matthias Wessendorf wrote: It was discussed, that Shale should have a final release; I am +1 on that. snip/ What do you have in mind, other than cutting the release? I may be able to help with the release (depends when etc.). v1.0.5 or v1.1.0 or both? it was now a while, since the last release; and a release (1.0.5 and 1.1.0 IMO) is needed. What happens after such a release? I don't know. Shale is quite now, besides some committs, that you do :-) I am not sure, if all modules should really make it into MyFaces. I can see interest in these Shale-modules: -Dialog -Remoting -Test -Tiger -ViewController What happens to the rest? I don't know; Will they be maintained ? I don't know; snap/ I intend to remain involved with the dialog modules, at the least. nice to hear. I have no problem with making the Shale committers MyFaces committers. Some are already. -M -Rahul -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Merging Shale into MyFaces
From: Matthias Wessendorf [EMAIL PROTECTED] Perhaps, we just should wait, when it comes to Faces 2.x impl and take the bits, as we need them; same is true for Orchestra (like Dialog/VC) as well. Besides that, the Test may be interesting for us, since we use it, and I'd like to see that module stays alive :-) Indeed, you are a committer in both projects so you could make that a reality regardless. -Matthias On Dec 6, 2007 8:34 AM, Matthias Wessendorf wrote: to bring light to this discussion; On Oct 24, 2007 8:15 AM, Martin Marinschek wrote: For me, a merger makes sense. The question is who will do the work, though. yup! That's right. Some reflections on the modules: - ViewController/Dialog: I hope Orchestra can take in what makes sense here (the notion of subflows which I think the Orchestra VC is pretty solid, right now; I personally like it more. What potential makes sense (as an addition) is the Dialog mgr + the XML-W3C-thing (forgot the name :-) ) - Clay: Yes, obviously Facelets has won the race - we should all concentrate our efforts there, so that the JSF community can profit as a whole (and is not splitted) yes, no need for that, sorry to say. - Tiger-extensions: again, this would make sense in Orchestra, as an alternative way of configuring Orchestras beans (and also other beans, of course) to using Spring for the discussion I have the understanding, that Tiger will be used as JSF2 @nnotation solution. We should take that bit for the next impl... :) - test-framework: we've long used it in MyFaces, but for recent tests both Matthias and me have used EasyMock, it is somewhat easier to define changing interface behaviour with EasyMock than with static mock-classes. Still, this is valuable, and should be a separate module in the merger. - validators - no, probably not really please no - s:token: I'd love to have a generic way of preventing duplicated posts. But I guess this is something that Orchestra could eventually handle? apart from that, I don't know much more about Shale - sorry. other bits, that were discussed were: -AppController looks like nobody is really interested in this -Remoting sounds like a nice enhancement; and may be JSF 2.0 (as mentioned by some folks here) -Spring-Integration no need for that (Did I miss a module?) It was discussed, that Shale should have a final release; I am +1 on that. I am not sure, if all modules should really make it into MyFaces. I can see interest in these Shale-modules: -Dialog -Remoting -Test -Tiger -ViewController What happens to the rest? I don't know; Will they be maintained ? I don't know; regards, Martin On 10/22/07, Mario Ivankovits wrote: Ok, so what about having a 'myfaces dormant' project where each module gets added where it seems there is no real maintainer. This could be a place for abandoned sandbox stuff too. I know, the word 'maintainer' is not well placed in the context of an apache community, but in the end I think it would be fair to show to users that no one is really working on an project. Mario -Original Message- From: Grant Smith Date: Monday, Okt 22, 2007 6:02 pm Subject: Re: Merging Shale into MyFaces To: Reply- MyFaces Development To: MyFaces Development Conceptually, I am in favor of a merge. I wouldn't wait for JSF 2.0 to do it, though. +1. On 10/22/07, Matthias Wessendorf wrote:At least, 1 year, that is my guess. So, I agree w/ Kito here -M On 10/22/07, Kito D. Mann wrote: I don't think that's a good idea, since JSF 2.0 is a year or more away ~~~ Kito D. Mann - Author, JavaServer Faces in Action http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info -Original Message- From: Bernhard Slominski [mailto:[EMAIL PROTECTED] Sent: Monday, October 22, 2007 8:41 AM To: '[EMAIL PROTECTED]'; MyFaces Development Subject: AW: Merging Shale into MyFaces Hi all, I guess it makes sense, to make the merger a post JSF 2 project. So all features, which are included in JSF 2 (e.g Remoting) should not move, but just stay in Shale. Also let's see where templating and component development goes before making a decision about Clay. So Shale is then the JSF 1.X add-on framework, when it comes to JSF 2 all Add-Ons move
Re: Merging Shale into MyFaces
It was discussed, that Shale should have a final release; I am +1 on that. snip/ What do you have in mind, other than cutting the release? I may be able to help with the release (depends when etc.). v1.0.5 or v1.1.0 or both? it was now a while, since the last release; and a release (1.0.5 and 1.1.0 IMO) is needed. What happens after such a release? I don't know. Shale is quite now, besides some committs, that you do :-) I am not sure, if all modules should really make it into MyFaces. I can see interest in these Shale-modules: -Dialog -Remoting -Test -Tiger -ViewController What happens to the rest? I don't know; Will they be maintained ? I don't know; snap/ I intend to remain involved with the dialog modules, at the least. nice to hear. I have no problem with making the Shale committers MyFaces committers. Some are already. -M -Rahul -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: Merging Shale into MyFaces
Their is a feature in the SNAPSHOT version of test-framework that reads the implementation's configuration, i.e. faces.xml, when setting up the environment. This feature is valuable when testing against different implementations, i.e. RI 1.1. In tomahawk 1.1.x, I hard coded some of the configuration to enable some of the component testing. This hard coding fails when testing against the RI. At one time I did modify the test to use the SNAPSHOT version of test-framework to run the tests against the RI, but I never committed the works because I did not want to introduce a SNAPSHOT dependency. Move the test-framework into MyFaces and I will commit the work. I request that test-framework be moved into MyFace. Paul Spencer Matthias Wessendorf wrote: to bring light to this discussion; On Oct 24, 2007 8:15 AM, Martin Marinschek [EMAIL PROTECTED] wrote: For me, a merger makes sense. The question is who will do the work, though. yup! That's right. Some reflections on the modules: - ViewController/Dialog: I hope Orchestra can take in what makes sense here (the notion of subflows which I think the Orchestra VC is pretty solid, right now; I personally like it more. What potential makes sense (as an addition) is the Dialog mgr + the XML-W3C-thing (forgot the name :-) ) - Clay: Yes, obviously Facelets has won the race - we should all concentrate our efforts there, so that the JSF community can profit as a whole (and is not splitted) yes, no need for that, sorry to say. - Tiger-extensions: again, this would make sense in Orchestra, as an alternative way of configuring Orchestras beans (and also other beans, of course) to using Spring for the discussion I have the understanding, that Tiger will be used as JSF2 @nnotation solution. We should take that bit for the next impl... :) - test-framework: we've long used it in MyFaces, but for recent tests both Matthias and me have used EasyMock, it is somewhat easier to define changing interface behaviour with EasyMock than with static mock-classes. Still, this is valuable, and should be a separate module in the merger. - validators - no, probably not really please no - s:token: I'd love to have a generic way of preventing duplicated posts. But I guess this is something that Orchestra could eventually handle? apart from that, I don't know much more about Shale - sorry. other bits, that were discussed were: -AppController looks like nobody is really interested in this -Remoting sounds like a nice enhancement; and may be JSF 2.0 (as mentioned by some folks here) -Spring-Integration no need for that (Did I miss a module?) It was discussed, that Shale should have a final release; I am +1 on that. I am not sure, if all modules should really make it into MyFaces. I can see interest in these Shale-modules: -Dialog -Remoting -Test -Tiger -ViewController What happens to the rest? I don't know; Will they be maintained ? I don't know; regards, Martin On 10/22/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Ok, so what about having a 'myfaces dormant' project where each module gets added where it seems there is no real maintainer. This could be a place for abandoned sandbox stuff too. I know, the word 'maintainer' is not well placed in the context of an apache community, but in the end I think it would be fair to show to users that no one is really working on an project. Mario -Original Message- From: Grant Smith [EMAIL PROTECTED] Date: Monday, Okt 22, 2007 6:02 pm Subject: Re: Merging Shale into MyFaces To: Reply-MyFaces Development dev@myfaces.apache.orgTo: MyFaces Development dev@myfaces.apache.org Conceptually, I am in favor of a merge. I wouldn't wait for JSF 2.0 to do it, though. +1. On 10/22/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:At least, 1 year, that is my guess. So, I agree w/ Kito here -M On 10/22/07, Kito D. Mann [EMAIL PROTECTED] wrote: I don't think that's a good idea, since JSF 2.0 is a year or more away ~~~ Kito D. Mann - Author, JavaServer Faces in Action http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info -Original Message- From: Bernhard Slominski [mailto:[EMAIL PROTECTED] Sent: Monday, October 22, 2007 8:41 AM To: '[EMAIL PROTECTED]'; MyFaces Development Subject: AW: Merging Shale into MyFaces Hi all, I guess it makes sense, to make the merger a post JSF 2 project. So all features, which are included in JSF 2 (e.g Remoting) should not move, but just stay in Shale. Also let's see where templating and component development goes before making a decision about Clay. So Shale is then the JSF 1.X add-on framework, when it comes to JSF 2 all Add-Ons move to MyFaces. Bernhard -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Auftrag von Craig McClanahan Gesendet: Montag, 22. Oktober
Re: Merging Shale into MyFaces
we can do that. I'd also like to see this (sub)project stays alive, at Apache ;-) I am not sure, if we need the infra@ guys for the mv. -M On Dec 6, 2007 3:54 PM, Paul Spencer [EMAIL PROTECTED] wrote: Their is a feature in the SNAPSHOT version of test-framework that reads the implementation's configuration, i.e. faces.xml, when setting up the environment. This feature is valuable when testing against different implementations, i.e. RI 1.1. In tomahawk 1.1.x, I hard coded some of the configuration to enable some of the component testing. This hard coding fails when testing against the RI. At one time I did modify the test to use the SNAPSHOT version of test-framework to run the tests against the RI, but I never committed the works because I did not want to introduce a SNAPSHOT dependency. Move the test-framework into MyFaces and I will commit the work. I request that test-framework be moved into MyFace. Paul Spencer Matthias Wessendorf wrote: to bring light to this discussion; On Oct 24, 2007 8:15 AM, Martin Marinschek [EMAIL PROTECTED] wrote: For me, a merger makes sense. The question is who will do the work, though. yup! That's right. Some reflections on the modules: - ViewController/Dialog: I hope Orchestra can take in what makes sense here (the notion of subflows which I think the Orchestra VC is pretty solid, right now; I personally like it more. What potential makes sense (as an addition) is the Dialog mgr + the XML-W3C-thing (forgot the name :-) ) - Clay: Yes, obviously Facelets has won the race - we should all concentrate our efforts there, so that the JSF community can profit as a whole (and is not splitted) yes, no need for that, sorry to say. - Tiger-extensions: again, this would make sense in Orchestra, as an alternative way of configuring Orchestras beans (and also other beans, of course) to using Spring for the discussion I have the understanding, that Tiger will be used as JSF2 @nnotation solution. We should take that bit for the next impl... :) - test-framework: we've long used it in MyFaces, but for recent tests both Matthias and me have used EasyMock, it is somewhat easier to define changing interface behaviour with EasyMock than with static mock-classes. Still, this is valuable, and should be a separate module in the merger. - validators - no, probably not really please no - s:token: I'd love to have a generic way of preventing duplicated posts. But I guess this is something that Orchestra could eventually handle? apart from that, I don't know much more about Shale - sorry. other bits, that were discussed were: -AppController looks like nobody is really interested in this -Remoting sounds like a nice enhancement; and may be JSF 2.0 (as mentioned by some folks here) -Spring-Integration no need for that (Did I miss a module?) It was discussed, that Shale should have a final release; I am +1 on that. I am not sure, if all modules should really make it into MyFaces. I can see interest in these Shale-modules: -Dialog -Remoting -Test -Tiger -ViewController What happens to the rest? I don't know; Will they be maintained ? I don't know; regards, Martin On 10/22/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Ok, so what about having a 'myfaces dormant' project where each module gets added where it seems there is no real maintainer. This could be a place for abandoned sandbox stuff too. I know, the word 'maintainer' is not well placed in the context of an apache community, but in the end I think it would be fair to show to users that no one is really working on an project. Mario -Original Message- From: Grant Smith [EMAIL PROTECTED] Date: Monday, Okt 22, 2007 6:02 pm Subject: Re: Merging Shale into MyFaces To: Reply-MyFaces Development dev@myfaces.apache.orgTo: MyFaces Development dev@myfaces.apache.org Conceptually, I am in favor of a merge. I wouldn't wait for JSF 2.0 to do it, though. +1. On 10/22/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:At least, 1 year, that is my guess. So, I agree w/ Kito here -M On 10/22/07, Kito D. Mann [EMAIL PROTECTED] wrote: I don't think that's a good idea, since JSF 2.0 is a year or more away ~~~ Kito D. Mann - Author, JavaServer Faces in Action http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info -Original Message- From: Bernhard Slominski [mailto:[EMAIL PROTECTED] Sent: Monday, October 22, 2007 8:41 AM To: '[EMAIL PROTECTED]'; MyFaces Development Subject: AW: Merging Shale into MyFaces Hi all, I guess it makes sense, to make the merger a post JSF 2 project. So all features, which are included
Re: Merging Shale into MyFaces
Matthias, I made this same request, in addition to moving parts or all of Shale into MyFaces, to Wendy Smoak at ApacheCon in Atlanta. She said that she would look into it. Paul Spencer Matthias Wessendorf wrote: It was discussed, that Shale should have a final release; I am +1 on that. snip/ What do you have in mind, other than cutting the release? I may be able to help with the release (depends when etc.). v1.0.5 or v1.1.0 or both? it was now a while, since the last release; and a release (1.0.5 and 1.1.0 IMO) is needed. What happens after such a release? I don't know. Shale is quite now, besides some committs, that you do :-) I am not sure, if all modules should really make it into MyFaces. I can see interest in these Shale-modules: -Dialog -Remoting -Test -Tiger -ViewController What happens to the rest? I don't know; Will they be maintained ? I don't know; snap/ I intend to remain involved with the dialog modules, at the least. nice to hear. I have no problem with making the Shale committers MyFaces committers. Some are already. -M -Rahul
Re: Merging Shale into MyFaces
That's cool; I think, I now remember (perhaps I forgot b/c of the cycling bar), you told me about it; We should have a release in shale, before we move/refactor/overhaul things; Let's discuss this release thing on shale-dev ml; -M On Dec 6, 2007 3:58 PM, Paul Spencer [EMAIL PROTECTED] wrote: Matthias, I made this same request, in addition to moving parts or all of Shale into MyFaces, to Wendy Smoak at ApacheCon in Atlanta. She said that she would look into it. Paul Spencer Matthias Wessendorf wrote: It was discussed, that Shale should have a final release; I am +1 on that. snip/ What do you have in mind, other than cutting the release? I may be able to help with the release (depends when etc.). v1.0.5 or v1.1.0 or both? it was now a while, since the last release; and a release (1.0.5 and 1.1.0 IMO) is needed. What happens after such a release? I don't know. Shale is quite now, besides some committs, that you do :-) I am not sure, if all modules should really make it into MyFaces. I can see interest in these Shale-modules: -Dialog -Remoting -Test -Tiger -ViewController What happens to the rest? I don't know; Will they be maintained ? I don't know; snap/ I intend to remain involved with the dialog modules, at the least. nice to hear. I have no problem with making the Shale committers MyFaces committers. Some are already. -M -Rahul -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: Merging Shale into MyFaces
Although I usually prefer dynamic mocks and easymock, I'm interested in the test framework but only in this test module not other modules of shale. On Dec 6, 2007 4:58 PM, Paul Spencer [EMAIL PROTECTED] wrote: Matthias, I made this same request, in addition to moving parts or all of Shale into MyFaces, to Wendy Smoak at ApacheCon in Atlanta. She said that she would look into it. Paul Spencer Matthias Wessendorf wrote: It was discussed, that Shale should have a final release; I am +1 on that. snip/ What do you have in mind, other than cutting the release? I may be able to help with the release (depends when etc.). v1.0.5 or v1.1.0 or both? it was now a while, since the last release; and a release (1.0.5 and 1.1.0 IMO) is needed. What happens after such a release? I don't know. Shale is quite now, besides some committs, that you do :-) I am not sure, if all modules should really make it into MyFaces. I can see interest in these Shale-modules: -Dialog -Remoting -Test -Tiger -ViewController What happens to the rest? I don't know; Will they be maintained ? I don't know; snap/ I intend to remain involved with the dialog modules, at the least. nice to hear. I have no problem with making the Shale committers MyFaces committers. Some are already. -M -Rahul
Re: Merging Shale into MyFaces
Matthias Wessendorf [EMAIL PROTECTED] schrieb: On Dec 6, 2007 4:50 PM, Kito D. Mann [EMAIL PROTECTED] wrote: Annotations and Remoting could be part of Tomahawk or common, and the ViewController could be part of Orchestra. I summarized today the same bits, makes sense to me. I'd prefer to see Orchestra's ViewController the one we use :) I'd rather see a viewcontroller go into one of the common projects (if one is appropriate) and then have Orchestra depend on that. I've always felt that a view-controller is not really a core part of Orchestra's functionality. And a view-controller is useful to many projects that may not want conversation support. Regards, Simon
Re: Merging Shale into MyFaces
I'd rather see a viewcontroller go into one of the common projects (if one is appropriate) and then have Orchestra depend on that. that would be a good idea; I started thinking about REST, to have the viewController call some callbacks. I was inspired about a talk at ApacheCon US on the S2 RESTplugin + codebehind-plugin (which is a view-controller-technology) I've always felt that a view-controller is not really a core part of Orchestra's functionality. And a view-controller is useful to many projects that may not want conversation support. yup, see above Regards, Simon -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
RE: Merging Shale into MyFaces
-Original Message- Their is a feature in the SNAPSHOT version of test-framework that reads the implementation's configuration, i.e. faces.xml, when setting up the environment. This feature is valuable when testing against different implementations, i.e. RI 1.1. In tomahawk 1.1.x, I hard coded some of the configuration to enable some of the component testing. This hard coding fails when testing against the RI. At one time I did modify the test to use the SNAPSHOT version of test-framework to run the tests against the RI, but I never committed the works because I did not want to introduce a SNAPSHOT dependency. Move the test-framework into MyFaces and I will commit the work. -/Original Message- That kind of testing framework-feature is worth a lot. Makes setting up the testing-environment somewhat easier... regards Alexander
RE: Merging Shale into MyFaces
From: Jesse Alexander (KSFH 323) [EMAIL PROTECTED] -Original Message- Their is a feature in the SNAPSHOT version of test-framework that reads the implementation's configuration, i.e. faces.xml, when setting up the environment. This feature is valuable when testing against different implementations, i.e. RI 1.1. In tomahawk 1.1.x, I hard coded some of the configuration to enable some of the component testing. This hard coding fails when testing against the RI. At one time I did modify the test to use the SNAPSHOT version of test-framework to run the tests against the RI, but I never committed the works because I did not want to introduce a SNAPSHOT dependency. Move the test-framework into MyFaces and I will commit the work. -/Original Message- That kind of testing framework-feature is worth a lot. Makes setting up the testing-environment somewhat easier... I agree these types of features are important. I think the test framework is some of Craig's best art. Many of the other shale libraries have been reinvented over several times. This seems to be one that has not. If you have not, please submit a patch. It seems like we could make this kind of thing conditional. http://shale.apache.org/issue-tracking.html Gary regards Alexander
Re: Merging Shale into MyFaces
to bring light to this discussion; On Oct 24, 2007 8:15 AM, Martin Marinschek [EMAIL PROTECTED] wrote: For me, a merger makes sense. The question is who will do the work, though. yup! That's right. Some reflections on the modules: - ViewController/Dialog: I hope Orchestra can take in what makes sense here (the notion of subflows which I think the Orchestra VC is pretty solid, right now; I personally like it more. What potential makes sense (as an addition) is the Dialog mgr + the XML-W3C-thing (forgot the name :-) ) - Clay: Yes, obviously Facelets has won the race - we should all concentrate our efforts there, so that the JSF community can profit as a whole (and is not splitted) yes, no need for that, sorry to say. - Tiger-extensions: again, this would make sense in Orchestra, as an alternative way of configuring Orchestras beans (and also other beans, of course) to using Spring for the discussion I have the understanding, that Tiger will be used as JSF2 @nnotation solution. We should take that bit for the next impl... :) - test-framework: we've long used it in MyFaces, but for recent tests both Matthias and me have used EasyMock, it is somewhat easier to define changing interface behaviour with EasyMock than with static mock-classes. Still, this is valuable, and should be a separate module in the merger. - validators - no, probably not really please no - s:token: I'd love to have a generic way of preventing duplicated posts. But I guess this is something that Orchestra could eventually handle? apart from that, I don't know much more about Shale - sorry. other bits, that were discussed were: -AppController looks like nobody is really interested in this -Remoting sounds like a nice enhancement; and may be JSF 2.0 (as mentioned by some folks here) -Spring-Integration no need for that (Did I miss a module?) It was discussed, that Shale should have a final release; I am +1 on that. I am not sure, if all modules should really make it into MyFaces. I can see interest in these Shale-modules: -Dialog -Remoting -Test -Tiger -ViewController What happens to the rest? I don't know; Will they be maintained ? I don't know; regards, Martin On 10/22/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Ok, so what about having a 'myfaces dormant' project where each module gets added where it seems there is no real maintainer. This could be a place for abandoned sandbox stuff too. I know, the word 'maintainer' is not well placed in the context of an apache community, but in the end I think it would be fair to show to users that no one is really working on an project. Mario -Original Message- From: Grant Smith [EMAIL PROTECTED] Date: Monday, Okt 22, 2007 6:02 pm Subject: Re: Merging Shale into MyFaces To: Reply-MyFaces Development dev@myfaces.apache.orgTo: MyFaces Development dev@myfaces.apache.org Conceptually, I am in favor of a merge. I wouldn't wait for JSF 2.0 to do it, though. +1. On 10/22/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:At least, 1 year, that is my guess. So, I agree w/ Kito here -M On 10/22/07, Kito D. Mann [EMAIL PROTECTED] wrote: I don't think that's a good idea, since JSF 2.0 is a year or more away ~~~ Kito D. Mann - Author, JavaServer Faces in Action http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info -Original Message- From: Bernhard Slominski [mailto:[EMAIL PROTECTED] Sent: Monday, October 22, 2007 8:41 AM To: '[EMAIL PROTECTED]'; MyFaces Development Subject: AW: Merging Shale into MyFaces Hi all, I guess it makes sense, to make the merger a post JSF 2 project. So all features, which are included in JSF 2 (e.g Remoting) should not move, but just stay in Shale. Also let's see where templating and component development goes before making a decision about Clay. So Shale is then the JSF 1.X add-on framework, when it comes to JSF 2 all Add-Ons move to MyFaces. Bernhard -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Auftrag von Craig McClanahan Gesendet: Montag, 22. Oktober 2007 01:48 An: MyFaces Development; Shale Developers List Betreff: Re: Merging Shale into MyFaces * Remoting Unsure, as most of this can be done with PPR too. +1 This is pretty useful and easy to use, and will affect JSF 2.0. A secondary benefit is near-zero config for resource access, gt -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf further stuff: blog: http
Re: Merging Shale into MyFaces
Perhaps, we just should wait, when it comes to Faces 2.x impl and take the bits, as we need them; same is true for Orchestra (like Dialog/VC) as well. Besides that, the Test may be interesting for us, since we use it, and I'd like to see that module stays alive :-) -Matthias On Dec 6, 2007 8:34 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote: to bring light to this discussion; On Oct 24, 2007 8:15 AM, Martin Marinschek [EMAIL PROTECTED] wrote: For me, a merger makes sense. The question is who will do the work, though. yup! That's right. Some reflections on the modules: - ViewController/Dialog: I hope Orchestra can take in what makes sense here (the notion of subflows which I think the Orchestra VC is pretty solid, right now; I personally like it more. What potential makes sense (as an addition) is the Dialog mgr + the XML-W3C-thing (forgot the name :-) ) - Clay: Yes, obviously Facelets has won the race - we should all concentrate our efforts there, so that the JSF community can profit as a whole (and is not splitted) yes, no need for that, sorry to say. - Tiger-extensions: again, this would make sense in Orchestra, as an alternative way of configuring Orchestras beans (and also other beans, of course) to using Spring for the discussion I have the understanding, that Tiger will be used as JSF2 @nnotation solution. We should take that bit for the next impl... :) - test-framework: we've long used it in MyFaces, but for recent tests both Matthias and me have used EasyMock, it is somewhat easier to define changing interface behaviour with EasyMock than with static mock-classes. Still, this is valuable, and should be a separate module in the merger. - validators - no, probably not really please no - s:token: I'd love to have a generic way of preventing duplicated posts. But I guess this is something that Orchestra could eventually handle? apart from that, I don't know much more about Shale - sorry. other bits, that were discussed were: -AppController looks like nobody is really interested in this -Remoting sounds like a nice enhancement; and may be JSF 2.0 (as mentioned by some folks here) -Spring-Integration no need for that (Did I miss a module?) It was discussed, that Shale should have a final release; I am +1 on that. I am not sure, if all modules should really make it into MyFaces. I can see interest in these Shale-modules: -Dialog -Remoting -Test -Tiger -ViewController What happens to the rest? I don't know; Will they be maintained ? I don't know; regards, Martin On 10/22/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Ok, so what about having a 'myfaces dormant' project where each module gets added where it seems there is no real maintainer. This could be a place for abandoned sandbox stuff too. I know, the word 'maintainer' is not well placed in the context of an apache community, but in the end I think it would be fair to show to users that no one is really working on an project. Mario -Original Message- From: Grant Smith [EMAIL PROTECTED] Date: Monday, Okt 22, 2007 6:02 pm Subject: Re: Merging Shale into MyFaces To: Reply-MyFaces Development dev@myfaces.apache.orgTo: MyFaces Development dev@myfaces.apache.org Conceptually, I am in favor of a merge. I wouldn't wait for JSF 2.0 to do it, though. +1. On 10/22/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:At least, 1 year, that is my guess. So, I agree w/ Kito here -M On 10/22/07, Kito D. Mann [EMAIL PROTECTED] wrote: I don't think that's a good idea, since JSF 2.0 is a year or more away ~~~ Kito D. Mann - Author, JavaServer Faces in Action http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info -Original Message- From: Bernhard Slominski [mailto:[EMAIL PROTECTED] Sent: Monday, October 22, 2007 8:41 AM To: '[EMAIL PROTECTED]'; MyFaces Development Subject: AW: Merging Shale into MyFaces Hi all, I guess it makes sense, to make the merger a post JSF 2 project. So all features, which are included in JSF 2 (e.g Remoting) should not move, but just stay in Shale. Also let's see where templating and component development goes before making a decision about Clay. So Shale is then the JSF 1.X add-on framework, when it comes to JSF 2 all Add-Ons move to MyFaces. Bernhard -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Auftrag von Craig McClanahan Gesendet: Montag, 22. Oktober 2007 01:48 An: MyFaces Development; Shale Developers List Betreff: Re: Merging
RE: Merging Shale into MyFaces
-Original Message- From: Martin Marinschek [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 24, 2007 3:16 AM To: MyFaces Development; [EMAIL PROTECTED] Subject: Re: Merging Shale into MyFaces For me, a merger makes sense. Seems almost unanimous :-). The question is who will do the work, though. That's always the question :-). Some reflections on the modules: - ViewController/Dialog: I hope Orchestra can take in what makes sense here (the notion of subflows which I like Orchesta a lot, but I don't think the view controller/dialog features should be tied to Spring - Clay: Yes, obviously Facelets has won the race - we should all concentrate our efforts there, so that the JSF community can profit as a whole (and is not splitted) Facelets definitely needs more resources too. - Tiger-extensions: again, this would make sense in Orchestra, as an alternative way of configuring Orchestras beans (and also other beans, of course) to using Spring I think we'd still need to support standard managed beans, though. - test-framework: we've long used it in MyFaces, but for recent tests both Matthias and me have used EasyMock, it is somewhat easier to define changing interface behaviour with EasyMock than with static mock-classes. Still, this is valuable, and should be a separate module in the merger. Could shale-test be enhanced by using EasyMock? ' - validators - no, probably not really - s:token: I'd love to have a generic way of preventing duplicated posts. But I guess this is something that Orchestra could eventually handle? Honestly, this may be more of a Tomahawk think. Perhaps a specialized form component? apart from that, I don't know much more about Shale - sorry. regards, Martin On 10/22/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Ok, so what about having a 'myfaces dormant' project where each module gets added where it seems there is no real maintainer. This could be a place for abandoned sandbox stuff too. I know, the word 'maintainer' is not well placed in the context of an apache community, but in the end I think it would be fair to show to users that no one is really working on an project. Mario -Original Message- From: Grant Smith [EMAIL PROTECTED] Date: Monday, Okt 22, 2007 6:02 pm Subject: Re: Merging Shale into MyFaces To: Reply-MyFaces Development dev@myfaces.apache.orgTo: MyFaces Development dev@myfaces.apache.org Conceptually, I am in favor of a merge. I wouldn't wait for JSF 2.0 to do it, though. +1. On 10/22/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:At least, 1 year, that is my guess. So, I agree w/ Kito here -M On 10/22/07, Kito D. Mann [EMAIL PROTECTED] wrote: I don't think that's a good idea, since JSF 2.0 is a year or more away ~~~ Kito D. Mann - Author, JavaServer Faces in Action http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info -Original Message- From: Bernhard Slominski [mailto:[EMAIL PROTECTED] Sent: Monday, October 22, 2007 8:41 AM To: '[EMAIL PROTECTED]'; MyFaces Development Subject: AW: Merging Shale into MyFaces Hi all, I guess it makes sense, to make the merger a post JSF 2 project. So all features, which are included in JSF 2 (e.g Remoting) should not move, but just stay in Shale. Also let's see where templating and component development goes before making a decision about Clay. So Shale is then the JSF 1.X add-on framework, when it comes to JSF 2 all Add-Ons move to MyFaces. Bernhard -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Auftrag von Craig McClanahan Gesendet: Montag, 22. Oktober 2007 01:48 An: MyFaces Development; Shale Developers List Betreff: Re: Merging Shale into MyFaces * Remoting Unsure, as most of this can be done with PPR too. +1 This is pretty useful and easy to use, and will affect JSF 2.0. A secondary benefit is near-zero config for resource access, gt -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Merging Shale into MyFaces
- test-framework: we've long used it in MyFaces, but for recent tests both Matthias and me have used EasyMock, it is somewhat easier to define changing interface behaviour with EasyMock than with static mock-classes. Still, this is valuable, and should be a separate module in the merger. Could shale-test be enhanced by using EasyMock? there is JMock support in -M ' - validators - no, probably not really - s:token: I'd love to have a generic way of preventing duplicated posts. But I guess this is something that Orchestra could eventually handle? Honestly, this may be more of a Tomahawk think. Perhaps a specialized form component? apart from that, I don't know much more about Shale - sorry. regards, Martin On 10/22/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Ok, so what about having a 'myfaces dormant' project where each module gets added where it seems there is no real maintainer. This could be a place for abandoned sandbox stuff too. I know, the word 'maintainer' is not well placed in the context of an apache community, but in the end I think it would be fair to show to users that no one is really working on an project. Mario -Original Message- From: Grant Smith [EMAIL PROTECTED] Date: Monday, Okt 22, 2007 6:02 pm Subject: Re: Merging Shale into MyFaces To: Reply-MyFaces Development dev@myfaces.apache.orgTo: MyFaces Development dev@myfaces.apache.org Conceptually, I am in favor of a merge. I wouldn't wait for JSF 2.0 to do it, though. +1. On 10/22/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:At least, 1 year, that is my guess. So, I agree w/ Kito here -M On 10/22/07, Kito D. Mann [EMAIL PROTECTED] wrote: I don't think that's a good idea, since JSF 2.0 is a year or more away ~~~ Kito D. Mann - Author, JavaServer Faces in Action http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info -Original Message- From: Bernhard Slominski [mailto:[EMAIL PROTECTED] Sent: Monday, October 22, 2007 8:41 AM To: '[EMAIL PROTECTED]'; MyFaces Development Subject: AW: Merging Shale into MyFaces Hi all, I guess it makes sense, to make the merger a post JSF 2 project. So all features, which are included in JSF 2 (e.g Remoting) should not move, but just stay in Shale. Also let's see where templating and component development goes before making a decision about Clay. So Shale is then the JSF 1.X add-on framework, when it comes to JSF 2 all Add-Ons move to MyFaces. Bernhard -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Auftrag von Craig McClanahan Gesendet: Montag, 22. Oktober 2007 01:48 An: MyFaces Development; Shale Developers List Betreff: Re: Merging Shale into MyFaces * Remoting Unsure, as most of this can be done with PPR too. +1 This is pretty useful and easy to use, and will affect JSF 2.0. A secondary benefit is near-zero config for resource access, gt -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org
Re: Merging Shale into MyFaces
- ViewController/Dialog: I hope Orchestra can take in what makes sense here (the notion of subflows which I like Orchesta a lot, but I don't think the view controller/dialog features should be tied to Spring I see two configuration options - Spring and annotations. The managed bean-facility just won't cope with scope=conversation! - test-framework: we've long used it in MyFaces, but for recent tests both Matthias and me have used EasyMock, it is somewhat easier to define changing interface behaviour with EasyMock than with static mock-classes. Still, this is valuable, and should be a separate module in the merger. Could shale-test be enhanced by using EasyMock? nope. I don't think so - it's very much static mocks or dynamic mocks (well, with a few exceptions, were you actually need implementation classes). I don't see much of a mixture here. regards, Martin
Re: Merging Shale into MyFaces
For me, a merger makes sense. The question is who will do the work, though. Some reflections on the modules: - ViewController/Dialog: I hope Orchestra can take in what makes sense here (the notion of subflows which - Clay: Yes, obviously Facelets has won the race - we should all concentrate our efforts there, so that the JSF community can profit as a whole (and is not splitted) - Tiger-extensions: again, this would make sense in Orchestra, as an alternative way of configuring Orchestras beans (and also other beans, of course) to using Spring - test-framework: we've long used it in MyFaces, but for recent tests both Matthias and me have used EasyMock, it is somewhat easier to define changing interface behaviour with EasyMock than with static mock-classes. Still, this is valuable, and should be a separate module in the merger. - validators - no, probably not really - s:token: I'd love to have a generic way of preventing duplicated posts. But I guess this is something that Orchestra could eventually handle? apart from that, I don't know much more about Shale - sorry. regards, Martin On 10/22/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Ok, so what about having a 'myfaces dormant' project where each module gets added where it seems there is no real maintainer. This could be a place for abandoned sandbox stuff too. I know, the word 'maintainer' is not well placed in the context of an apache community, but in the end I think it would be fair to show to users that no one is really working on an project. Mario -Original Message- From: Grant Smith [EMAIL PROTECTED] Date: Monday, Okt 22, 2007 6:02 pm Subject: Re: Merging Shale into MyFaces To: Reply-MyFaces Development dev@myfaces.apache.orgTo: MyFaces Development dev@myfaces.apache.org Conceptually, I am in favor of a merge. I wouldn't wait for JSF 2.0 to do it, though. +1. On 10/22/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:At least, 1 year, that is my guess. So, I agree w/ Kito here -M On 10/22/07, Kito D. Mann [EMAIL PROTECTED] wrote: I don't think that's a good idea, since JSF 2.0 is a year or more away ~~~ Kito D. Mann - Author, JavaServer Faces in Action http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info -Original Message- From: Bernhard Slominski [mailto:[EMAIL PROTECTED] Sent: Monday, October 22, 2007 8:41 AM To: '[EMAIL PROTECTED]'; MyFaces Development Subject: AW: Merging Shale into MyFaces Hi all, I guess it makes sense, to make the merger a post JSF 2 project. So all features, which are included in JSF 2 (e.g Remoting) should not move, but just stay in Shale. Also let's see where templating and component development goes before making a decision about Clay. So Shale is then the JSF 1.X add-on framework, when it comes to JSF 2 all Add-Ons move to MyFaces. Bernhard -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Auftrag von Craig McClanahan Gesendet: Montag, 22. Oktober 2007 01:48 An: MyFaces Development; Shale Developers List Betreff: Re: Merging Shale into MyFaces * Remoting Unsure, as most of this can be done with PPR too. +1 This is pretty useful and easy to use, and will affect JSF 2.0. A secondary benefit is near-zero config for resource access, gt -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
RE: Merging Shale into MyFaces
enhancing (but not overstuffing, KISS) Orchestra makes sense. No use to split the libraries further. - add the subflows - add the s:token (double posting) other parts: no preference regards Alexander -Original Message- From: Martin Marinschek [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 24, 2007 9:16 AM To: MyFaces Development; [EMAIL PROTECTED] Subject: Re: Merging Shale into MyFaces For me, a merger makes sense. The question is who will do the work, though. Some reflections on the modules: - ViewController/Dialog: I hope Orchestra can take in what makes sense here (the notion of subflows which - Clay: Yes, obviously Facelets has won the race - we should all concentrate our efforts there, so that the JSF community can profit as a whole (and is not splitted) - Tiger-extensions: again, this would make sense in Orchestra, as an alternative way of configuring Orchestras beans (and also other beans, of course) to using Spring - test-framework: we've long used it in MyFaces, but for recent tests both Matthias and me have used EasyMock, it is somewhat easier to define changing interface behaviour with EasyMock than with static mock-classes. Still, this is valuable, and should be a separate module in the merger. - validators - no, probably not really - s:token: I'd love to have a generic way of preventing duplicated posts. But I guess this is something that Orchestra could eventually handle? apart from that, I don't know much more about Shale - sorry. regards, Martin On 10/22/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Ok, so what about having a 'myfaces dormant' project where each module gets added where it seems there is no real maintainer. This could be a place for abandoned sandbox stuff too. I know, the word 'maintainer' is not well placed in the context of an apache community, but in the end I think it would be fair to show to users that no one is really working on an project. Mario -Original Message- From: Grant Smith [EMAIL PROTECTED] Date: Monday, Okt 22, 2007 6:02 pm Subject: Re: Merging Shale into MyFaces To: Reply-MyFaces Development dev@myfaces.apache.orgTo: MyFaces Development dev@myfaces.apache.org Conceptually, I am in favor of a merge. I wouldn't wait for JSF 2.0 to do it, though. +1. On 10/22/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:At least, 1 year, that is my guess. So, I agree w/ Kito here -M On 10/22/07, Kito D. Mann [EMAIL PROTECTED] wrote: I don't think that's a good idea, since JSF 2.0 is a year or more away ~~~ Kito D. Mann - Author, JavaServer Faces in Action http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info -Original Message- From: Bernhard Slominski [mailto:[EMAIL PROTECTED] Sent: Monday, October 22, 2007 8:41 AM To: '[EMAIL PROTECTED]'; MyFaces Development Subject: AW: Merging Shale into MyFaces Hi all, I guess it makes sense, to make the merger a post JSF 2 project. So all features, which are included in JSF 2 (e.g Remoting) should not move, but just stay in Shale. Also let's see where templating and component development goes before making a decision about Clay. So Shale is then the JSF 1.X add-on framework, when it comes to JSF 2 all Add-Ons move to MyFaces. Bernhard -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Auftrag von Craig McClanahan Gesendet: Montag, 22. Oktober 2007 01:48 An: MyFaces Development; Shale Developers List Betreff: Re: Merging Shale into MyFaces * Remoting Unsure, as most of this can be done with PPR too. +1 This is pretty useful and easy to use, and will affect JSF 2.0. A secondary benefit is near-zero config for resource access, gt -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Merging Shale into MyFaces
On 10/21/07, Craig McClanahan [EMAIL PROTECTED] wrote: big-snip/ * Dialog Manager * Dialog Manager (Basic Implementation) * Dialog Manager (SCXML Implementation) The Dialog Manager might be a next step for MyFaces Orchestra. Anyway, I hope that one of the original developers is still there to help out with things. +0 I like the idea of integrating this with Orchestra, although I'm not convinced that Spring should be a requirement to use this feature. If that's the case, you might as well use Spring Web Flow. The thing I like most about Shale Dialogs is that you really can abstract a significant amount of detail behind a common dialog interface, and then pick a back end implementation with varying sets of capabilities (and dependencies). Early on in Orchestra's life, I had suggested to Mario that it would be cool to have an adapter so you could Orchestra as your dialog implementation :-). snap/ While I'm on neither of the PMCs, I continue to be interested in Shale dialogs. And as long as I'm around, someone will try to answer user queries etc. -Rahul Longer term, this territory is going to get addressed by Web Beans (JSR-299), which is likely to include all the scope stuff (and more than Dialog has), coupled with annotation based dependency injection. But I've always felt that support for scopes other than request/session/application *really* belongs in the servlet spec so all Java web technologies can use it ... snip/
Re: Merging Shale into MyFaces
On 10/21/07, Craig McClanahan [EMAIL PROTECTED] wrote: * Tiles Integration See Clay. +0 I'll abstain here and since I don't know much about the Tiles side of things. Let's just say that I think Tiles integration should just work in MyFaces and Shale. Likely relevant for historical Struts1 users who want to stick with JSP as their view technology. I'm not sure how relevant even this is presently. Tiles 2 is so far removed from Struts-Tiles that there would still be a significant learning curve/porting effort. We support the idea of a Struts-Tiles compatibility layer, but to my knowledge, no work has been done to that end. Greg
RE: Merging Shale into MyFaces
I don't think that's a good idea, since JSF 2.0 is a year or more away ~~~ Kito D. Mann - Author, JavaServer Faces in Action http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info -Original Message- From: Bernhard Slominski [mailto:[EMAIL PROTECTED] Sent: Monday, October 22, 2007 8:41 AM To: '[EMAIL PROTECTED]'; MyFaces Development Subject: AW: Merging Shale into MyFaces Hi all, I guess it makes sense, to make the merger a post JSF 2 project. So all features, which are included in JSF 2 (e.g Remoting) should not move, but just stay in Shale. Also let's see where templating and component development goes before making a decision about Clay. So Shale is then the JSF 1.X add-on framework, when it comes to JSF 2 all Add-Ons move to MyFaces. Bernhard -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Auftrag von Craig McClanahan Gesendet: Montag, 22. Oktober 2007 01:48 An: MyFaces Development; Shale Developers List Betreff: Re: Merging Shale into MyFaces * Remoting Unsure, as most of this can be done with PPR too. +1 This is pretty useful and easy to use, and will affect JSF 2.0. A secondary benefit is near-zero config for resource access, particularly for resources provided in a jar file instead of as exploded files in a WAR. Until JSF 2 comes along, that's pretty useful all by itself. Craig
Re: Merging Shale into MyFaces
At least, 1 year, that is my guess. So, I agree w/ Kito here -M On 10/22/07, Kito D. Mann [EMAIL PROTECTED] wrote: I don't think that's a good idea, since JSF 2.0 is a year or more away ~~~ Kito D. Mann - Author, JavaServer Faces in Action http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info -Original Message- From: Bernhard Slominski [mailto:[EMAIL PROTECTED] Sent: Monday, October 22, 2007 8:41 AM To: '[EMAIL PROTECTED]'; MyFaces Development Subject: AW: Merging Shale into MyFaces Hi all, I guess it makes sense, to make the merger a post JSF 2 project. So all features, which are included in JSF 2 (e.g Remoting) should not move, but just stay in Shale. Also let's see where templating and component development goes before making a decision about Clay. So Shale is then the JSF 1.X add-on framework, when it comes to JSF 2 all Add-Ons move to MyFaces. Bernhard -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Auftrag von Craig McClanahan Gesendet: Montag, 22. Oktober 2007 01:48 An: MyFaces Development; Shale Developers List Betreff: Re: Merging Shale into MyFaces * Remoting Unsure, as most of this can be done with PPR too. +1 This is pretty useful and easy to use, and will affect JSF 2.0. A secondary benefit is near-zero config for resource access, particularly for resources provided in a jar file instead of as exploded files in a WAR. Until JSF 2 comes along, that's pretty useful all by itself. Craig -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org
Re: Merging Shale into MyFaces
Conceptually, I am in favor of a merge. I wouldn't wait for JSF 2.0 to do it, though. +1. On 10/22/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: At least, 1 year, that is my guess. So, I agree w/ Kito here -M On 10/22/07, Kito D. Mann [EMAIL PROTECTED] wrote: I don't think that's a good idea, since JSF 2.0 is a year or more away ~~~ Kito D. Mann - Author, JavaServer Faces in Action http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info -Original Message- From: Bernhard Slominski [mailto:[EMAIL PROTECTED] Sent: Monday, October 22, 2007 8:41 AM To: '[EMAIL PROTECTED]'; MyFaces Development Subject: AW: Merging Shale into MyFaces Hi all, I guess it makes sense, to make the merger a post JSF 2 project. So all features, which are included in JSF 2 (e.g Remoting) should not move, but just stay in Shale. Also let's see where templating and component development goes before making a decision about Clay. So Shale is then the JSF 1.X add-on framework, when it comes to JSF 2 all Add-Ons move to MyFaces. Bernhard -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Auftrag von Craig McClanahan Gesendet: Montag, 22. Oktober 2007 01:48 An: MyFaces Development; Shale Developers List Betreff: Re: Merging Shale into MyFaces * Remoting Unsure, as most of this can be done with PPR too. +1 This is pretty useful and easy to use, and will affect JSF 2.0. A secondary benefit is near-zero config for resource access, particularly for resources provided in a jar file instead of as exploded files in a WAR. Until JSF 2 comes along, that's pretty useful all by itself. Craig -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- Grant Smith
RE: Merging Shale into MyFaces
-Original Message- From: Bernhard Slominski [mailto:[EMAIL PROTECTED] Sent: Monday, October 22, 2007 12:33 PM To: '[EMAIL PROTECTED]' Subject: AW: Merging Shale into MyFaces The spec develops over the time so even it's not finsihed we roughly know what will be in it, it's getting clearer when time moves on. Maybe for the merger we don't have to set a hard dependency on JSF2, but it doesn't make sense to me to migrate any features which are not needed anymore in the near furture like Remoting. Seems to me it'd be easy to implement JSF 2.0 in MyFaces if we're already maintaining a similar code base... -Ursprüngliche Nachricht- Von: Kito D. Mann [mailto:[EMAIL PROTECTED] Gesendet: Montag, 22. Oktober 2007 17:49 An: [EMAIL PROTECTED] Betreff: RE: Merging Shale into MyFaces I don't think that's a good idea, since JSF 2.0 is a year or more away ~~~ Kito D. Mann - Author, JavaServer Faces in Action http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info -Original Message- From: Bernhard Slominski [mailto:[EMAIL PROTECTED] Sent: Monday, October 22, 2007 8:41 AM To: '[EMAIL PROTECTED]'; MyFaces Development Subject: AW: Merging Shale into MyFaces Hi all, I guess it makes sense, to make the merger a post JSF 2 project. So all features, which are included in JSF 2 (e.g Remoting) should not move, but just stay in Shale. Also let's see where templating and component development goes before making a decision about Clay. So Shale is then the JSF 1.X add-on framework, when it comes to JSF 2 all Add-Ons move to MyFaces. Bernhard
Re: Merging Shale into MyFaces
Ok, so what about having a 'myfaces dormant' project where each module gets added where it seems there is no real maintainer. This could be a place for abandoned sandbox stuff too. I know, the word 'maintainer' is not well placed in the context of an apache community, but in the end I think it would be fair to show to users that no one is really working on an project. Mario -Original Message- From: Grant Smith [EMAIL PROTECTED] Date: Monday, Okt 22, 2007 6:02 pm Subject: Re: Merging Shale into MyFaces To: Reply-MyFaces Development dev@myfaces.apache.orgTo: MyFaces Development dev@myfaces.apache.org Conceptually, I am in favor of a merge. I wouldn't wait for JSF 2.0 to do it, though. +1. On 10/22/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:At least, 1 year, that is my guess. So, I agree w/ Kito here -M On 10/22/07, Kito D. Mann [EMAIL PROTECTED] wrote: I don't think that's a good idea, since JSF 2.0 is a year or more away ~~~ Kito D. Mann - Author, JavaServer Faces in Action http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info -Original Message- From: Bernhard Slominski [mailto:[EMAIL PROTECTED] Sent: Monday, October 22, 2007 8:41 AM To: '[EMAIL PROTECTED]'; MyFaces Development Subject: AW: Merging Shale into MyFaces Hi all, I guess it makes sense, to make the merger a post JSF 2 project. So all features, which are included in JSF 2 (e.g Remoting) should not move, but just stay in Shale. Also let's see where templating and component development goes before making a decision about Clay. So Shale is then the JSF 1.X add-on framework, when it comes to JSF 2 all Add-Ons move to MyFaces. Bernhard -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Auftrag von Craig McClanahan Gesendet: Montag, 22. Oktober 2007 01:48 An: MyFaces Development; Shale Developers List Betreff: Re: Merging Shale into MyFaces * Remoting Unsure, as most of this can be done with PPR too. +1 This is pretty useful and easy to use, and will affect JSF 2.0. A secondary benefit is near-zero config for resource access, gt
Re: Merging Shale into MyFaces
Mario Ivankovits wrote: Hi! I sent out an e-mail to the Shale mailing list a week or so ago about the possibility of merging Shale with MyFaces. Development of Shale has become somewhat stale, and I'd rather see MyFaces pickup the pieces than have the code base atrophy The overwhelming consensus for the Shale list is yes (and Craig is no exception). What does the MyFaces PMC think? I am +1. I think we just have to define which modules we would like to take over: (BTW, this list is not to offend anyone, if this might happen, then sorry in advance - it might be just due to not sensitively enough choosen english wording.) * Application Controller Don't know. I thought action oriented frameworks are outdated, though, Seam seems to introduce this paradigm again too. * Clay Don't know. I am happy that we (I) moved away from html to components. * Core Library Might be a must have * Dialog Manager * Dialog Manager (Basic Implementation) * Dialog Manager (SCXML Implementation) The Dialog Manager might be a next step for MyFaces Orchestra. Anyway, I hope that one of the original developers is still there to help out with things. * Remoting Unsure, as most of this can be done with PPR too. * Spring Integration Unsure, I didn't get whats the advantage to the intregration with Spring * Test Framework Must have I think * Tiger Extensions Interesting, however, I'd like to tell everyone to use Spring as MB facility. And then Spring needs to provide such annotations (which are already existent I think) * Tiles Integration See Clay. * Validator Support A generic client/server validation library for JSF would be REALLY nice. Just, I don't like the idea just having a single component for this (val:commonsValidator), at least, this one needs to be extended. * View Controller This needs to be reviewed and merged with the Orchestra one if possible I am not going to vote an any of these components yet, first, I'd like to see a discussion about them. The reason is simple, even MyFaces has some man/women power problems currently I think. If no one is willing to pick up one of these modules they are dead in MyFaces land too. Point is, that too many dormand modules in MyFaces might harm the MyFaces community. We might create a dormand section where we move those modules then to express that we are waiting for someone with some urge to pick them up again. Ciao, Mario
Re: Merging Shale into MyFaces
By accident I sent my answer to [EMAIL PROTECTED] only. If possible, we should discuss this topic just in [EMAIL PROTECTED], no? I'd like to invent every Shale developer not yet at [EMAIL PROTECTED] to subscribe there too. Is this an option? Ciao, Mario Kito D. Mann schrieb: Hello everyone, I sent out an e-mail to the Shale mailing list a week or so ago about the possibility of merging Shale with MyFaces. Development of Shale has become somewhat stale, and I'd rather see MyFaces pickup the pieces than have the code base atrophy The overwhelming consensus for the Shale list is yes (and Craig is no exception). What does the MyFaces PMC think? ~~~ Kito D. Mann - Author, JavaServer Faces in Action http://www.virtua.com/ http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.jsfcentral.com/ http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
RE: Merging Shale into MyFaces
Hi! I sent out an e-mail to the Shale mailing list a week or so ago about the possibility of merging Shale with MyFaces. Development of Shale has become somewhat stale, and I'd rather see MyFaces pickup the pieces than have the code base atrophy The overwhelming consensus for the Shale list is yes (and Craig is no exception). What does the MyFaces PMC think? I am +1. I'm not on the PMC, but I wanted to state +1 for the record. From dealing with students and clients, I think this would be a good thing for JSF. I think we just have to define which modules we would like to take over: (BTW, this list is not to offend anyone, if this might happen, then sorry in advance - it might be just due to not sensitively enough choosen english wording.) * Application Controller Don't know. I thought action oriented frameworks are outdated, though, Seam seems to introduce this paradigm again too. -1. It's probably better to integrate any sort of direct request processing into the Remoting support (I know it's currently implemented using the Application Controller, but that's an implementation detail). Also, I don't know if anyone actually uses this. * Clay Don't know. I am happy that we (I) moved away from html to components. -1. Although I know Clay has some supporters, Facelets and JSFTemplating are going to affect JSF 2.0 the most. I'd love to see some of the Clay people help out with Facelets, actually. * Core Library Might be a must have +1 * Dialog Manager * Dialog Manager (Basic Implementation) * Dialog Manager (SCXML Implementation) The Dialog Manager might be a next step for MyFaces Orchestra. Anyway, I hope that one of the original developers is still there to help out with things. +0 I like the idea of integrating this with Orchestra, although I'm not convinced that Spring should be a requirement to use this feature. If that's the case, you might as well use Spring Web Flow. * Remoting Unsure, as most of this can be done with PPR too. +1 This is pretty useful and easy to use, and will affect JSF 2.0. * Spring Integration Unsure, I didn't get whats the advantage to the intregration with Spring -1 This is pretty useless now as far as I can tell. * Test Framework Must have I think +1 * Tiger Extensions Interesting, however, I'd like to tell everyone to use Spring as MB facility. And then Spring needs to provide such annotations (which are already existent I think) +1 This will serve as a blueprint for JSF 2.0, and it's quite useful. Although it's nice to use Spring, not everybody does, and we shouldn't force people to do so. * Tiles Integration See Clay. +0 I'll abstain here and since I don't know much about the Tiles side of things. Let's just say that I think Tiles integration should just work in MyFaces and Shale. * Validator Support A generic client/server validation library for JSF would be REALLY nice. Just, I don't like the idea just having a single component for this (val:commonsValidator), at least, this one needs to be extended. -1 I haven't heard of too many people using this these days, since Ajax is usually easier to do these days. If this is a big desire by the community, it'd make more sense to integrate it as a proper set of validators or components. * View Controller This needs to be reviewed and merged with the Orchestra one if possible +1 This is a requirement, I think. ~~~ Kito D. Mann - Author, JavaServer Faces in Action http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
Re: Merging Shale into MyFaces
+1 from me, but only if my logo contest entry is retroactively promoted to the official Shale logo. http://shale.apache.org/logo-contest.html Dennis Byrne On 10/20/07, Kito D. Mann [EMAIL PROTECTED] wrote: Hello everyone, I sent out an e-mail to the Shale mailing list a week or so ago about the possibility of merging Shale with MyFaces. Development of Shale has become somewhat stale, and I'd rather see MyFaces pickup the pieces than have the code base atrophy The overwhelming consensus for the Shale list is yes (and Craig is no exception). What does the MyFaces PMC think? ~~~ Kito D. Mann - Author, JavaServer Faces in Action http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com http://www.jsfcentral.com/ - JavaServer Faces FAQ, news, and info -- Dennis Byrne
