RE: [OT] Jira anonymous access
Within JIRA, go to Administration - Permission Schemes and edit the particular scheme to which the ADFFACES project belongs. Just a matter of setting the appropriate permissions for Add Comments to not include everyone. Chris Dadej Macquarie Bank Limited ISD - Investment Banking Group Phone: +612 8232 9987 Mobile: +614 1625 4791 Email: [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matthias Wessendorf Sent: Friday, 9 June 2006 3:46 PM To: MyFaces Development Subject: [OT] Jira anonymous access hey, anybody knows what todo to avoid anonymous sending comments to the ADFFACES jira? Or is this a task for the infra@ guys? thx, Matthias -- Matthias Wessendorf Aechterhoek 18 48282 Emsdetten blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com NOTICE This e-mail and any attachments are confidential and may contain copyright material of Macquarie Bank or third parties. If you are not the intended recipient of this email you should not read, print, re-transmit, store or act in reliance on this e-mail or any attachments, and should destroy all copies of them. Macquarie Bank does not guarantee the integrity of any emails or any attached files. The views or opinions expressed are the author's own and may not reflect the views or opinions of Macquarie Bank.
Re: [OT] Jira anonymous access
I think I don't have that permission to change it. Adam, can you take care? -Matthias On 6/8/06, Chris Dadej [EMAIL PROTECTED] wrote: Within JIRA, go to Administration - Permission Schemes and edit the particular scheme to which the ADFFACES project belongs. Just a matter of setting the appropriate permissions for Add Comments to not include everyone. Chris Dadej Macquarie Bank Limited ISD - Investment Banking Group Phone: +612 8232 9987 Mobile: +614 1625 4791 Email: [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matthias Wessendorf Sent: Friday, 9 June 2006 3:46 PM To: MyFaces Development Subject: [OT] Jira anonymous access hey, anybody knows what todo to avoid anonymous sending comments to the ADFFACES jira? Or is this a task for the infra@ guys? thx, Matthias -- Matthias Wessendorf Aechterhoek 18 48282 Emsdetten blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com NOTICE This e-mail and any attachments are confidential and may contain copyright material of Macquarie Bank or third parties. If you are not the intended recipient of this email you should not read, print, re-transmit, store or act in reliance on this e-mail or any attachments, and should destroy all copies of them. Macquarie Bank does not guarantee the integrity of any emails or any attached files. The views or opinions expressed are the author's own and may not reflect the views or opinions of Macquarie Bank. -- Matthias Wessendorf Aechterhoek 18 48282 Emsdetten blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: [OT] Jira anonymous access
On 6/8/06, Chris Dadej [EMAIL PROTECTED] wrote: Within JIRA, go to Administration - Permission Schemes and edit theparticular scheme to which the ADFFACES project belongs.Just a matter of setting the appropriate permissions for Add Commentsto not include everyone. Thanks Chris. I've got admin rights on the project in question, but not general JIRA admin rights (which seems to be necessary to edit permission schemes). Therefore, this will need to be requested from the Infra group. CraigChris DadejMacquarie Bank LimitedISD - Investment Banking Group Phone:+612 8232 9987Mobile: +614 1625 4791Email:[EMAIL PROTECTED]-Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf OfMatthias WessendorfSent: Friday, 9 June 2006 3:46 PMTo: MyFaces DevelopmentSubject: [OT] Jira anonymous access hey,anybody knows what todo to avoid anonymous sending comments to theADFFACES jira?Or is this a task for the infra@ guys?thx,Matthias--Matthias WessendorfAechterhoek 18 48282 Emsdettenblog: http://jroller.com/page/mwessendorfmail: mwessendorf-at-gmail-dot-comNOTICEThis e-mail and any attachments are confidential and may contain copyright material of Macquarie Bank or third parties. If you are not the intended recipient of this email you should not read, print, re-transmit, store or act in reliance on this e-mail or any attachments, and should destroy all copies of them. Macquarie Bank does not guarantee the integrity of any emails or any attached files. The views or opinions expressed are the author's own and may not reflect the views or opinions of Macquarie Bank.
Re: svn commit: r412924 - /myfaces/core/branches/jsf12/impl/pom.xml
ah, the comment was confusing to me. Good night mr b. -Matthias On 6/8/06, Dennis Byrne [EMAIL PROTECTED] wrote: It has nothing to do with the dependencies; reverting only reintroduces two things we don't need. I only wrote that in the svn comments because I knew Continuum might run right after the transaction. This did happen, hence the BUILD FAILURE notice sent to the list shortly afterwards. Reverting the patch would also cause another BUILD FAILURE notice ;) Dennis Byrne -Original Message- From: Matthias Wessendorf [mailto:[EMAIL PROTECTED] Sent: Friday, June 9, 2006 02:20 AM To: 'MyFaces Development' Subject: Re: svn commit: r412924 - /myfaces/core/branches/jsf12/impl/pom.xml sure, that works. but what has this todo w/ commons-el and commons-codec `? works for me w/ these deps too... (just checked twice) should I revert the commit? -Matthias On 6/8/06, Dennis Byrne [EMAIL PROTECTED] wrote: I think the problem will go away if you first cd and mvn clean istall the shared 3_0_0 branch. This will produce a jar under .m2\repository\org\apache\myfaces\shared\myfaces-shared-impl\3.0.0-SNAPSHOT . Let mw know what happens when you do mvn clean istall under jsf12 afterwards. Dennis Byrne -Original Message- From: Matthias Wessendorf [mailto:[EMAIL PROTECTED] Sent: Friday, June 9, 2006 12:57 AM To: 'MyFaces Development' Subject: Re: svn commit: r412924 - /myfaces/core/branches/jsf12/impl/pom.xml dennis- when I kill my complete m2 repo (local) I also get this message (after I checked out your commit). I can't see how removing commons-el and commons-codec can avoid this. -Matthias [WARNING] Unable to get resource from repository apache-maven-snapshots (http://cvs.apache.org/maven-snapshot-repository) [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) org.apache.myfaces.shared:myfaces-shared-impl:jar:3.0.0-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.myfaces.shared -DartifactId=myfaces-shared-impl \ -Dversion=3.0.0-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.myfaces.core:myfaces-impl:jar:1.2.0-SNAPSHOT 2) org.apache.myfaces.shared:myfaces-shared-impl:jar:3.0.0-SNAPSHOT -- 1 required artifact is missing. for artifact: org.apache.myfaces.core:myfaces-impl:jar:1.2.0-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2), java.net (https://maven-repository.dev.java.net/nonav/repository), apache-maven-snapshots (http://cvs.apache.org/maven-snapshot-repository), myfaces-repo (http://myfaces.zones.apache.org/dist/maven-repository) [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 11 minutes 9 seconds [INFO] Finished at: Thu Jun 08 21:54:17 PDT 2006 [INFO] Final Memory: 9M/29M [INFO] On 6/8/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: dennisbyrne Date: Thu Jun 8 21:24:49 2006 New Revision: 412924 URL: http://svn.apache.org/viewvc?rev=412924view=rev Log: removing commons-el and commons-codec ... builds fine locally but may cause build failure if Continuum cannot locate shared 3.0 branch Modified: myfaces/core/branches/jsf12/impl/pom.xml Modified: myfaces/core/branches/jsf12/impl/pom.xml URL: http://svn.apache.org/viewvc/myfaces/core/branches/jsf12/impl/pom.xml?rev=412924r1=412923r2=412924view=diff == --- myfaces/core/branches/jsf12/impl/pom.xml (original) +++ myfaces/core/branches/jsf12/impl/pom.xml Thu Jun 8 21:24:49 2006 @@ -238,12 +238,6 @@ scopeprovided/scope /dependency dependency - groupIdcommons-el/groupId - artifactIdcommons-el/artifactId - version1.0/version - scopecompile/scope -/dependency -dependency groupIdcommons-collections/groupId artifactIdcommons-collections/artifactId version3.1/version @@ -278,12 +272,6 @@ artifactIdmyfaces-shared-impl/artifactId version3.0.0-SNAPSHOT/version scopeprovided/scope -/dependency -dependency - groupIdcommons-codec/groupId - artifactIdcommons-codec/artifactId - version1.3/version - scopecompile/scope /dependency dependency groupIdportlet-api/groupId -- Matthias
Re: Upcoming Tomahawk Release
One thing I noticed w/ collapsiblePanel.jsf . c.s.f.r.h.HtmlResponseWriter.writeAttribute throws a NPE when HtmlTextHelpRenderer.renderInputTextHelp is passes nulls. Is this in JIRA? Dennis Byrne -Original Message- From: Matthias Wessendorf [mailto:[EMAIL PROTECTED] Sent: Thursday, June 8, 2006 11:26 PM To: 'MyFaces Development' Subject: Re: Upcoming Tomahawk Release I tried tomahawk_1_1_3 and JSF 1.1._01 (I just removed myfaces-xxx and added jsf-xxx) I didn't changed any of the dependencies. No idea, what RI needs :-) I figured out the following issues: TOMAHAWK-481 TOMAHAWK-480 TOMAHAWK-479 TOMAHAWK-478 TOMAHAWK-474 TOMAHAWK-458 TOMAHAWK-457 TOMAHAWK-456 Some of these issues are already know (like TOMAHAWK-457 or TOMAHAWK-474). Bugs like TOMAHAWK-474 are no real showstopper to me. I'll try now tomahaw_1_1_2 to be *very* sure what's going on here. in the meantime (I am not a RI user...) can any of the other committer please give the tomahawk_1_1_3 a try to their applications... or (if time) against the RI on their boxes Thanks, Matthias On 6/8/06, Sean Schofield [EMAIL PROTECTED] wrote: Are these related to the issues that we deferred to 1.1.4? There were a few issues that were already present in 1.1.2 and so they weren't considered showstoppers. Suggested course of action: 1.) Check JIRA - add issues if they are not already there 2.) Check agains 1.1.2 a.) issue is present in 1.1.2 -- mark version found as 1.1.2, 1.1.3 and ignore for this release b.) issue is not present in 1.1.2 -- mark fix version as 1.1.3 and we hold up the release Sean On 6/8/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: mmm w/ RI I get some issues. null pointers non-working links (sortable header for instance) Can anybody give it please a try w/ RI too? I guess I get these errors by random... sometimes RI works for me, sometime not.. thanks. will be back after a good night sleep -Matthias On 6/7/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: simple example w/ tom 1.1.3 + myfaces core (api impl) 1.1.4 works great now RI On 6/7/06, Mario Ivankovits [EMAIL PROTECTED] wrote: Don't worry about it. Sean must have fixed it. Even better ;-) Great! Thanks! Dennis Byrne Mario -- Matthias Wessendorf Aechterhoek 18 48282 Emsdetten blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf Aechterhoek 18 48282 Emsdetten blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf Aechterhoek 18 48282 Emsdetten blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: [OT] Jira anonymous access
Hi infra@ guys. We - the ADF team - would like to ask you to help us out with the jira permissions. currently it is possible to add comments as anonymous. This is a fact, we don't like for some reasons. thanks for your help, Matthias On 6/8/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 6/8/06, Chris Dadej [EMAIL PROTECTED] wrote: Within JIRA, go to Administration - Permission Schemes and edit the particular scheme to which the ADFFACES project belongs. Just a matter of setting the appropriate permissions for Add Comments to not include everyone. Thanks Chris. I've got admin rights on the project in question, but not general JIRA admin rights (which seems to be necessary to edit permission schemes). Therefore, this will need to be requested from the Infra group. Craig Chris Dadej Macquarie Bank Limited ISD - Investment Banking Group Phone: +612 8232 9987 Mobile: +614 1625 4791 Email: [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matthias Wessendorf Sent: Friday, 9 June 2006 3:46 PM To: MyFaces Development Subject: [OT] Jira anonymous access hey, anybody knows what todo to avoid anonymous sending comments to the ADFFACES jira? Or is this a task for the infra@ guys? thx, Matthias -- Matthias Wessendorf Aechterhoek 18 48282 Emsdetten blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com NOTICE This e-mail and any attachments are confidential and may contain copyright material of Macquarie Bank or third parties. If you are not the intended recipient of this email you should not read, print, re-transmit, store or act in reliance on this e-mail or any attachments, and should destroy all copies of them. Macquarie Bank does not guarantee the integrity of any emails or any attached files. The views or opinions expressed are the author's own and may not reflect the views or opinions of Macquarie Bank. -- Matthias Wessendorf Aechterhoek 18 48282 Emsdetten blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Upcoming Tomahawk Release
http://issues.apache.org/jira/browse/TOMAHAWK-479 -Matthias On 6/8/06, Dennis Byrne [EMAIL PROTECTED] wrote: One thing I noticed w/ collapsiblePanel.jsf . c.s.f.r.h.HtmlResponseWriter.writeAttribute throws a NPE when HtmlTextHelpRenderer.renderInputTextHelp is passes nulls. Is this in JIRA? Dennis Byrne -Original Message- From: Matthias Wessendorf [mailto:[EMAIL PROTECTED] Sent: Thursday, June 8, 2006 11:26 PM To: 'MyFaces Development' Subject: Re: Upcoming Tomahawk Release I tried tomahawk_1_1_3 and JSF 1.1._01 (I just removed myfaces-xxx and added jsf-xxx) I didn't changed any of the dependencies. No idea, what RI needs :-) I figured out the following issues: TOMAHAWK-481 TOMAHAWK-480 TOMAHAWK-479 TOMAHAWK-478 TOMAHAWK-474 TOMAHAWK-458 TOMAHAWK-457 TOMAHAWK-456 Some of these issues are already know (like TOMAHAWK-457 or TOMAHAWK-474). Bugs like TOMAHAWK-474 are no real showstopper to me. I'll try now tomahaw_1_1_2 to be *very* sure what's going on here. in the meantime (I am not a RI user...) can any of the other committer please give the tomahawk_1_1_3 a try to their applications... or (if time) against the RI on their boxes Thanks, Matthias On 6/8/06, Sean Schofield [EMAIL PROTECTED] wrote: Are these related to the issues that we deferred to 1.1.4? There were a few issues that were already present in 1.1.2 and so they weren't considered showstoppers. Suggested course of action: 1.) Check JIRA - add issues if they are not already there 2.) Check agains 1.1.2 a.) issue is present in 1.1.2 -- mark version found as 1.1.2, 1.1.3 and ignore for this release b.) issue is not present in 1.1.2 -- mark fix version as 1.1.3 and we hold up the release Sean On 6/8/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: mmm w/ RI I get some issues. null pointers non-working links (sortable header for instance) Can anybody give it please a try w/ RI too? I guess I get these errors by random... sometimes RI works for me, sometime not.. thanks. will be back after a good night sleep -Matthias On 6/7/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: simple example w/ tom 1.1.3 + myfaces core (api impl) 1.1.4 works great now RI On 6/7/06, Mario Ivankovits [EMAIL PROTECTED] wrote: Don't worry about it. Sean must have fixed it. Even better ;-) Great! Thanks! Dennis Byrne Mario -- Matthias Wessendorf Aechterhoek 18 48282 Emsdetten blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf Aechterhoek 18 48282 Emsdetten blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf Aechterhoek 18 48282 Emsdetten blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf Aechterhoek 18 48282 Emsdetten blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: [OT] Jira anonymous access
Easy enough to add Craig as a jira admin. I assume it's the craigmcc user Craig? There's another one with a sun.com address, but I suspect that was pulled in by a migration. Hen On 6/8/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi infra@ guys. We - the ADF team - would like to ask you to help us out with the jira permissions. currently it is possible to add comments as anonymous. This is a fact, we don't like for some reasons. thanks for your help, Matthias On 6/8/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 6/8/06, Chris Dadej [EMAIL PROTECTED] wrote: Within JIRA, go to Administration - Permission Schemes and edit the particular scheme to which the ADFFACES project belongs. Just a matter of setting the appropriate permissions for Add Comments to not include everyone. Thanks Chris. I've got admin rights on the project in question, but not general JIRA admin rights (which seems to be necessary to edit permission schemes). Therefore, this will need to be requested from the Infra group. Craig Chris Dadej Macquarie Bank Limited ISD - Investment Banking Group Phone: +612 8232 9987 Mobile: +614 1625 4791 Email: [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matthias Wessendorf Sent: Friday, 9 June 2006 3:46 PM To: MyFaces Development Subject: [OT] Jira anonymous access hey, anybody knows what todo to avoid anonymous sending comments to the ADFFACES jira? Or is this a task for the infra@ guys? thx, Matthias -- Matthias Wessendorf Aechterhoek 18 48282 Emsdetten blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com NOTICE This e-mail and any attachments are confidential and may contain copyright material of Macquarie Bank or third parties. If you are not the intended recipient of this email you should not read, print, re-transmit, store or act in reliance on this e-mail or any attachments, and should destroy all copies of them. Macquarie Bank does not guarantee the integrity of any emails or any attached files. The views or opinions expressed are the author's own and may not reflect the views or opinions of Macquarie Bank. -- Matthias Wessendorf Aechterhoek 18 48282 Emsdetten blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: [OT] Jira anonymous access
On 6/9/06, Henri Yandell [EMAIL PROTECTED] wrote: Easy enough to add Craig as a jira admin.I assume it's the craigmcc user Craig?Yes, that's me ([EMAIL PROTECTED]). I'd be happy to help out on all the JIRA admin issues if I could. There's another one with asun.com address, but I suspect that was pulled in by a migration. That ([EMAIL PROTECTED]) is also me ... but I'd prefer to have my Apache related admin rights attached to my Apache identity. HenCraigOn 6/8/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi infra@ guys. We - the ADF team - would like to ask you to help us out with the jira permissions. currently it is possible to add comments as anonymous. This is a fact, we don't like for some reasons. thanks for your help, Matthias On 6/8/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 6/8/06, Chris Dadej [EMAIL PROTECTED] wrote: Within JIRA, go to Administration - Permission Schemes and edit the particular scheme to which the ADFFACES project belongs. Just a matter of setting the appropriate permissions for Add Comments to not include everyone. Thanks Chris.I've got admin rights on the project in question, but not general JIRA admin rights (which seems to be necessary to edit permission schemes).Therefore, this will need to be requested from the Infra group. Craig Chris Dadej Macquarie Bank Limited ISD - Investment Banking Group Phone:+612 8232 9987 Mobile: +614 1625 4791 Email:[EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Matthias Wessendorf Sent: Friday, 9 June 2006 3:46 PM To: MyFaces Development Subject: [OT] Jira anonymous access hey, anybody knows what todo to avoid anonymous sending comments to the ADFFACES jira? Or is this a task for the infra@ guys? thx, Matthias -- Matthias Wessendorf Aechterhoek 18 48282 Emsdetten blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com NOTICE This e-mail and any attachments are confidential and may contain copyright material of Macquarie Bank or third parties. If you are not the intended recipient of this email you should not read, print, re-transmit, store or act in reliance on this e-mail or any attachments, and should destroy all copies of them. Macquarie Bank does not guarantee the integrity of any emails or any attached files. The views or opinions expressed are the author's own and may not reflect the views or opinions of Macquarie Bank. -- Matthias Wessendorf Aechterhoek 18 48282 Emsdetten blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: [OT] Jira anonymous access
Sorry Infra for bothering you - I've got admin rights for jira, and switched the flag.All set!regards,MartinOn 6/9/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:Hi infra@ guys. We - the ADF team - would like to ask you to help us out with the jirapermissions.currently it is possible to add comments as anonymous. This is afact, we don't like for some reasons. thanks for your help,MatthiasOn 6/8/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 6/8/06, Chris Dadej [EMAIL PROTECTED] wrote: Within JIRA, go to Administration - Permission Schemes and edit the particular scheme to which the ADFFACES project belongs. Just a matter of setting the appropriate permissions for Add Comments to not include everyone. Thanks Chris.I've got admin rights on the project in question, but not general JIRA admin rights (which seems to be necessary to edit permission schemes).Therefore, this will need to be requested from the Infra group. Craig Chris Dadej Macquarie Bank Limited ISD - Investment Banking Group Phone:+612 8232 9987 Mobile: +614 1625 4791 Email:[EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Matthias Wessendorf Sent: Friday, 9 June 2006 3:46 PM To: MyFaces Development Subject: [OT] Jira anonymous access hey, anybody knows what todo to avoid anonymous sending comments to the ADFFACES jira? Or is this a task for the infra@ guys? thx, Matthias -- Matthias Wessendorf Aechterhoek 18 48282 Emsdetten blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-comNOTICE This e-mail and any attachments are confidential and may contain copyright material of Macquarie Bank or third parties. If you are not the intended recipient of this email you should not read, print, re-transmit, store or act in reliance on this e-mail or any attachments, and should destroy all copies of them. Macquarie Bank does not guarantee the integrity of any emails or any attached files. The views or opinions expressed are the author's own and may not reflect the views or opinions of Macquarie Bank. --Matthias WessendorfAechterhoek 1848282 Emsdettenblog: http://jroller.com/page/mwessendorfmail: mwessendorf-at-gmail-dot-com -- http://www.irian.atYour JSF powerhouse - JSF Consulting, Development and Courses in English and GermanProfessional Support for Apache MyFaces
Re: [OT] Jira anonymous access
On 6/9/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 6/9/06, Henri Yandell [EMAIL PROTECTED] wrote: Easy enough to add Craig as a jira admin. I assume it's the craigmcc user Craig? Yes, that's me ([EMAIL PROTECTED]). I'd be happy to help out on all the JIRA admin issues if I could. Added. Hen
Re: Upcoming Tomahawk Release
You might also want to take a look at the snazzy pom.xml setup Wendy created for the Shale mvn_reorg branch. It lets you compile against either MyFaces or the RI based on enabling a profile ... something like this might be really handy on the component libraries, so you can easily build and test against both implementations. Yes I had already noticed this in Shale and planned to borrow it for MyFaces. :-) Craig Sean
[jira] Created: (TOMAHAWK-482) inputSuggestAjax inefficient with Ajax calls
inputSuggestAjax inefficient with Ajax calls Key: TOMAHAWK-482 URL: http://issues.apache.org/jira/browse/TOMAHAWK-482 Project: MyFaces Tomahawk Type: Improvement Components: InputSuggestAjax Versions: 1.1.4-SNAPSHOT Reporter: Peter Mahoney The inputSuggestAjax component currently sends an ajax request for every key press. This results in a lot on needless traffic which causes the user experience to be adversely affected. Possible improvements would be: Calls should only be made where the keypress has resulted in the field value changing. If a call results in no suggestions being returned, no further calls should be made until the field value up to the position of the cursor has been changed in some way e.g. a character deleted, or additional characters added. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Upcoming Tomahawk Release
So what's the latest? Any *new* bugs with the RI or is this all present in 1.1.2? Sean On 6/9/06, Sean Schofield [EMAIL PROTECTED] wrote: You might also want to take a look at the snazzy pom.xml setup Wendy created for the Shale mvn_reorg branch. It lets you compile against either MyFaces or the RI based on enabling a profile ... something like this might be really handy on the component libraries, so you can easily build and test against both implementations. Yes I had already noticed this in Shale and planned to borrow it for MyFaces. :-) Craig Sean
[Vote] Release Tomahawk 1.1.3
This is a vote to release Tomahawk 1.1.3 (and its dependencies: MyFaces Shared 2.0.2 and MyFaces Maven 1.0.3.) +1 for my vote -- Matthias Wessendorf Aechterhoek 18 48282 Emsdetten blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: [Vote] Release Tomahawk 1.1.3
Jo-o! This is a vote to release Tomahawk 1.1.3 (and its dependencies: MyFaces Shared 2.0.2 and MyFaces Maven 1.0.3.) +1 for my vote +1 Ciao, Mario
Re: [Vote] Release Tomahawk 1.1.3
+1 On 6/9/06, Mario Ivankovits [EMAIL PROTECTED] wrote: Jo-o! This is a vote to release Tomahawk 1.1.3 (and its dependencies: MyFaces Shared 2.0.2 and MyFaces Maven 1.0.3.) +1 for my vote +1 Ciao, Mario
bug in tomahawk HtmlTableRenderer (with patch)
There is a typo in the HtmlTableRenderer for tomahawk that applies the
rowStyle value where it should be applying the rowStyleClass value.
Here is the patch:
--- HtmlTableRenderer.java 2006-06-09 16:24:47.0 -0400
+++ HtmlTableRenderer.java.fixed2006-06-09 16:25:15.0 -0400
@@ -443,7 +443,7 @@
}
else
{
-writer.writeAttribute(HTML.CLASS_ATTR, rowStyle, null);
+writer.writeAttribute(HTML.CLASS_ATTR, rowStyleClass, null);
}
if(rowStyle != null)
{
--
Daniel Allen
Registered Linux User #231597
Mojavelinux.com: Open Source Advocacy
http://www.mojavelinux.com
While I make a strong effort to keep up with my email on a daily basis,
life and work come first and, at times, keep me away from my mail for a
while. If you contact me and then don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
Re: bug in tomahawk HtmlTableRenderer (with patch)
thx for heads up.
but please use in future our jira ticket system, so bugs / typs don't get lost.
-Matthias
On 6/9/06, Dan Allen [EMAIL PROTECTED] wrote:
There is a typo in the HtmlTableRenderer for tomahawk that applies the
rowStyle value where it should be applying the rowStyleClass value.
Here is the patch:
--- HtmlTableRenderer.java 2006-06-09 16:24:47.0 -0400
+++ HtmlTableRenderer.java.fixed2006-06-09 16:25:15.0 -0400
@@ -443,7 +443,7 @@
}
else
{
-writer.writeAttribute(HTML.CLASS_ATTR, rowStyle, null);
+writer.writeAttribute(HTML.CLASS_ATTR, rowStyleClass, null);
}
if(rowStyle != null)
{
--
Daniel Allen
Registered Linux User #231597
Mojavelinux.com: Open Source Advocacy
http://www.mojavelinux.com
While I make a strong effort to keep up with my email on a daily basis,
life and work come first and, at times, keep me away from my mail for a
while. If you contact me and then don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
--
Matthias Wessendorf
Aechterhoek 18
48282 Emsdetten
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
[jira] Created: (TOMAHAWK-484) Components with enabledOnUserRole overwrite their model with NULLs
Components with enabledOnUserRole overwrite their model with NULLs -- Key: TOMAHAWK-484 URL: http://issues.apache.org/jira/browse/TOMAHAWK-484 Project: MyFaces Tomahawk Type: Bug Versions: 1.1.2 Reporter: Val Blant The use of 'enabledOnUserRole' attribute results in components erroneously firing their valueChangeListeners and overwriting their value in the model with NULL. During the decode phase, org.apache.myfaces.shared_tomahawk.renderkit.html.HtmlRendererUtils.isDisabledOrReadOnly() method is used to determine if the component for the input field is disabled. The check is done like this: isTrue(component.getAttributes().get(disabled)) However, during the encode stage, we never set setDisabled(true) on the component! We simply rendered it as disabled in HtmlRendererUtils.internalRenderSelect(). Therefore the decode phase doesn't know that the component is disabled and thus sets the submittedValue to null, which leads to erroneous validation and model update. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TOMAHAWK-484) Components with enabledOnUserRole overwrite their model with NULLs
[ http://issues.apache.org/jira/browse/TOMAHAWK-484?page=comments#action_12415623 ] Val Blant commented on TOMAHAWK-484: I just realized that this problem only happens with drop down select boxes (i.e. HtmlRendererUtils.decodeUISelectOne() ). Input boxes print a warning, but they don't clobber the model Components with enabledOnUserRole overwrite their model with NULLs -- Key: TOMAHAWK-484 URL: http://issues.apache.org/jira/browse/TOMAHAWK-484 Project: MyFaces Tomahawk Type: Bug Versions: 1.1.2 Reporter: Val Blant The use of 'enabledOnUserRole' attribute results in components erroneously firing their valueChangeListeners and overwriting their value in the model with NULL. During the decode phase, org.apache.myfaces.shared_tomahawk.renderkit.html.HtmlRendererUtils.isDisabledOrReadOnly() method is used to determine if the component for the input field is disabled. The check is done like this: isTrue(component.getAttributes().get(disabled)) However, during the encode stage, we never set setDisabled(true) on the component! We simply rendered it as disabled in HtmlRendererUtils.internalRenderSelect(). Therefore the decode phase doesn't know that the component is disabled and thus sets the submittedValue to null, which leads to erroneous validation and model update. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TOMAHAWK-483) Resolving URIs using ViewHandler.getResourceURL
[ http://issues.apache.org/jira/browse/TOMAHAWK-483?page=all ] Rogério Pereira Araújo updated TOMAHAWK-483: Status: Patch Available (was: Open) Resolving URIs using ViewHandler.getResourceURL --- Key: TOMAHAWK-483 URL: http://issues.apache.org/jira/browse/TOMAHAWK-483 Project: MyFaces Tomahawk Type: Wish Reporter: Rogério Pereira Araújo Priority: Minor Fix For: 1.1.4-SNAPSHOT I'm using weblets and this solution uses viewHandler.getResourceURL to resolve some resources locations, i would like know if is possible change components like script, stylesheet and graphicImage to use this method. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TOMAHAWK-483) Resolving URIs using ViewHandler.getResourceURL
[ http://issues.apache.org/jira/browse/TOMAHAWK-483?page=all ] Matthias Weßendorf updated TOMAHAWK-483: Status: Open (was: Patch Available) Resolving URIs using ViewHandler.getResourceURL --- Key: TOMAHAWK-483 URL: http://issues.apache.org/jira/browse/TOMAHAWK-483 Project: MyFaces Tomahawk Type: Wish Reporter: Rogério Pereira Araújo Assignee: Matthias Weßendorf Priority: Minor Fix For: 1.1.4-SNAPSHOT Attachments: patch.txt I'm using weblets and this solution uses viewHandler.getResourceURL to resolve some resources locations, i would like know if is possible change components like script, stylesheet and graphicImage to use this method. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [Vote] Release Tomahawk 1.1.3
On 6/9/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: This is a vote to release Tomahawk 1.1.3 (and its dependencies:MyFaces Shared 2.0.2 and MyFaces Maven 1.0.3.)I should have spoken up earlier on, but I have a problem with this approach to release votes. In the Struts world, the release manager tends to put up a particular set of bits in his or her personal directory on people.apache.org, and then posts the vote request as I propose to release *this set of bits* ... That way, the other committers can download and check out exactly what is being proposed. Yes, with Maven based builds it is easy to assume that you and I will build identical artifacts, but it is still easier than you think for that not to be the case. Besides that, we caught packaging errors in several of the recent Struts Action Framework and Shale builds that would not have been caught if we hadn't been examining the actual bits being proposed. I would strongly suggest following this approach in MyFaces as well.On this basis, I'm -1 (non-binding as I'm not on the PMC).Craig +1 for my vote--Matthias WessendorfAechterhoek 1848282 Emsdettenblog: http://jroller.com/page/mwessendorfmail: mwessendorf-at-gmail-dot-com
Re: [Vote] Release Tomahawk 1.1.3
Craig- thanks for heads up. That particular RC for the Tomahawk 1.1.3 is listed available for download under [1]. That Shared 2.0.2 thing is *no* extra jar to be added to your WEB-INF/lib. The Shared clazzes are included in Tomahawk (org.apache.myfaces.shared_tomahawk.**) The folder [1] also contains a pom file for that Tomahawk 1.1.3 RC -Matthias [1] http://tinyurl.com/mu4t9 On 6/9/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 6/9/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: This is a vote to release Tomahawk 1.1.3 (and its dependencies: MyFaces Shared 2.0.2 and MyFaces Maven 1.0.3.) I should have spoken up earlier on, but I have a problem with this approach to release votes. In the Struts world, the release manager tends to put up a particular set of bits in his or her personal directory on people.apache.org, and then posts the vote request as I propose to release *this set of bits* ... That way, the other committers can download and check out exactly what is being proposed. Yes, with Maven based builds it is easy to assume that you and I will build identical artifacts, but it is still easier than you think for that not to be the case. Besides that, we caught packaging errors in several of the recent Struts Action Framework and Shale builds that would not have been caught if we hadn't been examining the actual bits being proposed. I would strongly suggest following this approach in MyFaces as well. On this basis, I'm -1 (non-binding as I'm not on the PMC). Craig +1 for my vote -- Matthias Wessendorf Aechterhoek 18 48282 Emsdetten blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf Aechterhoek 18 48282 Emsdetten blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: [Vote] Release Tomahawk 1.1.3
On 6/9/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Craig-thanks for heads up. That particular RC for the Tomahawk 1.1.3 islisted available for download under [1]. That Shared 2.0.2 thing is*no* extra jar to be added to your WEB-INF/lib. The Shared clazzes are included in Tomahawk (org.apache.myfaces.shared_tomahawk.**)The folder [1] also contains a pom file for that Tomahawk 1.1.3 RCOK, good ... I see that the proposed bits have indeed been published to a special repository for testing, and thereby withdraw my -1. But I still recommend a [VOTE] message for a release should specifically include such a URL (and perhaps instructions on how to temporarily modify your Maven settings to download and test this version) instead of just assuming that everyone knows where the bits are, and what to do. -MatthiasCraig [1] http://tinyurl.com/mu4t9On 6/9/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 6/9/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: This is a vote to release Tomahawk 1.1.3 (and its dependencies: MyFaces Shared 2.0.2 and MyFaces Maven 1.0.3.) I should have spoken up earlier on, but I have a problem with this approach to release votes. In the Struts world, the release manager tends to put up a particular set of bits in his or her personal directoryon people.apache.org, and then posts the vote request as I propose to release *this set of bits* ...That way, the other committers can download and check out exactly what is being proposed. Yes, with Maven based builds it is easy to assume that you and I will build identical artifacts, but it is still easier than you think for that not to be the case.Besides that, we caught packaging errors in several of the recent Struts Action Framework and Shale builds that would not have been caught if we hadn't been examining the actual bits being proposed. I would strongly suggest following this approach in MyFaces as well. On this basis, I'm -1 (non-binding as I'm not on the PMC). Craig +1 for my vote -- Matthias Wessendorf Aechterhoek 18 48282 Emsdetten blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com --Matthias WessendorfAechterhoek 1848282 Emsdettenblog: http://jroller.com/page/mwessendorfmail: mwessendorf-at-gmail-dot-com
Re: [Vote] Release Tomahawk 1.1.3
-1, show stopper bug!
It just so happens that today I decided that I would upgrade my
company's web application to myfaces 1.1.3 and tomahawk 1.1.3 and in
the process ran into a major bug. I will file this immediately after
this post in jira, but felt that it was important to mention it on
this thread so that the developers have an opportunity to take
appropriate measures.
After the merge of the tomahawk data table with the newspaper table, a
bug was introduced that causes faulty behavior in the rendering of the
row-level attributes. The problem stems from the fact that
setRowIndex() occurs after the renderRowStart() in
HtmlTableRendererBase. Consequently, all the row-level expressions
are off by one row, and the first row has no data.
Take the following example and run it to see what I am talking about:
t:dataTable var=item value=#{bean.items} rowIndexVar=index
h:column
row index: h:outputText value=#{index} /; item: h:outputText
value=#{item} /
/h:column
/t:dataTable
I built the code today from the tag 1_1_3. Unless this was something
recently fixed in the trunk, it probably still exists.
/dan
On 6/9/06, Craig McClanahan [EMAIL PROTECTED] wrote:
On 6/9/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Craig-
thanks for heads up. That particular RC for the Tomahawk 1.1.3 is
listed available for download under [1]. That Shared 2.0.2 thing is
*no* extra jar to be added to your WEB-INF/lib. The Shared clazzes are
included in Tomahawk
(org.apache.myfaces.shared_tomahawk.**)
The folder [1] also contains a pom file for that Tomahawk 1.1.3 RC
OK, good ... I see that the proposed bits have indeed been published to a
special repository for testing, and thereby withdraw my -1. But I still
recommend a [VOTE] message for a release should specifically include such a
URL (and perhaps instructions on how to temporarily modify your Maven
settings to download and test this version) instead of just assuming that
everyone knows where the bits are, and what to do.
-Matthias
Craig
[1] http://tinyurl.com/mu4t9
On 6/9/06, Craig McClanahan [EMAIL PROTECTED] wrote:
On 6/9/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
This is a vote to release Tomahawk 1.1.3 (and its dependencies:
MyFaces Shared 2.0.2 and MyFaces Maven 1.0.3.)
I should have spoken up earlier on, but I have a problem with this
approach
to release votes.
In the Struts world, the release manager tends to put up a particular
set of
bits in his or her personal directory on people.apache.org, and then
posts
the vote request as I propose to release *this set of bits* ... That
way,
the other committers can download and check out exactly what is being
proposed.
Yes, with Maven based builds it is easy to assume that you and I will
build
identical artifacts, but it is still easier than you think for that not
to
be the case. Besides that, we caught packaging errors in several of the
recent Struts Action Framework and Shale builds that would not have been
caught if we hadn't been examining the actual bits being proposed.
I would strongly suggest following this approach in MyFaces as well.
On this basis, I'm -1 (non-binding as I'm not on the PMC).
Craig
+1 for my vote
--
Matthias Wessendorf
Aechterhoek 18
48282 Emsdetten
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
--
Matthias Wessendorf
Aechterhoek 18
48282 Emsdetten
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
--
Daniel Allen
Registered Linux User #231597
Mojavelinux.com: Open Source Advocacy
http://www.mojavelinux.com
While I make a strong effort to keep up with my email on a daily basis,
life and work come first and, at times, keep me away from my mail for a
while. If you contact me and then don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
Re: [Vote] Release Tomahawk 1.1.3
Sorry, my example is flawed because I forgot to use one of the
row-level attributes. Please see the bug report for the correct
example:
http://issues.apache.org/jira/browse/TOMAHAWK-485
/dan
On 6/9/06, Dan Allen [EMAIL PROTECTED] wrote:
-1, show stopper bug!
It just so happens that today I decided that I would upgrade my
company's web application to myfaces 1.1.3 and tomahawk 1.1.3 and in
the process ran into a major bug. I will file this immediately after
this post in jira, but felt that it was important to mention it on
this thread so that the developers have an opportunity to take
appropriate measures.
After the merge of the tomahawk data table with the newspaper table, a
bug was introduced that causes faulty behavior in the rendering of the
row-level attributes. The problem stems from the fact that
setRowIndex() occurs after the renderRowStart() in
HtmlTableRendererBase. Consequently, all the row-level expressions
are off by one row, and the first row has no data.
Take the following example and run it to see what I am talking about:
t:dataTable var=item value=#{bean.items} rowIndexVar=index
h:column
row index: h:outputText value=#{index} /; item: h:outputText
value=#{item} /
/h:column
/t:dataTable
I built the code today from the tag 1_1_3. Unless this was something
recently fixed in the trunk, it probably still exists.
/dan
On 6/9/06, Craig McClanahan [EMAIL PROTECTED] wrote:
On 6/9/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Craig-
thanks for heads up. That particular RC for the Tomahawk 1.1.3 is
listed available for download under [1]. That Shared 2.0.2 thing is
*no* extra jar to be added to your WEB-INF/lib. The Shared clazzes are
included in Tomahawk
(org.apache.myfaces.shared_tomahawk.**)
The folder [1] also contains a pom file for that Tomahawk 1.1.3 RC
OK, good ... I see that the proposed bits have indeed been published to a
special repository for testing, and thereby withdraw my -1. But I still
recommend a [VOTE] message for a release should specifically include such a
URL (and perhaps instructions on how to temporarily modify your Maven
settings to download and test this version) instead of just assuming that
everyone knows where the bits are, and what to do.
-Matthias
Craig
[1] http://tinyurl.com/mu4t9
On 6/9/06, Craig McClanahan [EMAIL PROTECTED] wrote:
On 6/9/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
This is a vote to release Tomahawk 1.1.3 (and its dependencies:
MyFaces Shared 2.0.2 and MyFaces Maven 1.0.3.)
I should have spoken up earlier on, but I have a problem with this
approach
to release votes.
In the Struts world, the release manager tends to put up a particular
set of
bits in his or her personal directory on people.apache.org, and then
posts
the vote request as I propose to release *this set of bits* ... That
way,
the other committers can download and check out exactly what is being
proposed.
Yes, with Maven based builds it is easy to assume that you and I will
build
identical artifacts, but it is still easier than you think for that not
to
be the case. Besides that, we caught packaging errors in several of the
recent Struts Action Framework and Shale builds that would not have been
caught if we hadn't been examining the actual bits being proposed.
I would strongly suggest following this approach in MyFaces as well.
On this basis, I'm -1 (non-binding as I'm not on the PMC).
Craig
+1 for my vote
--
Matthias Wessendorf
Aechterhoek 18
48282 Emsdetten
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
--
Matthias Wessendorf
Aechterhoek 18
48282 Emsdetten
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
--
Daniel Allen
Registered Linux User #231597
Mojavelinux.com: Open Source Advocacy
http://www.mojavelinux.com
While I make a strong effort to keep up with my email on a daily basis,
life and work come first and, at times, keep me away from my mail for a
while. If you contact me and then don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
--
Daniel Allen
Registered Linux User #231597
Mojavelinux.com: Open Source Advocacy
http://www.mojavelinux.com
While I make a strong effort to keep up with my email on a daily basis,
life and work come first and, at times, keep me away from my mail for a
while. If you contact me and then don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
Re: [Vote] Release Tomahawk 1.1.3
Ok Craig, thanks. Next rc we will take care of that. -Matthias On 6/9/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 6/9/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Craig- thanks for heads up. That particular RC for the Tomahawk 1.1.3 is listed available for download under [1]. That Shared 2.0.2 thing is *no* extra jar to be added to your WEB-INF/lib. The Shared clazzes are included in Tomahawk (org.apache.myfaces.shared_tomahawk.**) The folder [1] also contains a pom file for that Tomahawk 1.1.3 RC OK, good ... I see that the proposed bits have indeed been published to a special repository for testing, and thereby withdraw my -1. But I still recommend a [VOTE] message for a release should specifically include such a URL (and perhaps instructions on how to temporarily modify your Maven settings to download and test this version) instead of just assuming that everyone knows where the bits are, and what to do. -Matthias Craig [1] http://tinyurl.com/mu4t9 On 6/9/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 6/9/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: This is a vote to release Tomahawk 1.1.3 (and its dependencies: MyFaces Shared 2.0.2 and MyFaces Maven 1.0.3.) I should have spoken up earlier on, but I have a problem with this approach to release votes. In the Struts world, the release manager tends to put up a particular set of bits in his or her personal directory on people.apache.org, and then posts the vote request as I propose to release *this set of bits* ... That way, the other committers can download and check out exactly what is being proposed. Yes, with Maven based builds it is easy to assume that you and I will build identical artifacts, but it is still easier than you think for that not to be the case. Besides that, we caught packaging errors in several of the recent Struts Action Framework and Shale builds that would not have been caught if we hadn't been examining the actual bits being proposed. I would strongly suggest following this approach in MyFaces as well. On this basis, I'm -1 (non-binding as I'm not on the PMC). Craig +1 for my vote -- Matthias Wessendorf Aechterhoek 18 48282 Emsdetten blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf Aechterhoek 18 48282 Emsdetten blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf Aechterhoek 18 48282 Emsdetten blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
