RE: AW: slf4j and myfaces
Start voting? ;-) From: Gerhard Petracek [mailto:gerhard.petra...@gmail.com] Sent: Saturday, June 06, 2009 11:45 AM To: MyFaces Development Subject: Re: AW: slf4j and myfaces yes the -1 vote would be a veto in view of slf4j - no agreement - we would vote about jul. or as mario suggested - let's start voting about jul. @mario: yes - i'll wait until monday for sure. and we should vote a bit longer than usual - due to holidays (+ it's an important topic for all myfaces projects) regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2009/6/6 Ganesh gan...@j4fry.orgmailto:gan...@j4fry.org Hi, we could also vote first about slf4j and everybody who prefers jul should vote -1 if we don't have a majority for slf4j, we have to vote about jul. is that ok for everybody? From http://www.apache.org/foundation/voting.html my understanding of a -1 vote is different from this. Vetos A code-modification proposal may be stopped dead in its tracks by a -1 vote by a qualified voter. This constitutes a veto, and it cannot be overruled nor overridden by anyone. Vetos stand until and unless withdrawn by their casters. To prevent vetos from being used capriciously, they must be accompanied by a technical justification showing why the change is bad (opens a security exposure, negatively affects performance, etc.). A veto without a justification is invalid and has no weight. Better use the fraction system for voting on the logging system: * +0: 'I don't feel strongly about it, but I'm okey with this.' * -0: 'I won't get in the way, but I'd rather we didn't do this.' * -0.5: 'I don't like this idea, but I can't find any rational justification for my feelings.' * ++1: 'Wow! I like this! Let's do it!' * -0.9: 'I really don't like this, but I'm not going to stand in the way if everyone else wants to go ahead with it.' * +0.9: 'This is a cool idea and i like it, but I don't have time/the skills necessary to help out.' Best regards, Ganesh
Re: [MyFaces 2.0] discussion on alpha plans
Michael Concini schrieb: All, I thought it might be a good time to raise the issue of solidifying a plan for the MyFaces 2.0 alpha release now that we've had a little time to work with the release candidate draft of the spec. What are the thoughts in the community with respect to what should be included in an alpha release as well as what the time frame should be for a release. If we can come up with a target date as well as specific 2.0 features we want to target for inclusion, that should help in prioritizing the remaining work. From my end, I'd love to see a working runtime in some form by the end of August if that's reasonable. As for content, that is definitely more of an open question. Here is my top list of what I would like to see be at least partially functional for an alpha release. -backwards compatibility with JSF 1.x apps -base support for facelets and composite components -AJAX support (should hopefully be in pretty good shape here thanks to Ganesh and team) -System event support -Partial view traversal Thoughts/concerns/objections? -Mike None from my side not sure how far Ganesh is with his ajax tag! The scripts already are in pretty good shape and functionalitywise well ahead of the RI ;-) As for partial Tree traversal minor sidequestion? Has anyone started to work on this, because I have started to implement the partial visit context (I have to recheck the jira for this, because I opened an issue for this under partial render response issue 2116/2241)! https://issues.apache.org/jira/browse/MYFACES-2241 I will commit my code around tomorrow, it is basically done but needs some testing! Werner
Re: [MyFaces 2.0] discussion on alpha plans
Matthias Wessendorf schrieb: Hey mike, I agree that we should try to get an *alpha* out of the door. Full ack, I personally think the biggest priority for now is to get a working release so that we can start to test and fix the entire thing. As for now we have a load of parts, many of them already working well, but the full integration picture is missing. (Well I have not tried to run the entire thing standalone for now so my current knowledge might be wrong) Werner
Re: Re: [MyFaces 2.0] discussion on alpha plans
Hi, The end of my extremely busy project is near, so I should have more time to work on MyFaces. My last work was on the annotation processing stuff, but AFAIK, Leonardo has continued this work. @Leonardo: What's the current state? Something else, some weeks ago, there was a discussion about restructuring the SVN, but that was delayed to enable Leonardo to do a release. Maybe this is a good time for the restructuring, before starting with the real work. Maybe we should also cleanup the build. Now Shale has been moved to the attic, we can upgrade the Shale mocks to 2.0. Then we can try to make all tests pass. We might also standardize on a testing framework (JUnit or TestNG) to simplify things... When all tests are up and running, the build process should be more smooth. /JK On Jun 9, 2009 1:07am, Matthias Wessendorf mat...@apache.org wrote: Hey mike, I agree that we should try to get an *alpha* out of the door. Main mantra is: release often, release early q: what is the state on the facelets support, currently ? -Matthias On Mon, Jun 8, 2009 at 2:11 PM, Michael concinimconc...@gmail.com wrote: All, I thought it might be a good time to raise the issue of solidifying a plan for the MyFaces 2.0 alpha release now that we've had a little time to work with the release candidate draft of the spec. What are the thoughts in the community with respect to what should be included in an alpha release as well as what the time frame should be for a release. If we can come up with a target date as well as specific 2.0 features we want to target for inclusion, that should help in prioritizing the remaining work. From my end, I'd love to see a working runtime in some form by the end of August if that's reasonable. As for content, that is definitely more of an open question. Here is my top list of what I would like to see be at least partially functional for an alpha release. -backwards compatibility with JSF 1.x apps -base support for facelets and composite components -AJAX support (should hopefully be in pretty good shape here thanks to Ganesh and team) -System event support -Partial view traversal Thoughts/concerns/objections? -Mike -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [MyFaces 2.0] discussion on alpha plans
Wasn't there a plan to have some of the partial tree traversal work done as part of the Google Summer of Code? I seem to recall some discussion around this awhile back (don't have time to dig through the mailing list archives right now to check). Does anybody remember what the plan was with Google SoC? Werner Punz wrote: Michael Concini schrieb: All, I thought it might be a good time to raise the issue of solidifying a plan for the MyFaces 2.0 alpha release now that we've had a little time to work with the release candidate draft of the spec. What are the thoughts in the community with respect to what should be included in an alpha release as well as what the time frame should be for a release. If we can come up with a target date as well as specific 2.0 features we want to target for inclusion, that should help in prioritizing the remaining work. From my end, I'd love to see a working runtime in some form by the end of August if that's reasonable. As for content, that is definitely more of an open question. Here is my top list of what I would like to see be at least partially functional for an alpha release. -backwards compatibility with JSF 1.x apps -base support for facelets and composite components -AJAX support (should hopefully be in pretty good shape here thanks to Ganesh and team) -System event support -Partial view traversal Thoughts/concerns/objections? -Mike None from my side not sure how far Ganesh is with his ajax tag! The scripts already are in pretty good shape and functionalitywise well ahead of the RI ;-) As for partial Tree traversal minor sidequestion? Has anyone started to work on this, because I have started to implement the partial visit context (I have to recheck the jira for this, because I opened an issue for this under partial render response issue 2116/2241)! https://issues.apache.org/jira/browse/MYFACES-2241 I will commit my code around tomorrow, it is basically done but needs some testing! Werner
Re: [MyFaces 2.0] discussion on alpha plans
On Tue, Jun 9, 2009 at 5:07 AM, Werner Punzwerner.p...@gmail.com wrote: Matthias Wessendorf schrieb: Hey mike, I agree that we should try to get an *alpha* out of the door. Full ack, I personally think the biggest priority for now is to get a working release so that we can start to test and fix the entire thing. As for now we have a load of parts, many of them already working well, but the full integration picture is missing. (Well I have not tried to run the entire thing standalone for now so my current knowledge might be wrong) Werner That was what I was thinking as well. I think most of the focus has been on filling the gaps but how well those pieces work together is rather unknown. Curtiss Howard
Re: [MyFaces 2.0] discussion on alpha plans
Michael Concini schrieb: Wasn't there a plan to have some of the partial tree traversal work done as part of the Google Summer of Code? I seem to recall some discussion around this awhile back (don't have time to dig through the mailing list archives right now to check). Does anybody remember what the plan was with Google SoC? Interesting question, but I assume I only have a small subset of the needed functionality implemented, the one we need for PPR so, I will commit my tomorrow as soon as I have tested it, whoever wants to do something in GSOC can pick it up and refine it. But have in mind, my work currently only coveres the area of providing a PartialVisitContext so that I have a complete state for PPR in this area! If someone comes with a better solution I dont have any problem dropping the code again ;-) Werner Werner Punz wrote: Michael Concini schrieb: All, I thought it might be a good time to raise the issue of solidifying a plan for the MyFaces 2.0 alpha release now that we've had a little time to work with the release candidate draft of the spec. What are the thoughts in the community with respect to what should be included in an alpha release as well as what the time frame should be for a release. If we can come up with a target date as well as specific 2.0 features we want to target for inclusion, that should help in prioritizing the remaining work. From my end, I'd love to see a working runtime in some form by the end of August if that's reasonable. As for content, that is definitely more of an open question. Here is my top list of what I would like to see be at least partially functional for an alpha release. -backwards compatibility with JSF 1.x apps -base support for facelets and composite components -AJAX support (should hopefully be in pretty good shape here thanks to Ganesh and team) -System event support -Partial view traversal Thoughts/concerns/objections? -Mike None from my side not sure how far Ganesh is with his ajax tag! The scripts already are in pretty good shape and functionalitywise well ahead of the RI ;-) As for partial Tree traversal minor sidequestion? Has anyone started to work on this, because I have started to implement the partial visit context (I have to recheck the jira for this, because I opened an issue for this under partial render response issue 2116/2241)! https://issues.apache.org/jira/browse/MYFACES-2241 I will commit my code around tomorrow, it is basically done but needs some testing! Werner
Re: [MyFaces 2.0] discussion on alpha plans
On Tue, Jun 9, 2009 at 5:15 AM, Michael Concinimconc...@gmail.com wrote: Wasn't there a plan to have some of the partial tree traversal work done as part of the Google Summer of Code? I seem to recall some discussion around this awhile back (don't have time to dig through the mailing list archives right now to check). Does anybody remember what the plan was with Google SoC? I think there was some of that - however I am sure there was no student for doing that :-) Or was there one ? -Matthias Werner Punz wrote: Michael Concini schrieb: All, I thought it might be a good time to raise the issue of solidifying a plan for the MyFaces 2.0 alpha release now that we've had a little time to work with the release candidate draft of the spec. What are the thoughts in the community with respect to what should be included in an alpha release as well as what the time frame should be for a release. If we can come up with a target date as well as specific 2.0 features we want to target for inclusion, that should help in prioritizing the remaining work. From my end, I'd love to see a working runtime in some form by the end of August if that's reasonable. As for content, that is definitely more of an open question. Here is my top list of what I would like to see be at least partially functional for an alpha release. -backwards compatibility with JSF 1.x apps -base support for facelets and composite components -AJAX support (should hopefully be in pretty good shape here thanks to Ganesh and team) -System event support -Partial view traversal Thoughts/concerns/objections? -Mike None from my side not sure how far Ganesh is with his ajax tag! The scripts already are in pretty good shape and functionalitywise well ahead of the RI ;-) As for partial Tree traversal minor sidequestion? Has anyone started to work on this, because I have started to implement the partial visit context (I have to recheck the jira for this, because I opened an issue for this under partial render response issue 2116/2241)! https://issues.apache.org/jira/browse/MYFACES-2241 I will commit my code around tomorrow, it is basically done but needs some testing! Werner -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[Trinidad]Share static data between web-projects
Hello, Im using two web-projects with trinidad. I want both projects to have the same style, but with only on file for .css and for each image. What I dont want is to duplicate the files and copy them around the different projects. I tried to extract the files that should be shared in another project so both web-projects can use this projects to get their stylesheets and images but I cant get this to work. The projects cant find the stylesheet. What do I have to do, to get this to work? Or is there any other way I could use to reach the goal of having only one .css file for several web-projects? Mit freundlichen Grüßen Ricardo Rog SoftProject GmbH Am Erlengraben 3 | DE 76275 Ettlingen Tel +49 7243 561 75 211 Fax +49 7243 561 75 199 E-mail mailto:ricardo@softproject.de ricardo@softproject.de www.softproject.de - Amtsgericht Mannheim HRB-Nr. 202147 Sitz der Gesellschaft: Ettlingen Geschäftsführer: Dipl. Wirt.-Ing. Dirk Detmer
Re: [MyFaces 2.0] discussion on alpha plans
regarding tree visitor, this may help: https://issues.apache.org/jira/browse/TRINIDAD-1368 -Matthias On Tue, Jun 9, 2009 at 6:37 AM, Werner Punzwerner.p...@gmail.com wrote: Michael Concini schrieb: Wasn't there a plan to have some of the partial tree traversal work done as part of the Google Summer of Code? I seem to recall some discussion around this awhile back (don't have time to dig through the mailing list archives right now to check). Does anybody remember what the plan was with Google SoC? Interesting question, but I assume I only have a small subset of the needed functionality implemented, the one we need for PPR so, I will commit my tomorrow as soon as I have tested it, whoever wants to do something in GSOC can pick it up and refine it. But have in mind, my work currently only coveres the area of providing a PartialVisitContext so that I have a complete state for PPR in this area! If someone comes with a better solution I dont have any problem dropping the code again ;-) Werner Werner Punz wrote: Michael Concini schrieb: All, I thought it might be a good time to raise the issue of solidifying a plan for the MyFaces 2.0 alpha release now that we've had a little time to work with the release candidate draft of the spec. What are the thoughts in the community with respect to what should be included in an alpha release as well as what the time frame should be for a release. If we can come up with a target date as well as specific 2.0 features we want to target for inclusion, that should help in prioritizing the remaining work. From my end, I'd love to see a working runtime in some form by the end of August if that's reasonable. As for content, that is definitely more of an open question. Here is my top list of what I would like to see be at least partially functional for an alpha release. -backwards compatibility with JSF 1.x apps -base support for facelets and composite components -AJAX support (should hopefully be in pretty good shape here thanks to Ganesh and team) -System event support -Partial view traversal Thoughts/concerns/objections? -Mike None from my side not sure how far Ganesh is with his ajax tag! The scripts already are in pretty good shape and functionalitywise well ahead of the RI ;-) As for partial Tree traversal minor sidequestion? Has anyone started to work on this, because I have started to implement the partial visit context (I have to recheck the jira for this, because I opened an issue for this under partial render response issue 2116/2241)! https://issues.apache.org/jira/browse/MYFACES-2241 I will commit my code around tomorrow, it is basically done but needs some testing! Werner -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [MyFaces 2.0] discussion on alpha plans
Matthias Wessendorf schrieb: regarding tree visitor, this may help: https://issues.apache.org/jira/browse/TRINIDAD-1368 Thanks for the link, I will get it and compare it to what I have... I assume there wont be too much which I still can integrated in the PartialVisitContext since I am rather optimized already and bound by the spec! Werner -Matthias On Tue, Jun 9, 2009 at 6:37 AM, Werner Punzwerner.p...@gmail.com wrote: Michael Concini schrieb: Wasn't there a plan to have some of the partial tree traversal work done as part of the Google Summer of Code? I seem to recall some discussion around this awhile back (don't have time to dig through the mailing list archives right now to check). Does anybody remember what the plan was with Google SoC? Interesting question, but I assume I only have a small subset of the needed functionality implemented, the one we need for PPR so, I will commit my tomorrow as soon as I have tested it, whoever wants to do something in GSOC can pick it up and refine it. But have in mind, my work currently only coveres the area of providing a PartialVisitContext so that I have a complete state for PPR in this area! If someone comes with a better solution I dont have any problem dropping the code again ;-) Werner Werner Punz wrote: Michael Concini schrieb: All, I thought it might be a good time to raise the issue of solidifying a plan for the MyFaces 2.0 alpha release now that we've had a little time to work with the release candidate draft of the spec. What are the thoughts in the community with respect to what should be included in an alpha release as well as what the time frame should be for a release. If we can come up with a target date as well as specific 2.0 features we want to target for inclusion, that should help in prioritizing the remaining work. From my end, I'd love to see a working runtime in some form by the end of August if that's reasonable. As for content, that is definitely more of an open question. Here is my top list of what I would like to see be at least partially functional for an alpha release. -backwards compatibility with JSF 1.x apps -base support for facelets and composite components -AJAX support (should hopefully be in pretty good shape here thanks to Ganesh and team) -System event support -Partial view traversal Thoughts/concerns/objections? -Mike None from my side not sure how far Ganesh is with his ajax tag! The scripts already are in pretty good shape and functionalitywise well ahead of the RI ;-) As for partial Tree traversal minor sidequestion? Has anyone started to work on this, because I have started to implement the partial visit context (I have to recheck the jira for this, because I opened an issue for this under partial render response issue 2116/2241)! https://issues.apache.org/jira/browse/MYFACES-2241 I will commit my code around tomorrow, it is basically done but needs some testing! Werner
Re: [MyFaces 2.0] discussion on alpha plans
Hi, On my side I'll try to work and finish Facelets part within 2 weeks, fater than that is impossible for me atm. Regards, ~ Simon On Tue, Jun 9, 2009 at 9:53 AM, Werner Punz werner.p...@gmail.com wrote: Matthias Wessendorf schrieb: regarding tree visitor, this may help: https://issues.apache.org/jira/browse/TRINIDAD-1368 Thanks for the link, I will get it and compare it to what I have... I assume there wont be too much which I still can integrated in the PartialVisitContext since I am rather optimized already and bound by the spec! Werner -Matthias On Tue, Jun 9, 2009 at 6:37 AM, Werner Punzwerner.p...@gmail.com wrote: Michael Concini schrieb: Wasn't there a plan to have some of the partial tree traversal work done as part of the Google Summer of Code? I seem to recall some discussion around this awhile back (don't have time to dig through the mailing list archives right now to check). Does anybody remember what the plan was with Google SoC? Interesting question, but I assume I only have a small subset of the needed functionality implemented, the one we need for PPR so, I will commit my tomorrow as soon as I have tested it, whoever wants to do something in GSOC can pick it up and refine it. But have in mind, my work currently only coveres the area of providing a PartialVisitContext so that I have a complete state for PPR in this area! If someone comes with a better solution I dont have any problem dropping the code again ;-) Werner Werner Punz wrote: Michael Concini schrieb: All, I thought it might be a good time to raise the issue of solidifying a plan for the MyFaces 2.0 alpha release now that we've had a little time to work with the release candidate draft of the spec. What are the thoughts in the community with respect to what should be included in an alpha release as well as what the time frame should be for a release. If we can come up with a target date as well as specific 2.0 features we want to target for inclusion, that should help in prioritizing the remaining work. From my end, I'd love to see a working runtime in some form by the end of August if that's reasonable. As for content, that is definitely more of an open question. Here is my top list of what I would like to see be at least partially functional for an alpha release. -backwards compatibility with JSF 1.x apps -base support for facelets and composite components -AJAX support (should hopefully be in pretty good shape here thanks to Ganesh and team) -System event support -Partial view traversal Thoughts/concerns/objections? -Mike None from my side not sure how far Ganesh is with his ajax tag! The scripts already are in pretty good shape and functionalitywise well ahead of the RI ;-) As for partial Tree traversal minor sidequestion? Has anyone started to work on this, because I have started to implement the partial visit context (I have to recheck the jira for this, because I opened an issue for this under partial render response issue 2116/2241)! https://issues.apache.org/jira/browse/MYFACES-2241 I will commit my code around tomorrow, it is basically done but needs some testing! Werner
Re: [MyFaces 2.0] discussion on alpha plans
Hi, Facelets are apache 2.0 licensed, why do we reinvent them? Best regards, Ganesh Simon Lessard schrieb: Hi, On my side I'll try to work and finish Facelets part within 2 weeks, fater than that is impossible for me atm. Regards, ~ Simon On Tue, Jun 9, 2009 at 9:53 AM, Werner Punz werner.p...@gmail.com mailto:werner.p...@gmail.com wrote: Matthias Wessendorf schrieb: regarding tree visitor, this may help: https://issues.apache.org/jira/browse/TRINIDAD-1368 Thanks for the link, I will get it and compare it to what I have... I assume there wont be too much which I still can integrated in the PartialVisitContext since I am rather optimized already and bound by the spec! Werner -Matthias On Tue, Jun 9, 2009 at 6:37 AM, Werner Punzwerner.p...@gmail.com mailto:werner.p...@gmail.com wrote: Michael Concini schrieb: Wasn't there a plan to have some of the partial tree traversal work done as part of the Google Summer of Code? I seem to recall some discussion around this awhile back (don't have time to dig through the mailing list archives right now to check). Does anybody remember what the plan was with Google SoC? Interesting question, but I assume I only have a small subset of the needed functionality implemented, the one we need for PPR so, I will commit my tomorrow as soon as I have tested it, whoever wants to do something in GSOC can pick it up and refine it. But have in mind, my work currently only coveres the area of providing a PartialVisitContext so that I have a complete state for PPR in this area! If someone comes with a better solution I dont have any problem dropping the code again ;-) Werner Werner Punz wrote: Michael Concini schrieb: All, I thought it might be a good time to raise the issue of solidifying a plan for the MyFaces 2.0 alpha release now that we've had a little time to work with the release candidate draft of the spec. What are the thoughts in the community with respect to what should be included in an alpha release as well as what the time frame should be for a release. If we can come up with a target date as well as specific 2.0 features we want to target for inclusion, that should help in prioritizing the remaining work. From my end, I'd love to see a working runtime in some form by the end of August if that's reasonable. As for content, that is definitely more of an open question. Here is my top list of what I would like to see be at least partially functional for an alpha release. -backwards compatibility with JSF 1.x apps -base support for facelets and composite components -AJAX support (should hopefully be in pretty good shape here thanks to Ganesh and team) -System event support -Partial view traversal Thoughts/concerns/objections? -Mike None from my side not sure how far Ganesh is with his ajax tag! The scripts already are in pretty good shape and functionalitywise well ahead of the RI ;-) As for partial Tree traversal minor sidequestion? Has anyone started to work on this, because I have started to implement the partial visit context (I have to recheck the jira for this, because I opened an issue for this under partial render response issue 2116/2241)! https://issues.apache.org/jira/browse/MYFACES-2241 I will commit my code around tomorrow, it is basically done but needs some testing! Werner
Re: [MyFaces 2.0] discussion on alpha plans
On Tue, Jun 9, 2009 at 8:20 AM, Ganeshgan...@j4fry.org wrote: Hi, Facelets are apache 2.0 licensed, correct why do we reinvent them? they added stuff for JSF 2.0 e.g. composite:interface etc (but didn't put it into the Apache licensed version) Best regards, Ganesh Simon Lessard schrieb: Hi, On my side I'll try to work and finish Facelets part within 2 weeks, fater than that is impossible for me atm. Regards, ~ Simon On Tue, Jun 9, 2009 at 9:53 AM, Werner Punz werner.p...@gmail.com mailto:werner.p...@gmail.com wrote: Matthias Wessendorf schrieb: regarding tree visitor, this may help: https://issues.apache.org/jira/browse/TRINIDAD-1368 Thanks for the link, I will get it and compare it to what I have... I assume there wont be too much which I still can integrated in the PartialVisitContext since I am rather optimized already and bound by the spec! Werner -Matthias On Tue, Jun 9, 2009 at 6:37 AM, Werner Punzwerner.p...@gmail.com mailto:werner.p...@gmail.com wrote: Michael Concini schrieb: Wasn't there a plan to have some of the partial tree traversal work done as part of the Google Summer of Code? I seem to recall some discussion around this awhile back (don't have time to dig through the mailing list archives right now to check). Does anybody remember what the plan was with Google SoC? Interesting question, but I assume I only have a small subset of the needed functionality implemented, the one we need for PPR so, I will commit my tomorrow as soon as I have tested it, whoever wants to do something in GSOC can pick it up and refine it. But have in mind, my work currently only coveres the area of providing a PartialVisitContext so that I have a complete state for PPR in this area! If someone comes with a better solution I dont have any problem dropping the code again ;-) Werner Werner Punz wrote: Michael Concini schrieb: All, I thought it might be a good time to raise the issue of solidifying a plan for the MyFaces 2.0 alpha release now that we've had a little time to work with the release candidate draft of the spec. What are the thoughts in the community with respect to what should be included in an alpha release as well as what the time frame should be for a release. If we can come up with a target date as well as specific 2.0 features we want to target for inclusion, that should help in prioritizing the remaining work. From my end, I'd love to see a working runtime in some form by the end of August if that's reasonable. As for content, that is definitely more of an open question. Here is my top list of what I would like to see be at least partially functional for an alpha release. -backwards compatibility with JSF 1.x apps -base support for facelets and composite components -AJAX support (should hopefully be in pretty good shape here thanks to Ganesh and team) -System event support -Partial view traversal Thoughts/concerns/objections? -Mike None from my side not sure how far Ganesh is with his ajax tag! The scripts already are in pretty good shape and functionalitywise well ahead of the RI ;-) As for partial Tree traversal minor sidequestion? Has anyone started to work on this, because I have started to implement the partial visit context (I have to recheck the jira for this, because I opened an issue for this under partial render response issue 2116/2241)! https://issues.apache.org/jira/browse/MYFACES-2241 I will commit my code around tomorrow, it is basically done
Re: [MyFaces 2.0] discussion on alpha plans
We use the Facelets codebase, we just have to rename the package (already done), use the HandlerDelegate ... thing ... and implement the Facelets VDL. Those are not part of standard Facelets with existing ASL 2.0 code. ~ Simon On Tue, Jun 9, 2009 at 11:22 AM, Matthias Wessendorf mat...@apache.orgwrote: On Tue, Jun 9, 2009 at 8:20 AM, Ganeshgan...@j4fry.org wrote: Hi, Facelets are apache 2.0 licensed, correct why do we reinvent them? they added stuff for JSF 2.0 e.g. composite:interface etc (but didn't put it into the Apache licensed version) Best regards, Ganesh Simon Lessard schrieb: Hi, On my side I'll try to work and finish Facelets part within 2 weeks, fater than that is impossible for me atm. Regards, ~ Simon On Tue, Jun 9, 2009 at 9:53 AM, Werner Punz werner.p...@gmail.com mailto:werner.p...@gmail.com wrote: Matthias Wessendorf schrieb: regarding tree visitor, this may help: https://issues.apache.org/jira/browse/TRINIDAD-1368 Thanks for the link, I will get it and compare it to what I have... I assume there wont be too much which I still can integrated in the PartialVisitContext since I am rather optimized already and bound by the spec! Werner -Matthias On Tue, Jun 9, 2009 at 6:37 AM, Werner Punzwerner.p...@gmail.com mailto:werner.p...@gmail.com wrote: Michael Concini schrieb: Wasn't there a plan to have some of the partial tree traversal work done as part of the Google Summer of Code? I seem to recall some discussion around this awhile back (don't have time to dig through the mailing list archives right now to check). Does anybody remember what the plan was with Google SoC? Interesting question, but I assume I only have a small subset of the needed functionality implemented, the one we need for PPR so, I will commit my tomorrow as soon as I have tested it, whoever wants to do something in GSOC can pick it up and refine it. But have in mind, my work currently only coveres the area of providing a PartialVisitContext so that I have a complete state for PPR in this area! If someone comes with a better solution I dont have any problem dropping the code again ;-) Werner Werner Punz wrote: Michael Concini schrieb: All, I thought it might be a good time to raise the issue of solidifying a plan for the MyFaces 2.0 alpha release now that we've had a little time to work with the release candidate draft of the spec. What are the thoughts in the community with respect to what should be included in an alpha release as well as what the time frame should be for a release. If we can come up with a target date as well as specific 2.0 features we want to target for inclusion, that should help in prioritizing the remaining work. From my end, I'd love to see a working runtime in some form by the end of August if that's reasonable. As for content, that is definitely more of an open question. Here is my top list of what I would like to see be at least partially functional for an alpha release. -backwards compatibility with JSF 1.x apps -base support for facelets and composite components -AJAX support (should hopefully be in pretty good shape here thanks to Ganesh and team) -System event support -Partial view traversal Thoughts/concerns/objections? -Mike None from my side not sure how far Ganesh is with his ajax tag! The scripts already are in pretty good shape and functionalitywise well ahead of the RI ;-) As for partial Tree traversal minor sidequestion? Has anyone started to work on this, because I
Re: [MyFaces 2.0] discussion on alpha plans
Hi Good to hear that facelets part will be committed soon. I hope to start working on javax.faces.behavior api and continue contribute on other parts of myfaces core 2.0 (for example implement partial state saving) as soon as tomahawk be released (planned on next week). regards Leonardo Uribe 2009/6/9 Simon Lessard simon.lessar...@gmail.com We use the Facelets codebase, we just have to rename the package (already done), use the HandlerDelegate ... thing ... and implement the Facelets VDL. Those are not part of standard Facelets with existing ASL 2.0 code. ~ Simon On Tue, Jun 9, 2009 at 11:22 AM, Matthias Wessendorf mat...@apache.orgwrote: On Tue, Jun 9, 2009 at 8:20 AM, Ganeshgan...@j4fry.org wrote: Hi, Facelets are apache 2.0 licensed, correct why do we reinvent them? they added stuff for JSF 2.0 e.g. composite:interface etc (but didn't put it into the Apache licensed version) Best regards, Ganesh Simon Lessard schrieb: Hi, On my side I'll try to work and finish Facelets part within 2 weeks, fater than that is impossible for me atm. Regards, ~ Simon On Tue, Jun 9, 2009 at 9:53 AM, Werner Punz werner.p...@gmail.com mailto:werner.p...@gmail.com wrote: Matthias Wessendorf schrieb: regarding tree visitor, this may help: https://issues.apache.org/jira/browse/TRINIDAD-1368 Thanks for the link, I will get it and compare it to what I have... I assume there wont be too much which I still can integrated in the PartialVisitContext since I am rather optimized already and bound by the spec! Werner -Matthias On Tue, Jun 9, 2009 at 6:37 AM, Werner Punzwerner.p...@gmail.com mailto:werner.p...@gmail.com wrote: Michael Concini schrieb: Wasn't there a plan to have some of the partial tree traversal work done as part of the Google Summer of Code? I seem to recall some discussion around this awhile back (don't have time to dig through the mailing list archives right now to check). Does anybody remember what the plan was with Google SoC? Interesting question, but I assume I only have a small subset of the needed functionality implemented, the one we need for PPR so, I will commit my tomorrow as soon as I have tested it, whoever wants to do something in GSOC can pick it up and refine it. But have in mind, my work currently only coveres the area of providing a PartialVisitContext so that I have a complete state for PPR in this area! If someone comes with a better solution I dont have any problem dropping the code again ;-) Werner Werner Punz wrote: Michael Concini schrieb: All, I thought it might be a good time to raise the issue of solidifying a plan for the MyFaces 2.0 alpha release now that we've had a little time to work with the release candidate draft of the spec. What are the thoughts in the community with respect to what should be included in an alpha release as well as what the time frame should be for a release. If we can come up with a target date as well as specific 2.0 features we want to target for inclusion, that should help in prioritizing the remaining work. From my end, I'd love to see a working runtime in some form by the end of August if that's reasonable. As for content, that is definitely more of an open question. Here is my top list of what I would like to see be at least partially functional for an alpha release. -backwards compatibility with JSF 1.x apps -base support for facelets and composite components -AJAX support (should hopefully be in pretty good shape here thanks to Ganesh and team) -System event support -Partial view traversal Thoughts/concerns/objections? -Mike None from my side not sure how far Ganesh is
[jira] Commented: (TOMAHAWK-1108) MultipartRequestWrapper doesn't handle request parameters correctly in JSF 1.2/JSP 2.1
[ https://issues.apache.org/jira/browse/TOMAHAWK-1108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12717773#action_12717773 ] Leonardo Uribe commented on TOMAHAWK-1108: -- Thanks a lot to Ben Smith for provide this patch MultipartRequestWrapper doesn't handle request parameters correctly in JSF 1.2/JSP 2.1 -- Key: TOMAHAWK-1108 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1108 Project: MyFaces Tomahawk Issue Type: Bug Components: ExtensionsFilter Affects Versions: 1.1.6 Environment: RI 1.2.1, tomahawk 1.1.6, Tomcat 6.0.14, Java 1.5 Reporter: Ben Smith Assignee: Leonardo Uribe Fix For: 1.1.9-SNAPSHOT Attachments: MultipartRequestWrapper.java, TOMAHAWK-1108.patch The getParameter*() methods of MultipartRequestWrapper don't work correctly in Tomcat 6/JSP 2.1(at least). I think the problem applies to parameters in an included file, but it may apply in other places, too. To reproduce the problem, create a jsp file that includes another jsp file and uses jsp:param / to pass a parameter to the included file. When the extension filter is active (i.e. a form with enctype=multipart/form-data is submitted), the parameter will not be available in the included file. The problem is that MultipartRequestWrapper only parses the request once, so it doesn't pick up the new request parameters in the included file. I was able to fix the problem by modifying parseRequest() to only retrieve the FileItem parameters and then the getParameter*() methods to call through to the wrapped request getParameter*() as necessary. I don't know enough about all of this to know whether or not my fix is the right way to do it but I'll attach my version of MultipartRequestWrapper.java -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TOMAHAWK-1108) MultipartRequestWrapper doesn't handle request parameters correctly in JSF 1.2/JSP 2.1
[ https://issues.apache.org/jira/browse/TOMAHAWK-1108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved TOMAHAWK-1108. -- Resolution: Fixed Fix Version/s: 1.1.9-SNAPSHOT Assignee: Leonardo Uribe I reviewed the patch and it works. I did some small modifications and comments. Definitively it is clear that the assumption that query params are the same from start of the request is wrong, because the user can use jsp:include + jsp:param to add query params. But note that the params decoded when the request is parsed takes precedence over request.getParameterMap, because this ones are content parameters. MultipartRequestWrapper doesn't handle request parameters correctly in JSF 1.2/JSP 2.1 -- Key: TOMAHAWK-1108 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1108 Project: MyFaces Tomahawk Issue Type: Bug Components: ExtensionsFilter Affects Versions: 1.1.6 Environment: RI 1.2.1, tomahawk 1.1.6, Tomcat 6.0.14, Java 1.5 Reporter: Ben Smith Assignee: Leonardo Uribe Fix For: 1.1.9-SNAPSHOT Attachments: MultipartRequestWrapper.java, TOMAHAWK-1108.patch The getParameter*() methods of MultipartRequestWrapper don't work correctly in Tomcat 6/JSP 2.1(at least). I think the problem applies to parameters in an included file, but it may apply in other places, too. To reproduce the problem, create a jsp file that includes another jsp file and uses jsp:param / to pass a parameter to the included file. When the extension filter is active (i.e. a form with enctype=multipart/form-data is submitted), the parameter will not be available in the included file. The problem is that MultipartRequestWrapper only parses the request once, so it doesn't pick up the new request parameters in the included file. I was able to fix the problem by modifying parseRequest() to only retrieve the FileItem parameters and then the getParameter*() methods to call through to the wrapped request getParameter*() as necessary. I don't know enough about all of this to know whether or not my fix is the right way to do it but I'll attach my version of MultipartRequestWrapper.java -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release Tobago 1.0.21
Hi, +1 regards, Volker 2009/6/8 Udo Schnurpfeil u...@schnurpfeil.de: Hi, here is my +1 Regards Udo Bernd Bohmann schrieb: Hello, I would like to release Tobago 1.0.21 For a detail list please consult the release notes: http://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310273styleName=Htmlversion=12313470 The version is available at the staging location and the revision number of the release is 782305 and tagged as tobago-1.0.21. Staging distribution: http://people.apache.org/~bommel/repo Staging repository: http://people.apache.org/~bommel/repo The Vote is open for 72h. [ ] +1 [ ] +0 [ ] -1 -- inexso - information exchange solutions GmbH Bismarckstraße 13 | 26122 Oldenburg Tel.: +49 441 4082 356 | FAX: +49 441 4082 355 | www.inexso.de
[VOTE] jul instead of commons-logging
hi, short description: this first vote is about the switch from commons-logging (cl) to java.util.logging (jul). it's a binding vote for the next releases of all myfaces libs which are currently using commons-logging. so e.g. trinidad isn't affected. details are available at [1] if there won't be a majority, we will open a second vote (switch from commons-logging to slf4j). [ ] +1 for replacing cl with jul [ ] +0 [ ] -1 for keeping cl or to force a second vote for slf4j as replacement regards, gerhard [1] http://www.nabble.com/slf4j-and-myfaces-td23890255.html
Re: [VOTE] jul instead of commons-logging
+0.75 On Tue, Jun 9, 2009 at 11:32 AM, Gerhard Petracekgerhard.petra...@gmail.com wrote: hi, short description: this first vote is about the switch from commons-logging (cl) to java.util.logging (jul). it's a binding vote for the next releases of all myfaces libs which are currently using commons-logging. so e.g. trinidad isn't affected. details are available at [1] if there won't be a majority, we will open a second vote (switch from commons-logging to slf4j). [ ] +1 for replacing cl with jul [ ] +0 [ ] -1 for keeping cl or to force a second vote for slf4j as replacement regards, gerhard [1] http://www.nabble.com/slf4j-and-myfaces-td23890255.html -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [VOTE] jul instead of commons-logging
+1 Gerhard Petracek wrote: hi, short description: this first vote is about the switch from commons-logging (cl) to java.util.logging (jul). it's a binding vote for the next releases of all myfaces libs which are currently using commons-logging. so e.g. trinidad isn't affected. details are available at [1] if there won't be a majority, we will open a second vote (switch from commons-logging to slf4j). [ ] +1 for replacing cl with jul [ ] +0 [ ] -1 for keeping cl or to force a second vote for slf4j as replacement regards, gerhard [1] http://www.nabble.com/slf4j-and-myfaces-td23890255.html
Re: [VOTE] jul instead of commons-logging
On Tue, Jun 9, 2009 at 2:32 PM, Gerhard Petracekgerhard.petra...@gmail.com wrote: hi, short description: this first vote is about the switch from commons-logging (cl) to java.util.logging (jul). it's a binding vote for the next releases of all myfaces libs which are currently using commons-logging. so e.g. trinidad isn't affected. details are available at [1] if there won't be a majority, we will open a second vote (switch from commons-logging to slf4j). [ ] +1 for replacing cl with jul [ ] +0 [ ] -1 for keeping cl or to force a second vote for slf4j as replacement regards, gerhard [1] http://www.nabble.com/slf4j-and-myfaces-td23890255.html +1 Curtiss Howard
Re: [VOTE] jul instead of commons-logging
+1 On Tue, Jun 9, 2009 at 2:56 PM, Curtiss Howardcurtiss.how...@gmail.com wrote: On Tue, Jun 9, 2009 at 2:32 PM, Gerhard Petracekgerhard.petra...@gmail.com wrote: hi, short description: this first vote is about the switch from commons-logging (cl) to java.util.logging (jul). it's a binding vote for the next releases of all myfaces libs which are currently using commons-logging. so e.g. trinidad isn't affected. details are available at [1] if there won't be a majority, we will open a second vote (switch from commons-logging to slf4j). [ ] +1 for replacing cl with jul [ ] +0 [ ] -1 for keeping cl or to force a second vote for slf4j as replacement regards, gerhard [1] http://www.nabble.com/slf4j-and-myfaces-td23890255.html +1 Curtiss Howard
Re: AW: slf4j and myfaces
here [1] you go! :) regards, gerhard [1] http://www.nabble.com/-VOTE--jul-instead-of-commons-logging-td23948865.html 2009/6/9 Mario Ivankovits ma...@ops.co.at Start voting? ;-) *From:* Gerhard Petracek [mailto:gerhard.petra...@gmail.com] *Sent:* Saturday, June 06, 2009 11:45 AM *To:* MyFaces Development *Subject:* Re: AW: slf4j and myfaces yes the -1 vote would be a veto in view of slf4j - no agreement - we would vote about jul. or as mario suggested - let's start voting about jul. @mario: yes - i'll wait until monday for sure. and we should vote a bit longer than usual - due to holidays (+ it's an important topic for all myfaces projects) regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2009/6/6 Ganesh gan...@j4fry.org Hi, we could also vote first about slf4j and everybody who prefers jul should vote -1 if we don't have a majority for slf4j, we have to vote about jul. is that ok for everybody? From http://www.apache.org/foundation/voting.html my understanding of a -1 vote is different from this. Vetos A code-modification proposal may be stopped dead in its tracks by a -1 vote by a qualified voter. This constitutes a veto, and it cannot be overruled nor overridden by anyone. Vetos stand until and unless withdrawn by their casters. To prevent vetos from being used capriciously, they must be accompanied by a technical justification showing why the change is bad (opens a security exposure, negatively affects performance, etc.). A veto without a justification is invalid and has no weight. Better use the fraction system for voting on the logging system: * +0: 'I don't feel strongly about it, but I'm okey with this.' * -0: 'I won't get in the way, but I'd rather we didn't do this.' * -0.5: 'I don't like this idea, but I can't find any rational justification for my feelings.' * ++1: 'Wow! I like this! Let's do it!' * -0.9: 'I really don't like this, but I'm not going to stand in the way if everyone else wants to go ahead with it.' * +0.9: 'This is a cool idea and i like it, but I don't have time/the skills necessary to help out.' Best regards, Ganesh
AW: [VOTE] jul instead of commons-logging
+1 Von: Gerhard Petracek [mailto:gerhard.petra...@gmail.com] Gesendet: Dienstag, 09. Juni 2009 20:33 An: MyFaces Development Betreff: [VOTE] jul instead of commons-logging hi, short description: this first vote is about the switch from commons-logging (cl) to java.util.logging (jul). it's a binding vote for the next releases of all myfaces libs which are currently using commons-logging. so e.g. trinidad isn't affected. details are available at [1] if there won't be a majority, we will open a second vote (switch from commons-logging to slf4j). [ ] +1 for replacing cl with jul [ ] +0 [ ] -1 for keeping cl or to force a second vote for slf4j as replacement regards, gerhard [1] http://www.nabble.com/slf4j-and-myfaces-td23890255.html
Re: [VOTE] jul instead of commons-logging
-0.5, I like slf4j :) Regards, Cagatay On Jun 9, 2009, at 7:32 PM, Gerhard Petracek wrote: hi, short description: this first vote is about the switch from commons-logging (cl) to java.util.logging (jul). it's a binding vote for the next releases of all myfaces libs which are currently using commons-logging. so e.g. trinidad isn't affected. details are available at [1] if there won't be a majority, we will open a second vote (switch from commons-logging to slf4j). [ ] +1 for replacing cl with jul [ ] +0 [ ] -1 for keeping cl or to force a second vote for slf4j as replacement regards, gerhard [1] http://www.nabble.com/slf4j-and-myfaces-td23890255.html
Re: [VOTE] jul instead of commons-logging
+1 for JUL. On Tue, Jun 9, 2009 at 10:41 PM, Cagatay Civici cagatay.civ...@gmail.comwrote: -0.5, I like slf4j :) Regards, Cagatay On Jun 9, 2009, at 7:32 PM, Gerhard Petracek wrote: hi, short description: this first vote is about the switch from commons-logging (cl) to java.util.logging (jul). it's a binding vote for the next releases of all myfaces libs which are currently using commons-logging. so e.g. trinidad isn't affected. details are available at [1] if there won't be a majority, we will open a second vote (switch from commons-logging to slf4j). [ ] +1 for replacing cl with jul [ ] +0 [ ] -1 for keeping cl or to force a second vote for slf4j as replacement regards, gerhard [1] http://www.nabble.com/slf4j-and-myfaces-td23890255.html -- Hazem Ahmed Saleh Ahmed Author of (The Definitive Guide to Apache MyFaces and Facelets): http://www.amazon.com/Definitive-Guide-Apache-MyFaces-Facelets/dp/1590597370 Web blog: http://www.jroller.com/page/HazemBlog [Web 2.0] Google Maps Integration with JSF: http://code.google.com/p/gmaps4jsf/ http://www.theserverside.com/tt/articles/article.tss?l=IntroductiontoGMaps4JSF
Re: [VOTE] jul instead of commons-logging
+0.5 I like SLF4J as well, but I won't get in the way of JUL. Never used JUL myself, so I don't know for sure if there might be any hidden quirks. ;-) --Manfred On Tue, Jun 9, 2009 at 20:32, Gerhard Petracekgerhard.petra...@gmail.com wrote: hi, short description: this first vote is about the switch from commons-logging (cl) to java.util.logging (jul). it's a binding vote for the next releases of all myfaces libs which are currently using commons-logging. so e.g. trinidad isn't affected. details are available at [1] if there won't be a majority, we will open a second vote (switch from commons-logging to slf4j). [ ] +1 for replacing cl with jul [ ] +0 [ ] -1 for keeping cl or to force a second vote for slf4j as replacement regards, gerhard [1] http://www.nabble.com/slf4j-and-myfaces-td23890255.html
Re: Problems compiling a modified version Tomahawk for JSF 1.2
Ganesh, I downgraded my maven to version 2.0.9 but I still can't have my changes compiled. I'm trying to change the org.apache.myfaces.shared_tomahawk.renderkit.html.HtmlRendererUtils class and package it with maven. This class is located in my WORKSPACE_ROOT/core/target/shared_sources/org/apache/myfaces/shared_tomahawk/renderkit/html folder. I am changing the correct file? I mean, this one is under a target folder, and I could not locate anywhere else this class. RPM Ganesh wrote: Hi Ramiro, Please try downgrading maven to 2.0.9. It's either the build-helper-maven-plugin or myfaces-builder-plugin that isn't compatible with maven 2.1 Best regards, Ganesh Ramiro Pereira de Magalhaes schrieb: Guys, I checked out Tomahawk (for JSF 1.2) from Subversion (http://svn.apache.org/repos/asf/myfaces/tomahawk/trunk) to make some changes in the code and make an internal distribution of it to my company, since I have to comply with an internal policy that says that all applications must render XHTML 1.0 Transitional pages. I made some changes but when I run mvn install some plugin causes my modifications to be ignored. How can I create a customized Tomahawk package with maven? RPM
[jira] Updated: (TOMAHAWK-1318) Add itemLabelEscaped, itemDisabled attributes to t:selectItems
[ https://issues.apache.org/jira/browse/TOMAHAWK-1318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe updated TOMAHAWK-1318: - Resolution: Fixed Fix Version/s: 1.1.9-SNAPSHOT Assignee: Leonardo Uribe (was: Cagatay Civici) Status: Resolved (was: Patch Available) Add itemLabelEscaped, itemDisabled attributes to t:selectItems -- Key: TOMAHAWK-1318 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1318 Project: MyFaces Tomahawk Issue Type: New Feature Affects Versions: 1.1.7-SNAPSHOT Reporter: Cagatay Civici Assignee: Leonardo Uribe Priority: Minor Fix For: 1.1.9-SNAPSHOT Attachments: TOMAHAWK-1318.patch Improvements for t:selectItems -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Problems compiling a modified version Tomahawk for JSF 1.2
Hi This file is on shared project: svn repo: http://svn.apache.org/repos/asf/myfaces/shared/ link to find site : http://myfaces.apache.org/otherProjects.html Tomahawk unpack shared code and add it, so if you want change this file, you have to follow this steps: 1. Checkout, make the update and compile. 3. Change tomahawk shared related var to the version you are compiling (if you are using the latest code 2.0.11-SNAPSHOT and 3.0.7-SNAPSHOT), on its pom.xml (not core or core12 pom, the main pom). 3. Compile and the resulting artifacts should have the change. regards Leonardo Uribe 2009/6/9 Ramiro Pereira de Magalhaes rpm_mail...@yahoo.com.br Ganesh, I downgraded my maven to version 2.0.9 but I still can't have my changes compiled. I'm trying to change the org.apache.myfaces.shared_tomahawk.renderkit.html.HtmlRendererUtils class and package it with maven. This class is located in my WORKSPACE_ROOT/core/target/shared_sources/org/apache/myfaces/shared_tomahawk/renderkit/html folder. I am changing the correct file? I mean, this one is under a target folder, and I could not locate anywhere else this class. RPM Ganesh wrote: Hi Ramiro, Please try downgrading maven to 2.0.9. It's either the build-helper-maven-plugin or myfaces-builder-plugin that isn't compatible with maven 2.1 Best regards, Ganesh Ramiro Pereira de Magalhaes schrieb: Guys, I checked out Tomahawk (for JSF 1.2) from Subversion ( http://svn.apache.org/repos/asf/myfaces/tomahawk/trunk) to make some changes in the code and make an internal distribution of it to my company, since I have to comply with an internal policy that says that all applications must render XHTML 1.0 Transitional pages. I made some changes but when I run mvn install some plugin causes my modifications to be ignored. How can I create a customized Tomahawk package with maven? RPM
[jira] Updated: (TOMAHAWK-596) Duplicate id exception for HtmlDataScrollerRenderer
[ https://issues.apache.org/jira/browse/TOMAHAWK-596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe updated TOMAHAWK-596: Resolution: Fixed Fix Version/s: 1.1.9-SNAPSHOT Assignee: Leonardo Uribe Status: Resolved (was: Patch Available) The patch proposed by Milan Majercik has sense and does not cause the side effects of other patches like the one proposed on TOMAHAWK-1249. I review it and did the necessary fixes, like remove links generated by paginator section and correct the section related to generated facet links (needed to solve TOMAHAWK-1249). Thanks to Milan Majercik for this patch. Duplicate id exception for HtmlDataScrollerRenderer --- Key: TOMAHAWK-596 URL: https://issues.apache.org/jira/browse/TOMAHAWK-596 Project: MyFaces Tomahawk Issue Type: Bug Components: Data Scroller Affects Versions: 1.1.3 Environment: Linux, Windows Reporter: Ryan Wynn Assignee: Leonardo Uribe Fix For: 1.1.9-SNAPSHOT Attachments: datascroller-issue.txt, HtmlDataScrollerRenderer.java, HtmlDataScrollerRenderer.java.example, HtmlDataScrollerRenderer.patch, HtmlDataScrollerRenderer.patch, TOMAHAWK-596.patch In a portlet environment a non-faces request produces an exception when the faces tree is rendered if the faces tree contains a DataScroller component. The HtmlDataScroller renderer actually renders its children twice in this case, once in the encodeChildren method and once in the encodeEnd method. Since rendering of the children is taken care of in encodeEnd I made the encodeChildren method a no-op. Also, although the CommandLinks which are rendered as children are marked as transient, they see to stick around. I put a check in the getLink methods to make sure that the links are not added twice. This seems to fix the duplicate id exception, but it might be necessary to further investigate why they are sticking around in the first place. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Problems compiling a modified version Tomahawk for JSF 1.2
Guys, thanks for helping. It worked just fine. Is this written somewhere? I can write about it if you point me where the appropriate place is. RPM Leonardo Uribe wrote: Hi This file is on shared project: svn repo: http://svn.apache.org/repos/asf/myfaces/shared/ link to find site : http://myfaces.apache.org/otherProjects.html Tomahawk unpack shared code and add it, so if you want change this file, you have to follow this steps: 1. Checkout, make the update and compile. 3. Change tomahawk shared related var to the version you are compiling (if you are using the latest code 2.0.11-SNAPSHOT and 3.0.7-SNAPSHOT), on its pom.xml (not core or core12 pom, the main pom). 3. Compile and the resulting artifacts should have the change. regards Leonardo Uribe 2009/6/9 Ramiro Pereira de Magalhaes rpm_mail...@yahoo.com.br mailto:rpm_mail...@yahoo.com.br Ganesh, I downgraded my maven to version 2.0.9 but I still can't have my changes compiled. I'm trying to change the org.apache.myfaces.shared_tomahawk.renderkit.html.HtmlRendererUtils class and package it with maven. This class is located in my WORKSPACE_ROOT/core/target/shared_sources/org/apache/myfaces/shared_tomahawk/renderkit/html folder. I am changing the correct file? I mean, this one is under a target folder, and I could not locate anywhere else this class. RPM Ganesh wrote: Hi Ramiro, Please try downgrading maven to 2.0.9. It's either the build-helper-maven-plugin or myfaces-builder-plugin that isn't compatible with maven 2.1 Best regards, Ganesh Ramiro Pereira de Magalhaes schrieb: Guys, I checked out Tomahawk (for JSF 1.2) from Subversion (http://svn.apache.org/repos/asf/myfaces/tomahawk/trunk) to make some changes in the code and make an internal distribution of it to my company, since I have to comply with an internal policy that says that all applications must render XHTML 1.0 Transitional pages. I made some changes but when I run mvn install some plugin causes my modifications to be ignored. How can I create a customized Tomahawk package with maven? RPM
Re: [VOTE] jul instead of commons-logging
+1 Gerhard Petracek schrieb: hi, short description: this first vote is about the switch from commons-logging (cl) to java.util.logging (jul). it's a binding vote for the next releases of all myfaces libs which are currently using commons-logging. so e.g. trinidad isn't affected. details are available at [1] if there won't be a majority, we will open a second vote (switch from commons-logging to slf4j). [ ] +1 for replacing cl with jul [ ] +0 [ ] -1 for keeping cl or to force a second vote for slf4j as replacement regards, gerhard [1] http://www.nabble.com/slf4j-and-myfaces-td23890255.html
