[jira] [Created] (MYFACES-3905) The caption facet is not documented for the tag h:datatable.
Paul Spencer created MYFACES-3905: - Summary: The caption facet is not documented for the tag h:datatable. Key: MYFACES-3905 URL: https://issues.apache.org/jira/browse/MYFACES-3905 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.2.3 Reporter: Paul Spencer Priority: Trivial The caption facet is not documented for the tag h:datatable. Per Leonardo: getCaption(), so there is no @JSFFacet. Yes, you can create an issue as with priority trivial in: -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: [jira] Resolved: (TRINIDAD-7) Project not listed in Apache's project catalog http://projects.apache.org/
Tobago is listed even though it is a sub project of MyFaces. See http://projects.apache.org/indexes/pmc.html#Apache%20MyFaces Paul Spencer On Jan 16, 2010, at 10:57 AM, Matthias Weßendorf (JIRA) wrote: [ https://issues.apache.org/jira/browse/TRINIDAD-7?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias Weßendorf resolved TRINIDAD-7. --- Resolution: Invalid myfaces is listed there, this is a subproject of myfaces; also i added the doap plugin to our reporting; but site-deploy is down, currently Project not listed in Apache's project catalog http://projects.apache.org/ -- Key: TRINIDAD-7 URL: https://issues.apache.org/jira/browse/TRINIDAD-7 Project: MyFaces Trinidad Issue Type: Task Components: Build Affects Versions: 1.0.1-incubating-core-SNAPSHOT Reporter: Paul Spencer Assignee: Matthias Weßendorf Priority: Minor This project not listed in Apache's project catalog http://projects.apache.org/ . It needs to be added. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1386) Add tr:selectManyCheckbox to render a list of select items as checkboxs
Add tr:selectManyCheckbox to render a list of select items as checkboxs
-
Key: TRINIDAD-1386
URL: https://issues.apache.org/jira/browse/TRINIDAD-1386
Project: MyFaces Trinidad
Issue Type: New Feature
Components: Components
Affects Versions: 1.0.10-core, 1.2.10-core
Reporter: Paul Spencer
I have list of select items that are currently rendered using
tr:selectManyListbox that I would like to see rendered as checkboxes across
many columns. The primary reason is to display a greater number of choices to
the user at one time.As an example, a 3 column list of Users would like the
following:
Users:_ Sam Smith _ Jane Doe _Jerry James
_ Bill Smith _ Sam Sneed _ Tom Jones
A suggested tag would be a combination of tr:selectManyListbox and
tr:panelList. For the above example I would expect the tag to be:
tr:selectManyCheckbox rows=2' maxColumns=3 label=Users
value=#{selectedUsers}
f:selectItem itemValue=Sam Smith/
f:selectItem itemValue=Bil Smith/
/tr:selectManyCheckbox
Other implementation notes:
o f:selectItems can be used in place of tr;selectItem
o Rules around the ordering of the check boxes should be similar to the
ordering rules in tr:panelList
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: New MyFaces PMC chair
Congratulations Matthias! Paul Spencer Manfred Geiler wrote: Please welcome our new MyFaces PMC chair Matthias Wessendorf! As some of you already might know, I had decided to step down as the chair. The MyFaces PMC members then voted for Matthias Wessendorf as the successor and yesterday the board approved the change. Matthias, thanks for beeing up to that job. I personally have great confidence in you and wish you all the best for guiding us into the JSF 2.0 era. Regards, Manfred Geiler
Re: [VOTE] Release of Trinidad 1.2.10
+1 Matthias Wessendorf wrote: Hi, I was running the needed tasks to get the 1.2.10 release of the Apache MyFaces Trinidad CORE out. The artifacts are deployed to my private Apache account ([1]). Please take a look at the 1.2.10 artifacts and vote [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Matthias [1] http://people.apache.org/~matzew/trinidad1210/
Re: [VOTE] Release of Trinidad 1.2.10
Where can I find the proposed release notes? BTW: I will not be able to look at the artifacts until this evening, Eastern Standard Time, at the earliest. Paul Spencer Matthias Wessendorf wrote: Hi, I was running the needed tasks to get the 1.2.10 release of the Apache MyFaces Trinidad CORE out. The artifacts are deployed to my private Apache account ([1]). Please take a look at the 1.2.10 artifacts and vote [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Matthias [1] http://people.apache.org/~matzew/trinidad1210/
Re: [VOTE] Release of Trinidad 1.2.10
Where can I find the proposed release notes? BTW: I will not be able to look at the artifacts until this evening, Eastern Standard Time, at the earliest. Paul Spencer Matthias Wessendorf wrote: Hi, I was running the needed tasks to get the 1.2.10 release of the Apache MyFaces Trinidad CORE out. The artifacts are deployed to my private Apache account ([1]). Please take a look at the 1.2.10 artifacts and vote [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Matthias [1] http://people.apache.org/~matzew/trinidad1210/
Re: tomahawk examples design proposal
Thomas, I like the new layout. It is obvious to the user what the underlying code looks like! Their are some Selenium test using the current examples that are part part of Tomahawk[1]. The tests not only serve as an example on how to test a MyFaces web application, they also provide a place for regression testing. When Shale Test v1.1 is released, then Tomahawk can be tested against other implementations using the same test. I ask that Selenium testing be include in the redesigned examples. Paul Spencer [1]http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/examples/simple/src/test/selenium/ Thomas Spiegl wrote: attached you'll find a proposal for a redesign of tomahawk examples. Please tell me, which one you like better. IRIAN will take care of implementing it over the next couple of weeks. regards, thomas
[jira] Created: (TRINIDAD-1252) Tag Attributes duplicated in trace level logging.
Tag Attributes duplicated in trace level logging. - Key: TRINIDAD-1252 URL: https://issues.apache.org/jira/browse/TRINIDAD-1252 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.2.9-core Reporter: Paul Spencer Priority: Minor Some attributes, like renderType and title, are duplicated in trace level logging. The log output below is based on the following jspx. You will notice duplicate attributes in both tr:document and tr:outputText. ?xml version=1.0 encoding=iso-8859-1 standalone=yes ? jsp:root xmlns:jsp=http://java.sun.com/JSP/Page; version=2.0 xmlns:f=http://java.sun.com/jsf/core; xmlns:tr=http://myfaces.apache.org/trinidad; jsp:directive.page contentType=text/html;charset=utf-8 / f:view tr:document title=My Title! tr:outputText value=Hello World! / /tr:document /f:view /jsp:root TRACE - View after rendering UIViewRoot id=j_id_jsp_880081898_0 org.apache.myfaces.FORMER_CHILD_IDS=[j_id_jsp_880081898_1] org.apache.myfaces.BOUND_VIEW_ROOT=true afterPhaseListener=NULL beforePhaseListener=NULL facetCount=0 family=javax.faces.ViewRoot locale=en renderKitId=org.apache.myfaces.trinidad.core rendered=true rendererType=NULL rendersChildren=false transient=false viewId=/documentTest.jspx org.apache.myfaces.trinidad.component.core.CoreDocument id=j_id_jsp_880081898_1 title=My Title! org.apache.myfaces.FORMER_CHILD_IDS=[j_id_jsp_880081898_2] rendererType=org.apache.myfaces.trinidad.Document attributeChangeListener=NULL attributeChangeListeners=NULL facesBean=NULL facetCount=NULL facetNames=NULL family=NULL initialFocusId=NULL inlineStyle=NULL metaContainer=NULL mode=default onclick=NULL ondblclick=NULL onkeydown=NULL onkeypress=NULL onkeyup=NULL onload=NULL onmousedown=NULL onmousemove=NULL onmouseout=NULL onmouseover=NULL onmouseup=NULL onunload=NULL partialTriggers=NULL rendered=true rendererType=org.apache.myfaces.trinidad.Document rendersChildren=NULL shortDesc=NULL styleClass=NULL title=My Title! transient=NULL org.apache.myfaces.trinidad.component.core.output.CoreOutputText id=j_id_jsp_880081898_2 value=Hello World! rendererType=org.apache.myfaces.trinidad.Text attributeChangeListener=NULL attributeChangeListeners=NULL converter=NULL description=NULL escape=true facesBean=NULL facetCount=NULL facetNames=NULL family=NULL inlineStyle=NULL localValue=NULL onclick=NULL ondblclick=NULL onkeydown=NULL onkeypress=NULL onkeyup=NULL onmousedown=NULL onmousemove=NULL onmouseout=NULL onmouseover=NULL onmouseup=NULL partialTriggers=NULL rendered=true rendererType=org.apache.myfaces.trinidad.Text rendersChildren=NULL shortDesc=NULL styleClass=NULL transient=NULL truncateAt=0 / /org.apache.myfaces.trinidad.component.core.CoreDocument /UIViewRoot -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Make dev@ private?
Andrew, The dev@ mailing list is described on the Jakarts site[1] as: The Developer lists where you can send questions and comments about the actual software source code and general development types of questions. Making the developer list private is extreme and I would resist this change. Their are many productive discussion on the developer list that include non-committers or non-pmc members. Are the posting to the developer list because the question is not answered on the user list? If so, then lets address this problem first. If not, then should the response to an user@ post on the dev@ list be something like You have posted this to the wrong list, please repost this on the user@ list The dev@ mailing list is described on the Jakarts site[1] as: The Developer lists where you can send questions and comments about the actual software source code and general development types of questions. Making the developer list private is extreme. Their are many discussion on the developer list that include non-committers or non-pmc members. Paul Spencer [1]http://jakarta.apache.org/site/mail.html Andrew Robinson wrote: Is it possible to make dev@ a private mailing list, so only commiters and people that PMCs decide should have access to post are allowed to send emails to this list? That way we can reduce the accidental posting to dev@ instead of [EMAIL PROTECTED] -Andrew
Re: Test cases
I would suggest also running the Selenium test in Tomahawk [1]. Paul Spencer [1] http://myfaces.apache.org/tomahawk/testing/selenium.html v aditya wrote: Hi all, I have edited some of the implementation files of My Faces. Do someone have the test cases which are used to test the original My Faces implementation? So that I can test the changes I made . thanks in advance!!!
[TRINIDAD] License files for both current version contains How to apply the Apache License to your work.
The license file contains instructions to the developer that I suspect should be removed from the distribution. Below is the text in question: APPENDIX: How to apply the Apache License to your work. To apply the Apache License to your work, attach the following boilerplate notice, with the fields enclosed by brackets [] replaced with your own identifying information. (Don't include the brackets!) The text should be enclosed in the appropriate comment syntax for the file format. We also recommend that a file or class name and description of purpose be included on the same printed page as the copyright notice for easier identification within third-party archives. Copyright [] [name of copyright owner] Licensed under the Apache License, Version 2.0 (the License); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. This test can be found in the following license files: http://svn.apache.org/viewvc/myfaces/trinidad/trunk/LICENSE.txt?view=markup http://svn.apache.org/viewvc/myfaces/trinidad/trunk_1.2.x/LICENSE.txt?view=log Paul Spencer
Re: [TRINIDAD] License files for both current version contains How to apply the Apache License to your work.
I will fix this. Paul Spencer Matthias Wessendorf wrote: since you have commit rights, can you fix that ? -M On Wed, Jul 23, 2008 at 9:33 PM, Paul Spencer [EMAIL PROTECTED] wrote: The license file contains instructions to the developer that I suspect should be removed from the distribution. Below is the text in question: APPENDIX: How to apply the Apache License to your work. To apply the Apache License to your work, attach the following boilerplate notice, with the fields enclosed by brackets [] replaced with your own identifying information. (Don't include the brackets!) The text should be enclosed in the appropriate comment syntax for the file format. We also recommend that a file or class name and description of purpose be included on the same printed page as the copyright notice for easier identification within third-party archives. Copyright [] [name of copyright owner] Licensed under the Apache License, Version 2.0 (the License); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. This test can be found in the following license files: http://svn.apache.org/viewvc/myfaces/trinidad/trunk/LICENSE.txt?view=markup http://svn.apache.org/viewvc/myfaces/trinidad/trunk_1.2.x/LICENSE.txt?view=log Paul Spencer
Re: [VOTE] layout for myfaces-commons project
I am one who is using JSF 1.1 for some applications. This is because the applications are running software/hardware environments which do not support JSF 1.2. For applications in environment that will support JSF 1.2, I use JSF 1.2. Future JSF version are inevitable, thus a solution must not be limited to support for JSF 1.1. At some point a support for a JSF version must be scaled back to bug fixes. Below is a starting point for a long term solution. We have several different customer facing project ( MyFaces,Tomahawk, Trinidad, Tobago, Orchestra, and Portal Bridge) the must address this JSF version issue. Most restrict a JSF version to a Major.Minor version of the project. Tomahawk I know support both JSF versions in the same project version. If all customer facing projects adopt a restrict a JSF version to a Major.Minor project version paradigm, then we can drop support for a JSF version in the common projects with out holding back functionality in the customer facing project because that functionality can not be implement in the older JSF implementation. The illustration below is for one customer facing project the is dependent on one common project. When the project started, only JSF 1.1 was supported. When support for JSF 1.2 was added, the common project was able to support both JSF versions. As functionality was added and bug fixed, the common project was able to support both JSF versions. Version 1.1/2.3 of the customer facing application are functionally equivalent, but the the common project had to be split off JSF 1.1 into a branch, keep JSF 1.2 and JSF 2.0 support together. JSF 1.1JSF 1.2 JSF 2.0 CF VerCP Ver CF Ver CP Ver CF Ver CP Ver -- -- -- -- -- 1.1.0 1.0.0 1.1.1 1.1.0 1.2.1 1.1.0 1.1.2 1.2.0 1.2.2 1.2.0 1.1.3 1.2.1 1.2.3 1.3.0 2.0.0 1.3.0 1.1.3.1 1.2.2 1.2.4 1.3.1 2.0.1 1.4.0 CF Ver = Version of customer facing project CP Ver = Version of common project Version 1.1.3 and 1.2.3 and 2.0.0 are functionally equivalent, the older JSF uses a different version of the common library. Version 1.1.3.1 is a bug fix release this has no function equivalent in the other JSF implementations. Paul Spencer Simon Lessard wrote: Hi all, I have to agree with Andrew here. One year ago, JEE5 server were still scarce or underused, thus supporting the maintained two branches argument, but now is no longer the case and splitting efforts between two code bases doesn't sound most efficient. Regards ~ Simon On Fri, Jun 20, 2008 at 11:00 AM, Andrew Robinson [EMAIL PROTECTED] wrote: JSR 252 (JSF 1.2) was finalized on 2006-05-11 Java 1.5 released 2004-09-30 I don't mind people maintaining JSF 1.1, but I do think that there is very good cause to have 1.1 moved to branches and the latest JSF specification as the trunk for each project. Over 2 years is plenty of time to adopt JSF 1.2. If you choose to stay on an old API, there is just cause to not have the latest and greatest code available. For those that wish to stay on and support 1.1 on a branch, that is perfectly fine, but I think it is time to stop burdening every developer with supporting legacy code without just cause. Other technologies support the latest, and I think 2 years is plenty of notice to users. My $2 (gas price inflation from cents to dollars) -Andrew On Fri, Jun 20, 2008 at 3:14 AM, Mario Ivankovits [EMAIL PROTECTED] wrote: simon schrieb: In other words, keeping one line of code makes sense (less maintenance) even if we lose some JSF1.2/JSF2.0-specific features or performance boosts. While I second the rest of your mail, I wont do so with the sentence above. We are developers, and, at least in your younger years ;-), you'd like to keep up with technology and use the newest things. And JSF 1.2 is anything else then new today, not to speak about JSF 1.1. In contrast, we spent alot of time to make our JSF 1.1 development upward compatible. I don't think that we are responsible to provide a vital community around a library which itself depends on a stone old architecture. So, yes to one line of code, but I'd like to see the bundle Tomahawk+JSF1.1 frozen. Anything new should go to a JSF 1.2 native Tomahawk. And JSF 2.0 release date + (lets say) half year the same should count for Tomhawk JSF 1.2 then. Ciao, Mario
Re: [VOTE] layout for myfaces-commons project
Scott O'Bryan wrote: Partially ignore this.. :) Let me clairify now that I understand your proposal.. I think projects need to be in charge of their own destiny based off of need/usage.. :) Indeed Trinidad has a 1.0.8 branch and a 1.2.8 branch which is (mostly) functionally equivalent. But I wouldn't say that you can take code written for 1.2.8 and use it on 1.0.8. You should be able to, however, do the opposite. So the rules in Trinidad are that items added to the 1.0.x branch MUST be added to the equivalent 1.2.x branchin order to provide a clean upgrade path. The project should document their policy. It is the job of the PMC and the community to hold the project to their stated policy. As for the commons, I think it's largely irrelivant. Commons should be more stable API and functionality wise (and we should do everything in our power to ensure this). As such, if Trinidad had a minimum requirement of myfaces-commons-utils 1.2.2 and Tobago had a minimum requirement of myfaces-commons-utils 1.2.8, Trinidad should work with 1.2.8 as well. I think on the commons side, we can just release each branch as needed because, especially starting off, we're going to have projects which will require a release of commons in order to do their release. Especially if there are some enhancements. In the illustration, only the major.minor version of common project change when the JSF support changes. I agree within a major.minor version upward compatibility is the goal, which puts an emphasis on testing. In your example of using Trinidad with the 1.2.8 utils sounds reasonable because the JSF version support did not change. The rules around version numbers for the common projects need to be defined so the depend projects know what to expect. Paul Spencer Scott Scott O'Bryan wrote: Paul, why do the CF versions have to be different. This is no different (IMO) then what I was talking about except that we could not FORCE people to backport everything. I don't see why libraries for older JSF's HAVE to be functionally equivalent. That is not to say that API's started in 1.2 shouldn't be upheld in the 2.0 version, but why should the 2.0 libraries only contain functionality relivent to 1.2.. I think the older branches could be move back as needed and the only real concern we need to have, therefore, is for forward compatibility except by exception. As for JDK, if we support JSF 1.1, we should build off JDK 1.4. If we support JSF 1.2, then there is no reason NOT to use JDK 1.5. If we support JSF 2.0, then I think 1.6 is the minimum requirement. Scott Paul Spencer wrote: I am one who is using JSF 1.1 for some applications. This is because the applications are running software/hardware environments which do not support JSF 1.2. For applications in environment that will support JSF 1.2, I use JSF 1.2. Future JSF version are inevitable, thus a solution must not be limited to support for JSF 1.1. At some point a support for a JSF version must be scaled back to bug fixes. Below is a starting point for a long term solution. We have several different customer facing project ( MyFaces,Tomahawk, Trinidad, Tobago, Orchestra, and Portal Bridge) the must address this JSF version issue. Most restrict a JSF version to a Major.Minor version of the project. Tomahawk I know support both JSF versions in the same project version. If all customer facing projects adopt a restrict a JSF version to a Major.Minor project version paradigm, then we can drop support for a JSF version in the common projects with out holding back functionality in the customer facing project because that functionality can not be implement in the older JSF implementation. The illustration below is for one customer facing project the is dependent on one common project. When the project started, only JSF 1.1 was supported. When support for JSF 1.2 was added, the common project was able to support both JSF versions. As functionality was added and bug fixed, the common project was able to support both JSF versions. Version 1.1/2.3 of the customer facing application are functionally equivalent, but the the common project had to be split off JSF 1.1 into a branch, keep JSF 1.2 and JSF 2.0 support together. JSF 1.1JSF 1.2 JSF 2.0 CF VerCP Ver CF Ver CP Ver CF Ver CP Ver -- -- -- -- -- 1.1.0 1.0.0 1.1.1 1.1.0 1.2.1 1.1.0 1.1.2 1.2.0 1.2.2 1.2.0 1.1.3 1.2.1 1.2.3 1.3.0 2.0.0 1.3.0 1.1.3.1 1.2.2 1.2.4 1.3.1 2.0.1 1.4.0 CF Ver = Version of customer facing project CP Ver = Version of common project Version 1.1.3 and 1.2.3 and 2.0.0 are functionally equivalent, the older JSF uses a different version of the common library. Version 1.1.3.1 is a bug fix release this has no function equivalent in the other JSF implementations. Paul Spencer Simon
[jira] Commented: (TRINIDAD-1089) trinidad-demo.war does not run in non-J2EE container as distributed.
[ https://issues.apache.org/jira/browse/TRINIDAD-1089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12604230#action_12604230 ] Paul Spencer commented on TRINIDAD-1089: Shale is looking into the use of classifiers in Maven to distribute jdk specific variants of an artifact. Assuming classifiers work as expected, this may be a way to easily distribute container specific wars. I have asked a question about classifiers on the Maven user list with the subject Are classifiers the answer, are they mature, what are the pitfalls?[1] Paul Spencer [1] http://markmail.org/message/l6v3nbnb6qwrdduy trinidad-demo.war does not run in non-J2EE container as distributed. Key: TRINIDAD-1089 URL: https://issues.apache.org/jira/browse/TRINIDAD-1089 Project: MyFaces Trinidad Issue Type: Improvement Components: Documentation Affects Versions: 1.0.8-core, 1.2.8-core Reporter: Paul Spencer Assignee: Scott O'Bryan The trinidad-demo.war does not run in a non-J2EE container, like Tomcat, as distributed in examples.zip/tar.gz. This is due to a missing JSTL jar which is provided by a J2EE container. This improvement is simplify the process of installing the demo in a non-J2EE container. Changes should include documentation included in the distribution and available on demo project's web site. Additional change may be required in the POM. Their is a related thread titled Trinidad] Should a non-J2EE demo war be added to the distribution in the myfaces-dev mailing list. [1] *** * The procedure I used to run trinidad-demo.war in Tomcat 6.0.16 *** 1) Download the examples distribution 2) Copy the trinidad-demo.war from the distribution to Tomcat's webapps directory 3) After Tomcat exploded the war, I copied jstl-1.2.jar into the WEB-INF/lib directory of the exploded war. 4) Restart tomcat. [1] http://markmail.org/message/7ah2zedr57ppzfx6 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Is their a comparison of Trinidad, Tobago, Tomahawk,...?
I am staring a new project that will use JSF. MyFaces has quite a collection of JSF components and it is challenging, if not discouraging, to determine which component, or components, to use for a specific project. Yes, each component contains a description of what does, but I have yet to find one place with a comparison that can be used to answer the question Which component(s) should I use? Is their a comparison of Trinidad, Tobago, Tomahawk,... that compares each components features, requirements, intended uses, status (active/deprecated/...), ...? Paul Spencer
Re: [myfaces commons] discussion about reorganization of this project is required!
Leonardo Uribe wrote: Hi I'll start to upgrade component from sandbox to tomahawk. The first item on my list of todos is move this converters and validators (first check and solve possible issues on JIRA) s:convertBoolean s:convertDateTime s:convertNumber s:validateCompareTo s:validateCSV s:validateISBN s:validateUrl Please note that long time ago this upgrade was approved, but this was not applied due to code generation discussion. file:///C:/GSOC/workspace/tomahawk-compgen/oldsandbox-site/tlddoc/s/validateUrl.html Actually on tomahawk exists this validators: t:validateCreditCard t:validateEmail t:validateEqual t:validateRegExpr The idea is that all this converters and validators be on myfaces-commons. But originally tomahawk is 1.1 compatible, and there was comments about commons should have 1.1 and 1.2 converters and validators. If this is true, tomahawk should refer myfaces commons converters and validators on its tld, and have dependecies to commons (if false this is valid only for 1.2). +1 for true. The thought of maintaining 2 sets of converts/valdiators is unnerving. The new unpack plugin allow us to manage this issues more easily, enforcing just the necessary files to maintain. In order to be consistent with this intentions my first approach would be: 1. Use this layout for myfaces-commons: myfaces-commons-converters myfaces-commons-converters12 myfaces-commons-validators myfaces-commons-validators12 myfaces-commons-utils 2. Use myfaces-builder-plugin for this stuff. 3. Refer converters and validator from commons to tomahawk tld (the intention is avoid changes on existing applications). I suggest deprecating the existing converters/validators. Suggestions are welcome o What is the impact on the other components, i.e. Trinidad/Tobago/...? o Is this to be included in Tomahawk 1.1.7? o How long do you expect this to take, i.e. days/weeks/months/... ? (I am only asking to set expectation on release schedules) o Where is the new unpack plugin documented? regards Leonardo Uribe Paul Spencer
[jira] Commented: (TOMAHAWK-1022) HtmlMessage and HtmlMessages fails unit test when using RI
[ https://issues.apache.org/jira/browse/TOMAHAWK-1022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12602258#action_12602258 ] Paul Spencer commented on TOMAHAWK-1022: I have no objections on removing setParent(). HtmlMessage and HtmlMessages fails unit test when using RI -- Key: TOMAHAWK-1022 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1022 Project: MyFaces Tomahawk Issue Type: Bug Components: Message(s) Affects Versions: 1.1.6, 1.1.7-SNAPSHOT Reporter: Paul Spencer Fix For: 1.1.7-SNAPSHOT Below are output from the test failures. The test are run using the following command: cd tomahawk/core mvn test -Djsf=ri --- Test set: org.apache.myfaces.component.html.ext.HtmlMessagesTest --- Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.094 sec FAILURE! testDefaultRenderer(org.apache.myfaces.component.html.ext.HtmlMessagesTest) Time elapsed: 0.032 sec ERROR! java.lang.IllegalStateException: Parent was not null, but this component not related at javax.faces.component.UIComponentBase.eraseParent(UIComponentBase.java:457) at javax.faces.component.UIComponentBase.access$500(UIComponentBase.java:76) at javax.faces.component.UIComponentBase$ChildrenList.add(UIComponentBase.java:1496) at org.apache.myfaces.component.html.ext.HtmlMessagesTest.testDefaultRenderer(HtmlMessagesTest.java:66) --- Test set: org.apache.myfaces.component.html.ext.HtmlMessageTest --- Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.031 sec FAILURE! testDefaultRenderer(org.apache.myfaces.component.html.ext.HtmlMessageTest) Time elapsed: 0 sec ERROR! java.lang.IllegalStateException: Parent was not null, but this component not related at javax.faces.component.UIComponentBase.eraseParent(UIComponentBase.java:457) at javax.faces.component.UIComponentBase.access$500(UIComponentBase.java:76) at javax.faces.component.UIComponentBase$ChildrenList.add(UIComponentBase.java:1496) at org.apache.myfaces.component.html.ext.HtmlMessageTest.testDefaultRenderer(HtmlMessageTest.java:66) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-1023) HtmlInputHidden fails unit test when using RI
[ https://issues.apache.org/jira/browse/TOMAHAWK-1023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12602261#action_12602261 ] Paul Spencer commented on TOMAHAWK-1023: I have no objections to #2 as long as the test is a valid test. Please note the test cases use renderers defined in org.apache.myfaces.test.utils.TestUtils.addDefaultRenderers() [1]. This is because Shale-test 1.0.x does not read faces.xml. Shale-262 [2] resolves this issue in version 1.1. [1]http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/core/src/test/java/org/apache/myfaces/test/utils/TestUtils.java?view=markup [2]http://issues.apache.org/struts/browse/SHALE-262 HtmlInputHidden fails unit test when using RI - Key: TOMAHAWK-1023 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1023 Project: MyFaces Tomahawk Issue Type: Bug Affects Versions: 1.1.6, 1.1.7-SNAPSHOT Reporter: Paul Spencer Fix For: 1.1.7-SNAPSHOT --- Test set: org.apache.myfaces.component.html.ext.HtmlInputHiddenTest Below are output from the test failures. The test are run using the following command: cd tomahawk/core mvn test -Djsf=ri --- Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.016 sec FAILURE! testDefaultRenderer(org.apache.myfaces.component.html.ext.HtmlInputHiddenTest) Time elapsed: 0.016 sec FAILURE! junit.framework.AssertionFailedError: ID is not null at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.assertTrue(Assert.java:20) at junit.framework.Assert.assertNotNull(Assert.java:220) at org.apache.myfaces.test.AbstractTomahawkViewControllerTestCase.assertIdExists(AbstractTomahawkViewControllerTestCase.java:88) at org.apache.myfaces.component.html.ext.HtmlInputHiddenTest.testDefaultRenderer(HtmlInputHiddenTest.java:64) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[Fwd: [VOTE] Release Shale 1.0.5]
I am not in a position to runthe staged release of 1.0.5 against Tomahawk 1.1.7-SNAPSHOT. If some can this would be great. Please note that Tomahawk only use the shale-test feature of Shale. Paul Spencer ---BeginMessage--- A set of artifacts for Shale 1.0.5 is now ready. Please review the artifacts mentioned below and vote accordingly. Since this is my first time as release manager I wouldn't be surprised if something is missing or if I've included things that shouldn't be included, so I'd appreciate as thorough a review as you have time for. In particular I see a lot of Maven artifacts and zip files that were not included in previous releases so I wonder if they are meant to be release (the *test* artifacts for example). (1) The repository has been tagged here: http://svn.apache.org/repos/asf/shale/framework/tags/SHALE_1_0_5/ (2) The Maven artifacts are staged here: http://people.apache.org/builds/shale/shale-1.0.5/m2-staging-repository/ org.apache.shale.extras:mailreader-jpa:1.0.5 org.apache.shale:shale-application:1.0.5 org.apache.shale:shale-apps-parent:1.0.5 org.apache.shale:shale-blank:1.0.5 org.apache.shale:shale-clay-usecases:1.0.5 org.apache.shale:shale-clay:1.0.5 org.apache.shale:shale-core:1.0.5 org.apache.shale:shale-dialog-basic:1.0.5 org.apache.shale:shale-dialog-scxml:1.0.5 org.apache.shale:shale-dialog:1.0.5 org.apache.shale:shale-mailreader-jpa:1.0.5 org.apache.shale:shale-mailreader:1.0.5 org.apache.shale:shale-parent:1.0.5 org.apache.shale:shale-remoting:1.0.5 org.apache.shale:shale-spring:1.0.5 org.apache.shale:shale-sql-browser:1.0.5 org.apache.shale:shale-test-core:1.0.5 org.apache.shale:shale-test-dialog-basic:1.0.5 org.apache.shale:shale-test-dialog-scxml:1.0.5 org.apache.shale:shale-test-tiger:1.0.5 org.apache.shale:shale-blank:1.0.5 org.apache.shale:shale-test-view:1.0.5 org.apache.shale:shale-tiger:1.0.5 org.apache.shale:shale-usecases:1.0.5 org.apache.shale:shale-validator:1.0.5 org.apache.shale:shale-view:1.0.5 (3) The release artifacts are available here: http://people.apache.org/builds/shale/shale-1.0.5/dist/ mailreader-jpa-1.0.5.zip shale-blank-1.0.5.zip shale-clay-usecases-1.0.5.zip shale-framework-1.0.5.zip shale-mailreader-1.0.5.zip shale-mailreader-jpa-1.0.5.zip shale-sql-browser-1.0.5.zip shale-test-core-1.0.5.zip shale-test-dialog-basic-1.0.5.zip shale-test-dialog-scxml-1.0.5.zip shale-test-tiger-1.0.5.zip shale-test-view-1.0.5.zip shale-usecases-1.0.5.zip (4) The release notes are here, for ready reference: http://people.apache.org/~greddin/release-notes-1.0.5.html (5) Vote Please review these artifacts, signatures and checksums, and vote whether we should release them as Apache Shale version 1.0.5. --8 [ ] +1 (Binding) for PMC members only [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released A quality vote (per module, where necessary) will be held later on if this passes. Thank you!! Greg ---End Message---
Re: svn commit: r663341 - in /myfaces/tomahawk/trunk/core/src: main/java/org/apache/myfaces/component/html/ext/ main/java/org/apache/myfaces/renderkit/html/ext/ test/java/org/apache/myfaces/component/
Leonardo,
Was HtmlHiddenRenderer.java add just to make the test pass, or is it
need to when Tomahawk is run with the RI?
Paul Spencer
[EMAIL PROTECTED] wrote:
Author: lu4242
Date: Wed Jun 4 11:53:57 2008
New Revision: 663341
URL: http://svn.apache.org/viewvc?rev=663341view=rev
Log:
TOMAHAWK-1023 HtmlInputHidden fails unit test when using RI
Added:
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/renderkit/html/ext/HtmlHiddenRenderer.java
(with props)
Modified:
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/component/html/ext/AbstractHtmlInputHidden.java
myfaces/tomahawk/trunk/core/src/test/java/org/apache/myfaces/component/html/ext/HtmlInputHiddenTest.java
myfaces/tomahawk/trunk/core/src/test/java/org/apache/myfaces/test/utils/TestUtils.java
Modified:
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/component/html/ext/AbstractHtmlInputHidden.java
URL:
http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/component/html/ext/AbstractHtmlInputHidden.java?rev=663341r1=663340r2=663341view=diff
==
---
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/component/html/ext/AbstractHtmlInputHidden.java
(original)
+++
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/component/html/ext/AbstractHtmlInputHidden.java
Wed Jun 4 11:53:57 2008
@@ -42,7 +42,7 @@
implements ForceIdAware
{
public static final String COMPONENT_TYPE =
org.apache.myfaces.HtmlInputHidden;
-public static final String DEFAULT_RENDERER_TYPE = javax.faces.Hidden;
+public static final String DEFAULT_RENDERER_TYPE =
org.apache.myfaces.Hidden;
public AbstractHtmlInputHidden()
{
Added:
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/renderkit/html/ext/HtmlHiddenRenderer.java
URL:
http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/renderkit/html/ext/HtmlHiddenRenderer.java?rev=663341view=auto
==
---
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/renderkit/html/ext/HtmlHiddenRenderer.java
(added)
+++
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/renderkit/html/ext/HtmlHiddenRenderer.java
Wed Jun 4 11:53:57 2008
@@ -0,0 +1,90 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * License); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.myfaces.renderkit.html.ext;
+
+import java.io.IOException;
+
+import javax.faces.component.UIComponent;
+import javax.faces.component.UIInput;
+import javax.faces.component.UIOutput;
+import javax.faces.context.FacesContext;
+import javax.faces.context.ResponseWriter;
+import javax.faces.convert.ConverterException;
+
+import org.apache.myfaces.shared_tomahawk.renderkit.JSFAttr;
+import org.apache.myfaces.shared_tomahawk.renderkit.RendererUtils;
+import org.apache.myfaces.shared_tomahawk.renderkit.html.HTML;
+import org.apache.myfaces.shared_tomahawk.renderkit.html.HtmlRenderer;
+import org.apache.myfaces.shared_tomahawk.renderkit.html.HtmlRendererUtils;
+
+
+/**
+ * @JSFRenderer
+ * renderKitId=HTML_BASIC
+ * family=javax.faces.Input
+ * type=org.apache.myfaces.Hidden
+ *
+ * @author Thomas Spiegl (latest modification by $Author$)
+ * @author Anton Koinov
+ * @version $Revision$ $Date$
+ */
+public class HtmlHiddenRenderer
+extends HtmlRenderer
+{
+public void encodeEnd(FacesContext facesContext, UIComponent uiComponent)
+throws IOException
+{
+RendererUtils.checkParamValidity(facesContext, uiComponent,
UIInput.class);
+
+ResponseWriter writer = facesContext.getResponseWriter();
+
+writer.startElement(HTML.INPUT_ELEM, uiComponent);
+writer.writeAttribute(HTML.TYPE_ATTR, HTML.INPUT_TYPE_HIDDEN, null);
+
+String clientId = uiComponent.getClientId(facesContext);
+writer.writeAttribute(HTML.ID_ATTR, clientId, null);
+writer.writeAttribute(HTML.NAME_ATTR, clientId, null);
+
+String value = RendererUtils.getStringValue(facesContext, uiComponent);
+if (value != null)
+{
+writer.writeAttribute
Re: svn commit: r663341 - in /myfaces/tomahawk/trunk/core/src: main/java/org/apache/myfaces/component/html/ext/ main/java/org/apache/myfaces/renderkit/html/ext/ test/java/org/apache/myfaces/component/
Leonardo,
Was HtmlHiddenRenderer.java add just to make the test pass, or is it
need to when Tomahawk is run with the RI?
Paul Spencer
[EMAIL PROTECTED] wrote:
Author: lu4242
Date: Wed Jun 4 11:53:57 2008
New Revision: 663341
URL: http://svn.apache.org/viewvc?rev=663341view=rev
Log:
TOMAHAWK-1023 HtmlInputHidden fails unit test when using RI
Added:
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/renderkit/html/ext/HtmlHiddenRenderer.java
(with props)
Modified:
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/component/html/ext/AbstractHtmlInputHidden.java
myfaces/tomahawk/trunk/core/src/test/java/org/apache/myfaces/component/html/ext/HtmlInputHiddenTest.java
myfaces/tomahawk/trunk/core/src/test/java/org/apache/myfaces/test/utils/TestUtils.java
Modified:
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/component/html/ext/AbstractHtmlInputHidden.java
URL:
http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/component/html/ext/AbstractHtmlInputHidden.java?rev=663341r1=663340r2=663341view=diff
==
---
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/component/html/ext/AbstractHtmlInputHidden.java
(original)
+++
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/component/html/ext/AbstractHtmlInputHidden.java
Wed Jun 4 11:53:57 2008
@@ -42,7 +42,7 @@
implements ForceIdAware
{
public static final String COMPONENT_TYPE =
org.apache.myfaces.HtmlInputHidden;
-public static final String DEFAULT_RENDERER_TYPE = javax.faces.Hidden;
+public static final String DEFAULT_RENDERER_TYPE =
org.apache.myfaces.Hidden;
public AbstractHtmlInputHidden()
{
Added:
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/renderkit/html/ext/HtmlHiddenRenderer.java
URL:
http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/renderkit/html/ext/HtmlHiddenRenderer.java?rev=663341view=auto
==
---
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/renderkit/html/ext/HtmlHiddenRenderer.java
(added)
+++
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/renderkit/html/ext/HtmlHiddenRenderer.java
Wed Jun 4 11:53:57 2008
@@ -0,0 +1,90 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * License); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.myfaces.renderkit.html.ext;
+
+import java.io.IOException;
+
+import javax.faces.component.UIComponent;
+import javax.faces.component.UIInput;
+import javax.faces.component.UIOutput;
+import javax.faces.context.FacesContext;
+import javax.faces.context.ResponseWriter;
+import javax.faces.convert.ConverterException;
+
+import org.apache.myfaces.shared_tomahawk.renderkit.JSFAttr;
+import org.apache.myfaces.shared_tomahawk.renderkit.RendererUtils;
+import org.apache.myfaces.shared_tomahawk.renderkit.html.HTML;
+import org.apache.myfaces.shared_tomahawk.renderkit.html.HtmlRenderer;
+import org.apache.myfaces.shared_tomahawk.renderkit.html.HtmlRendererUtils;
+
+
+/**
+ * @JSFRenderer
+ * renderKitId=HTML_BASIC
+ * family=javax.faces.Input
+ * type=org.apache.myfaces.Hidden
+ *
+ * @author Thomas Spiegl (latest modification by $Author$)
+ * @author Anton Koinov
+ * @version $Revision$ $Date$
+ */
+public class HtmlHiddenRenderer
+extends HtmlRenderer
+{
+public void encodeEnd(FacesContext facesContext, UIComponent uiComponent)
+throws IOException
+{
+RendererUtils.checkParamValidity(facesContext, uiComponent,
UIInput.class);
+
+ResponseWriter writer = facesContext.getResponseWriter();
+
+writer.startElement(HTML.INPUT_ELEM, uiComponent);
+writer.writeAttribute(HTML.TYPE_ATTR, HTML.INPUT_TYPE_HIDDEN, null);
+
+String clientId = uiComponent.getClientId(facesContext);
+writer.writeAttribute(HTML.ID_ATTR, clientId, null);
+writer.writeAttribute(HTML.NAME_ATTR, clientId, null);
+
+String value = RendererUtils.getStringValue(facesContext, uiComponent);
+if (value != null)
+{
+writer.writeAttribute
HtmlHiddenRenderer.java uses Java 5 annotations. was (Re: svn commit: r663341 -... )
Leonardo,
HtmlHiddenRenderer.java uses Java 5 annotations. Tomahawk must work in
Java 1.4
Paul Spencer
[EMAIL PROTECTED] wrote:
Author: lu4242
Date: Wed Jun 4 11:53:57 2008
New Revision: 663341
URL: http://svn.apache.org/viewvc?rev=663341view=rev
Log:
TOMAHAWK-1023 HtmlInputHidden fails unit test when using RI
Added:
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/renderkit/html/ext/HtmlHiddenRenderer.java
(with props)
Modified:
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/component/html/ext/AbstractHtmlInputHidden.java
myfaces/tomahawk/trunk/core/src/test/java/org/apache/myfaces/component/html/ext/HtmlInputHiddenTest.java
myfaces/tomahawk/trunk/core/src/test/java/org/apache/myfaces/test/utils/TestUtils.java
Modified:
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/component/html/ext/AbstractHtmlInputHidden.java
URL:
http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/component/html/ext/AbstractHtmlInputHidden.java?rev=663341r1=663340r2=663341view=diff
==
---
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/component/html/ext/AbstractHtmlInputHidden.java
(original)
+++
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/component/html/ext/AbstractHtmlInputHidden.java
Wed Jun 4 11:53:57 2008
@@ -42,7 +42,7 @@
implements ForceIdAware
{
public static final String COMPONENT_TYPE =
org.apache.myfaces.HtmlInputHidden;
-public static final String DEFAULT_RENDERER_TYPE = javax.faces.Hidden;
+public static final String DEFAULT_RENDERER_TYPE =
org.apache.myfaces.Hidden;
public AbstractHtmlInputHidden()
{
Added:
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/renderkit/html/ext/HtmlHiddenRenderer.java
URL:
http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/renderkit/html/ext/HtmlHiddenRenderer.java?rev=663341view=auto
==
---
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/renderkit/html/ext/HtmlHiddenRenderer.java
(added)
+++
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/renderkit/html/ext/HtmlHiddenRenderer.java
Wed Jun 4 11:53:57 2008
@@ -0,0 +1,90 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * License); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.myfaces.renderkit.html.ext;
+
+import java.io.IOException;
+
+import javax.faces.component.UIComponent;
+import javax.faces.component.UIInput;
+import javax.faces.component.UIOutput;
+import javax.faces.context.FacesContext;
+import javax.faces.context.ResponseWriter;
+import javax.faces.convert.ConverterException;
+
+import org.apache.myfaces.shared_tomahawk.renderkit.JSFAttr;
+import org.apache.myfaces.shared_tomahawk.renderkit.RendererUtils;
+import org.apache.myfaces.shared_tomahawk.renderkit.html.HTML;
+import org.apache.myfaces.shared_tomahawk.renderkit.html.HtmlRenderer;
+import org.apache.myfaces.shared_tomahawk.renderkit.html.HtmlRendererUtils;
+
+
+/**
+ * @JSFRenderer
+ * renderKitId=HTML_BASIC
+ * family=javax.faces.Input
+ * type=org.apache.myfaces.Hidden
+ *
+ * @author Thomas Spiegl (latest modification by $Author$)
+ * @author Anton Koinov
+ * @version $Revision$ $Date$
+ */
+public class HtmlHiddenRenderer
+extends HtmlRenderer
+{
+public void encodeEnd(FacesContext facesContext, UIComponent uiComponent)
+throws IOException
+{
+RendererUtils.checkParamValidity(facesContext, uiComponent,
UIInput.class);
+
+ResponseWriter writer = facesContext.getResponseWriter();
+
+writer.startElement(HTML.INPUT_ELEM, uiComponent);
+writer.writeAttribute(HTML.TYPE_ATTR, HTML.INPUT_TYPE_HIDDEN, null);
+
+String clientId = uiComponent.getClientId(facesContext);
+writer.writeAttribute(HTML.ID_ATTR, clientId, null);
+writer.writeAttribute(HTML.NAME_ATTR, clientId, null);
+
+String value = RendererUtils.getStringValue(facesContext, uiComponent);
+if (value != null)
+{
+writer.writeAttribute(HTML.VALUE_ATTR, value
Re: svn commit: r663341 - in /myfaces/tomahawk/trunk/core/src: main/java/org/apache/myfaces/component/html/ext/ main/java/org/apache/myfaces/renderkit/html/ext/ test/java/org/apache/myfaces/component/
Leonardo,
Should HtmlHiddenRenderer.java be removed when we update to Shale 1.1?
Paul Spencer
Leonardo Uribe wrote:
On Wed, Jun 4, 2008 at 2:28 PM, Paul Spencer [EMAIL PROTECTED] wrote:
Leonardo,
Was HtmlHiddenRenderer.java add just to make the test pass, or is it
need to when Tomahawk is run with the RI?
Really it is not necessary to tomahawk runs with the RI, but it is necessary
to make the test pass, because TestUtils.addDefaultRenderers() add this as
javax.faces.Hidden renderer:
addRenderer(facesContext, javax.faces.Input, javax.faces.Hidden,
org.apache.myfaces.renderkit.html.HtmlHiddenRenderer);
If the test can read the faces-config.xml file there is no problem, but in
that case the class referred on jsf ri does not exists.
Paul Spencer
[EMAIL PROTECTED] wrote:
Author: lu4242
Date: Wed Jun 4 11:53:57 2008
New Revision: 663341
URL: http://svn.apache.org/viewvc?rev=663341view=rev
Log:
TOMAHAWK-1023 HtmlInputHidden fails unit test when using RI
Added:
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/renderkit/html/ext/HtmlHiddenRenderer.java
(with props)
Modified:
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/component/html/ext/AbstractHtmlInputHidden.java
myfaces/tomahawk/trunk/core/src/test/java/org/apache/myfaces/component/html/ext/HtmlInputHiddenTest.java
myfaces/tomahawk/trunk/core/src/test/java/org/apache/myfaces/test/utils/TestUtils.java
Modified:
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/component/html/ext/AbstractHtmlInputHidden.java
URL:
http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/component/html/ext/AbstractHtmlInputHidden.java?rev=663341r1=663340r2=663341view=diff
==
---
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/component/html/ext/AbstractHtmlInputHidden.java
(original)
+++
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/component/html/ext/AbstractHtmlInputHidden.java
Wed Jun 4 11:53:57 2008
@@ -42,7 +42,7 @@
implements ForceIdAware
{
public static final String COMPONENT_TYPE =
org.apache.myfaces.HtmlInputHidden;
-public static final String DEFAULT_RENDERER_TYPE =
javax.faces.Hidden;
+public static final String DEFAULT_RENDERER_TYPE =
org.apache.myfaces.Hidden;
public AbstractHtmlInputHidden()
{
Added:
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/renderkit/html/ext/HtmlHiddenRenderer.java
URL:
http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/renderkit/html/ext/HtmlHiddenRenderer.java?rev=663341view=auto
==
---
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/renderkit/html/ext/HtmlHiddenRenderer.java
(added)
+++
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/renderkit/html/ext/HtmlHiddenRenderer.java
Wed Jun 4 11:53:57 2008
@@ -0,0 +1,90 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * License); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.myfaces.renderkit.html.ext;
+
+import java.io.IOException;
+
+import javax.faces.component.UIComponent;
+import javax.faces.component.UIInput;
+import javax.faces.component.UIOutput;
+import javax.faces.context.FacesContext;
+import javax.faces.context.ResponseWriter;
+import javax.faces.convert.ConverterException;
+
+import org.apache.myfaces.shared_tomahawk.renderkit.JSFAttr;
+import org.apache.myfaces.shared_tomahawk.renderkit.RendererUtils;
+import org.apache.myfaces.shared_tomahawk.renderkit.html.HTML;
+import org.apache.myfaces.shared_tomahawk.renderkit.html.HtmlRenderer;
+import
org.apache.myfaces.shared_tomahawk.renderkit.html.HtmlRendererUtils;
+
+
+/**
+ * @JSFRenderer
+ * renderKitId=HTML_BASIC
+ * family=javax.faces.Input
+ * type=org.apache.myfaces.Hidden
+ * + * @author Thomas Spiegl (latest modification by $Author$)
+ * @author Anton Koinov
+ * @version $Revision$ $Date$
+ */
+public class HtmlHiddenRenderer
+extends HtmlRenderer
+{
+public void encodeEnd(FacesContext facesContext, UIComponent
uiComponent)
+throws IOException
Re: Tomahawk next release!
Hazen, For a list of pending issues, look at the roadmap for 1.1.7-SNAPSHOT. Paul Spencer Hazem Saleh wrote: Hi Team, I just want to ask when can we Tomahawk next release ? We can list all the pending issues (if we have), so we can work on to have a near release of the library. Thanks all!
Re: Tomahawk next release!
Hazen, The roadmap is found in the issue tracking system[1], JIRA. Paul Spencer [1]http://issues.apache.org/jira/browse/TOMAHAWK?report=com.atlassian.jira.plugin.system.project:roadmap-panel Hazem Saleh wrote: Hi Paul, Where can I get Tomahawk 1.1.7 RoadMap? Thanks! On Tue, Jun 3, 2008 at 9:36 PM, Paul Spencer [EMAIL PROTECTED] wrote: Hazen, For a list of pending issues, look at the roadmap for 1.1.7-SNAPSHOT. Paul Spencer Hazem Saleh wrote: Hi Team, I just want to ask when can we Tomahawk next release ? We can list all the pending issues (if we have), so we can work on to have a near release of the library. Thanks all!
[jira] Created: (TRINIDAD-1089) trinidad-demo.war does not run in non-J2EE container as distributed.
trinidad-demo.war does not run in non-J2EE container as distributed. Key: TRINIDAD-1089 URL: https://issues.apache.org/jira/browse/TRINIDAD-1089 Project: MyFaces Trinidad Issue Type: Improvement Components: Documentation Affects Versions: 1.2.8-core, 1.0.8-core Reporter: Paul Spencer The trinidad-demo.war does not run in a non-J2EE container, like Tomcat, as distributed in examples.zip/tar.gz. This is due to a missing JSTL jar which is provided by a J2EE container. This improvement is simplify the process of installing the demo in a non-J2EE container. Changes should include documentation included in the distribution and available on demo project's web site. Additional change may be required in the POM. Their is a related thread titled Trinidad] Should a non-J2EE demo war be added to the distribution in the myfaces-dev mailing list. [1] *** * The procedure I used to run trinidad-demo.war in Tomcat 6.0.16 *** 1) Download the examples distribution 2) Copy the trinidad-demo.war from the distribution to Tomcat's webapps directory 3) After Tomcat exploded the war, I copied jstl-1.2.jar into the WEB-INF/lib directory of the exploded war. 4) Restart tomcat. [1] http://markmail.org/message/7ah2zedr57ppzfx6 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[Trinidad] Should a non-J2EE demo war be added to the distribution?
The current Trinidad demo will not work in a non-J2EE container, i.e. Tomcat 6.0, because it does not contain the JSTL jar. Should we add a non-J2EE demo to the distribution? I would say yes because it simplifies the process of getting the demo running in an not-J2EE environment. Paul Spencer
Re: [Trinidad] Should a non-J2EE demo war be added to the distribution?
Scott, Well I sort of assumed that people wanting configurations outside of the standard supported J2EE configuration would compile the branch themselves. And this is document where :) http://myfaces.apache.org/trinidad/trinidad-1_2/FAQ.html http://myfaces.apache.org/trinidad/trinidad-1_2/trinidad-demo/index.html I am of the opinion that a demo/example should run as distributed and the installation should be intuitive. In this case the distribution is build for a J2EE environment, but it is not obvious to anyone installing it. Paul Spencer Scott O'Bryan wrote: Well I sort of assumed that people wanting configurations outside of the standard supported J2EE configuration would compile the branch themselves. Scott Paul Spencer wrote: Scott, If the Demo includes JSTL, will it work on a J2EE server? ( I suspect the server will/should complain when 2 copies/version of JSTL exists ) If not then when should distribute : A) J2EE version and non-J2EE version of Example.zip/tar.gz or B) Example.zip/tar.gz containing a J2EE and non-J2EE version of trinidad-demo.war and trinidad-blank.war Paul Spencer Scott O'Bryan wrote: IMO this isn't necessary. We already control whether we deploy the myfaces jars using a profile. Can't we add a profile which includes the JSTL jars in the demo when it's built? Also, it should be easy enough to add them to tomcat as a shared library as well. Scott Paul Spencer wrote: The current Trinidad demo will not work in a non-J2EE container, i.e. Tomcat 6.0, because it does not contain the JSTL jar. Should we add a non-J2EE demo to the distribution? I would say yes because it simplifies the process of getting the demo running in an not-J2EE environment. Paul Spencer
Re: [Trinidad] Should a non-J2EE demo war be added to the distribution?
Scott and Andrew, The goal is to make it easy for a user to get the demo up and running with minimal frustration. Since I am not currently working in a J2EE environment, my desire to quickly get the demo running in order to test the 1.2.8 release did not include a J2EE server. I dropped the war in an available Tomcat server and then had to determine why the demo failed to run. After determining the I need a JSTL jar, I was able to test the release. I make the following suggested solutions, in order of preference: 1) distribute a non-J2EE Demo and Blank either in the existing Example distribution or in an non-J2EE distribution. 2) Add installation instruction that include instructions for J2EE and non-J2EE environments. The instructions, including any required jars, should be included in the .zip/.tar.gz file. 3) Add instructions on building a non-J2EE environment from the source. What ever solution is chosen, the instructions should also be on the Demo's web page[1]. Paul Spencer [1]http://myfaces.apache.org/trinidad/trinidad-1_2/trinidad-demo/index.html Scott O'Bryan wrote: Andrew, Yeah, that's what I proposed. Paul wants us to distribute the non-j2ee version with our examples... Scott Andrew Robinson wrote: We can relatively easily create a tomcat profile that could be used to deploy onto tomcat by changing the dependency scope from to provided to compile right? Just as we have the jetty profile and the jetty plugin registered, we can do the same for tomcat I think. The drawback of course is maintaining the poms for different servers -Andrew On Wed, May 21, 2008 at 1:36 PM, Scott O'Bryan [EMAIL PROTECTED] wrote: Well documentation is easy. I'm just not excited about having to maintain two trees or wasting a lot of spacing building multiple versions of a demo application when all someone has to do is look at the pre-req's and make sure it's available in their environment. Scott Paul Spencer wrote: Scott, Well I sort of assumed that people wanting configurations outside of the standard supported J2EE configuration would compile the branch themselves. And this is document where :) http://myfaces.apache.org/trinidad/trinidad-1_2/FAQ.html http://myfaces.apache.org/trinidad/trinidad-1_2/trinidad-demo/index.html I am of the opinion that a demo/example should run as distributed and the installation should be intuitive. In this case the distribution is build for a J2EE environment, but it is not obvious to anyone installing it. Paul Spencer Scott O'Bryan wrote: Well I sort of assumed that people wanting configurations outside of the standard supported J2EE configuration would compile the branch themselves. Scott Paul Spencer wrote: Scott, If the Demo includes JSTL, will it work on a J2EE server? ( I suspect the server will/should complain when 2 copies/version of JSTL exists ) If not then when should distribute : A) J2EE version and non-J2EE version of Example.zip/tar.gz or B) Example.zip/tar.gz containing a J2EE and non-J2EE version of trinidad-demo.war and trinidad-blank.war Paul Spencer Scott O'Bryan wrote: IMO this isn't necessary. We already control whether we deploy the myfaces jars using a profile. Can't we add a profile which includes the JSTL jars in the demo when it's built? Also, it should be easy enough to add them to tomcat as a shared library as well. Scott Paul Spencer wrote: The current Trinidad demo will not work in a non-J2EE container, i.e. Tomcat 6.0, because it does not contain the JSTL jar. Should we add a non-J2EE demo to the distribution? I would say yes because it simplifies the process of getting the demo running in an not-J2EE environment. Paul Spencer
Re: [TRINIDAD] The email demo and panelPageSkinDemo.jspx fail in the 1.2.8 proposed release.
Is this an issue that should be addressed before releasing 1.2.8?
Paul Spencer
Jeanne Waldman wrote:
I was just about to send out an email about this as well.
I created a project from the example war file and I see the same error.
When I comment out the skin-family in faces-config.xml I get the same
error for the accessibilityMode. Both are EL bound to the same object:
accessibility-mode#{prefs.proxy.accessibilityMode}/accessibility-mode
accessibility-profile#{prefs.proxy.accessibilityProfile}/accessibility-profile
skin-family#{prefs.proxy.skinFamily}/skin-family
The errors go away when I comment these out.
This worked when I did the same thing with the 1.2.7 demo war.
Jeanne
Paul Spencer wrote, On 5/16/2008 1:56 PM PT:
Testing the 1.2.8 proposed release.
The email demo and panelPageSkinDemo.jspx fail when using jstl-1.2.jar
instead of jstl-1.1.2.jar in WEB-INF/lib in a tomcat 6.0.16 container
May 16, 2008 4:42:12 PM javax.faces.webapp._ErrorPageWriter
handleException
SEVERE: An exception occurred
javax.el.PropertyNotFoundException: Property 'skinFamily' not found
on type java.lang.String
at
javax.el.BeanELResolver$BeanProperties.get(BeanELResolver.java:193)
at
javax.el.BeanELResolver$BeanProperties.access$400(BeanELResolver.java:170)
at javax.el.BeanELResolver.property(BeanELResolver.java:279)
at javax.el.BeanELResolver.getValue(BeanELResolver.java:60)
at
javax.el.CompositeELResolver.getValue(CompositeELResolver.java:53)
at
org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.access$301(FacesCompositeELResolver.java:46)
at
org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver$4.invoke(FacesCompositeELResolver.java:108)
at
org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.invoke(FacesCompositeELResolver.java:148)
at
org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:104)
at org.apache.el.parser.AstValue.getValue(AstValue.java:114)
at
org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:186)
at
org.apache.myfaces.trinidad.bean.FacesBeanImpl.getProperty(FacesBeanImpl.java:68)
at
org.apache.myfaces.trinidadinternal.context.RequestContextImpl.getSkinFamily(RequestContextImpl.java:230)
at
org.apache.myfaces.trinidadinternal.renderkit.core.CoreRenderingContext._initializeSkin(CoreRenderingContext.java:510)
at
org.apache.myfaces.trinidadinternal.renderkit.core.CoreRenderingContext.init(CoreRenderingContext.java:85)
at
org.apache.myfaces.trinidadinternal.renderkit.core.CoreRenderKit.encodeBegin(CoreRenderKit.java:481)
at
org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:166)
at
org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:41)
at
org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:140)
at
javax.faces.webapp.FacesServlet.service(FacesServlet.java:152)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._invokeDoFilter(TrinidadFilterImpl.java:238)
at
org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._doFilterImpl(TrinidadFilterImpl.java:195)
at
org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:138)
at
org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.myfaces.trinidaddemo.webapp.RedirectFilter.doFilter(RedirectFilter.java:97)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844
Re: [VOTE] Release of Trinidad 1.2.8
In light of the fix for TRINIDAD-1083 and issuance of TRINIDAD-1085, I remove my -1 and change it to a +1. Paul Spencer Paul Spencer wrote: Scott, Venkata has created a JIRA, TRINIDAD-1083, and attached a patch. Please regenerate the artifacts. I should be able to retest, and alter my vote, tomorrow evening. Thank you, Paul Spencer Scott O'Bryan wrote: Venkata, we'll need a JIRA issue and a patch if possible. I can apply it asap. To the community, I do have a question.. Concerning this vote we had 2.5 +1's and 1 -1. Technically I think that allows us to release but I suspect people would want to get this one fixed first. I'll allow people to chime in as needed on both this and the 1.0.8 thread if you'd like to stop the release. Once Venkata submits the patch, I can certainly apply it and generate the artifacts, but it will delay our release another 72 hours as I call another vote. So let me know what you think and I'll either complete the release tomorrow generate some new artifacts and start the vote again. Current results for 1.2.8: +1 Scott O'Bryan, Matthias Wessendorf +.5 Andrew Robinson -1 Paul Spencer because the Chart component doesn't work. Current results for 1.0.8 +1 Scott O'Bryan, Matthias Wessendorf, Andrew Robinson I'll go ahead and keep votes open for one more day to allow people to chime in or change their vote. Scott Paul Spencer wrote: Venkata, Thank you for your work on this issue. Paul Spencer venkata guddanti wrote: I believe yes. On Mon, May 19, 2008 at 1:54 PM, Paul Spencer [EMAIL PROTECTED] wrote: Venkata, Is this also an issue in 1.0.x? Paul Spencer venkata guddanti wrote: I think I found out the reason why this is not working. The ApacheChart.js is not registered in CoreCommonScriptsResourceLoader. I added the file to the debug and normal libraries list and it works. Do we need a JIRA ticket for this? Venkata On Mon, May 19, 2008 at 12:46 PM, venkata guddanti [EMAIL PROTECTED] wrote: OK, I looked at the issue. It seems that the scriptlet output is broken in the latest trunk and 1.2 trunk. The chart is rendered using ApacheChart.js on the client. The Renderer creates a new Linbrary Scriptlet( new LibraryScriptlet(ApacheChart, null)). It the uses chartLib.outputScriptlet to send the library to the browser. This seems to be broken. Looking at the page source The library written is /trinidad-demo-context-root/adf/jsLibs/DebugApacheChart1_2_8.js;jsessionid=0bef3a120e9dc7a98a8e960e4626cd56ee02bc717325f73e5bd3a0ae88bfd133. However this file seems to be invalid from the browser viewpoint. I only see jsLibsDebugs/ApacheChart.js in the output director. Does anybody know if the resource loader or something has changed in the latest release to cause this to happen? Venkata On Mon, May 19, 2008 at 12:09 PM, Scott O'Bryan [EMAIL PROTECTED] wrote: Cool, thanks Venkata, I'll wait to hear back as to whether the issue is in the demo or the component before I close the vote. Scott venkata guddanti wrote: I will investigate the chart not working in 1.2.8 today. Venkata On Thu, May 15, 2008 at 7:32 PM, Scott O'Bryan [EMAIL PROTECTED] mailto: [EMAIL PROTECTED] wrote: Hi, I was running the needed tasks to get the 1.2.8 release of the Apache MyFaces Trinidad out. The artifacts are deployed to my private Apache account ([1]). Please take a look at the 1.2.8 artifacts and vote. Please note that this is my first time putting together a release for Trinidad so if you could pay extra attention, I would be much appreciative. [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Scott [1] http://people.apache.org/~sobryan/trinidad/1.2.8http://people.apache.org/%7Esobryan/trinidad/1.2.8 http://people.apache.org/%7Esobryan/trinidad/1.2.8 http://people.apache.org/%7Esobryan/trinidad/1.2.8
Re: [VOTE] Release of Trinidad 1.2.8
Venkata, Adding a JIRA that describes the issue and the solution would not hurt. If anything it will serve as a reminder next time this occurs. Paul Spencer venkata guddanti wrote: I think I found out the reason why this is not working. The ApacheChart.js is not registered in CoreCommonScriptsResourceLoader. I added the file to the debug and normal libraries list and it works. Do we need a JIRA ticket for this? Venkata On Mon, May 19, 2008 at 12:46 PM, venkata guddanti [EMAIL PROTECTED] wrote: OK, I looked at the issue. It seems that the scriptlet output is broken in the latest trunk and 1.2 trunk. The chart is rendered using ApacheChart.js on the client. The Renderer creates a new Linbrary Scriptlet( new LibraryScriptlet(ApacheChart, null)). It the uses chartLib.outputScriptlet to send the library to the browser. This seems to be broken. Looking at the page source The library written is /trinidad-demo-context-root/adf/jsLibs/DebugApacheChart1_2_8.js;jsessionid=0bef3a120e9dc7a98a8e960e4626cd56ee02bc717325f73e5bd3a0ae88bfd133. However this file seems to be invalid from the browser viewpoint. I only see jsLibsDebugs/ApacheChart.js in the output director. Does anybody know if the resource loader or something has changed in the latest release to cause this to happen? Venkata On Mon, May 19, 2008 at 12:09 PM, Scott O'Bryan [EMAIL PROTECTED] wrote: Cool, thanks Venkata, I'll wait to hear back as to whether the issue is in the demo or the component before I close the vote. Scott venkata guddanti wrote: I will investigate the chart not working in 1.2.8 today. Venkata On Thu, May 15, 2008 at 7:32 PM, Scott O'Bryan [EMAIL PROTECTED]mailto: [EMAIL PROTECTED] wrote: Hi, I was running the needed tasks to get the 1.2.8 release of the Apache MyFaces Trinidad out. The artifacts are deployed to my private Apache account ([1]). Please take a look at the 1.2.8 artifacts and vote. Please note that this is my first time putting together a release for Trinidad so if you could pay extra attention, I would be much appreciative. [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Scott [1] http://people.apache.org/~sobryan/trinidad/1.2.8http://people.apache.org/%7Esobryan/trinidad/1.2.8 http://people.apache.org/%7Esobryan/trinidad/1.2.8
Re: [VOTE] Release of Trinidad 1.2.8
Venkata, Is this also an issue in 1.0.x? Paul Spencer venkata guddanti wrote: I think I found out the reason why this is not working. The ApacheChart.js is not registered in CoreCommonScriptsResourceLoader. I added the file to the debug and normal libraries list and it works. Do we need a JIRA ticket for this? Venkata On Mon, May 19, 2008 at 12:46 PM, venkata guddanti [EMAIL PROTECTED] wrote: OK, I looked at the issue. It seems that the scriptlet output is broken in the latest trunk and 1.2 trunk. The chart is rendered using ApacheChart.js on the client. The Renderer creates a new Linbrary Scriptlet( new LibraryScriptlet(ApacheChart, null)). It the uses chartLib.outputScriptlet to send the library to the browser. This seems to be broken. Looking at the page source The library written is /trinidad-demo-context-root/adf/jsLibs/DebugApacheChart1_2_8.js;jsessionid=0bef3a120e9dc7a98a8e960e4626cd56ee02bc717325f73e5bd3a0ae88bfd133. However this file seems to be invalid from the browser viewpoint. I only see jsLibsDebugs/ApacheChart.js in the output director. Does anybody know if the resource loader or something has changed in the latest release to cause this to happen? Venkata On Mon, May 19, 2008 at 12:09 PM, Scott O'Bryan [EMAIL PROTECTED] wrote: Cool, thanks Venkata, I'll wait to hear back as to whether the issue is in the demo or the component before I close the vote. Scott venkata guddanti wrote: I will investigate the chart not working in 1.2.8 today. Venkata On Thu, May 15, 2008 at 7:32 PM, Scott O'Bryan [EMAIL PROTECTED]mailto: [EMAIL PROTECTED] wrote: Hi, I was running the needed tasks to get the 1.2.8 release of the Apache MyFaces Trinidad out. The artifacts are deployed to my private Apache account ([1]). Please take a look at the 1.2.8 artifacts and vote. Please note that this is my first time putting together a release for Trinidad so if you could pay extra attention, I would be much appreciative. [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Scott [1] http://people.apache.org/~sobryan/trinidad/1.2.8http://people.apache.org/%7Esobryan/trinidad/1.2.8 http://people.apache.org/%7Esobryan/trinidad/1.2.8
Re: [VOTE] Release of Trinidad 1.2.8
Venkata, Thank you for your work on this issue. Paul Spencer venkata guddanti wrote: I believe yes. On Mon, May 19, 2008 at 1:54 PM, Paul Spencer [EMAIL PROTECTED] wrote: Venkata, Is this also an issue in 1.0.x? Paul Spencer venkata guddanti wrote: I think I found out the reason why this is not working. The ApacheChart.js is not registered in CoreCommonScriptsResourceLoader. I added the file to the debug and normal libraries list and it works. Do we need a JIRA ticket for this? Venkata On Mon, May 19, 2008 at 12:46 PM, venkata guddanti [EMAIL PROTECTED] wrote: OK, I looked at the issue. It seems that the scriptlet output is broken in the latest trunk and 1.2 trunk. The chart is rendered using ApacheChart.js on the client. The Renderer creates a new Linbrary Scriptlet( new LibraryScriptlet(ApacheChart, null)). It the uses chartLib.outputScriptlet to send the library to the browser. This seems to be broken. Looking at the page source The library written is /trinidad-demo-context-root/adf/jsLibs/DebugApacheChart1_2_8.js;jsessionid=0bef3a120e9dc7a98a8e960e4626cd56ee02bc717325f73e5bd3a0ae88bfd133. However this file seems to be invalid from the browser viewpoint. I only see jsLibsDebugs/ApacheChart.js in the output director. Does anybody know if the resource loader or something has changed in the latest release to cause this to happen? Venkata On Mon, May 19, 2008 at 12:09 PM, Scott O'Bryan [EMAIL PROTECTED] wrote: Cool, thanks Venkata, I'll wait to hear back as to whether the issue is in the demo or the component before I close the vote. Scott venkata guddanti wrote: I will investigate the chart not working in 1.2.8 today. Venkata On Thu, May 15, 2008 at 7:32 PM, Scott O'Bryan [EMAIL PROTECTED] mailto: [EMAIL PROTECTED] wrote: Hi, I was running the needed tasks to get the 1.2.8 release of the Apache MyFaces Trinidad out. The artifacts are deployed to my private Apache account ([1]). Please take a look at the 1.2.8 artifacts and vote. Please note that this is my first time putting together a release for Trinidad so if you could pay extra attention, I would be much appreciative. [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Scott [1] http://people.apache.org/~sobryan/trinidad/1.2.8http://people.apache.org/%7Esobryan/trinidad/1.2.8 http://people.apache.org/%7Esobryan/trinidad/1.2.8 http://people.apache.org/%7Esobryan/trinidad/1.2.8
Re: [VOTE] Release of Trinidad 1.2.8
Scott, Venkata has created a JIRA, TRINIDAD-1083, and attached a patch. Please regenerate the artifacts. I should be able to retest, and alter my vote, tomorrow evening. Thank you, Paul Spencer Scott O'Bryan wrote: Venkata, we'll need a JIRA issue and a patch if possible. I can apply it asap. To the community, I do have a question.. Concerning this vote we had 2.5 +1's and 1 -1. Technically I think that allows us to release but I suspect people would want to get this one fixed first. I'll allow people to chime in as needed on both this and the 1.0.8 thread if you'd like to stop the release. Once Venkata submits the patch, I can certainly apply it and generate the artifacts, but it will delay our release another 72 hours as I call another vote. So let me know what you think and I'll either complete the release tomorrow generate some new artifacts and start the vote again. Current results for 1.2.8: +1 Scott O'Bryan, Matthias Wessendorf +.5 Andrew Robinson -1 Paul Spencer because the Chart component doesn't work. Current results for 1.0.8 +1 Scott O'Bryan, Matthias Wessendorf, Andrew Robinson I'll go ahead and keep votes open for one more day to allow people to chime in or change their vote. Scott Paul Spencer wrote: Venkata, Thank you for your work on this issue. Paul Spencer venkata guddanti wrote: I believe yes. On Mon, May 19, 2008 at 1:54 PM, Paul Spencer [EMAIL PROTECTED] wrote: Venkata, Is this also an issue in 1.0.x? Paul Spencer venkata guddanti wrote: I think I found out the reason why this is not working. The ApacheChart.js is not registered in CoreCommonScriptsResourceLoader. I added the file to the debug and normal libraries list and it works. Do we need a JIRA ticket for this? Venkata On Mon, May 19, 2008 at 12:46 PM, venkata guddanti [EMAIL PROTECTED] wrote: OK, I looked at the issue. It seems that the scriptlet output is broken in the latest trunk and 1.2 trunk. The chart is rendered using ApacheChart.js on the client. The Renderer creates a new Linbrary Scriptlet( new LibraryScriptlet(ApacheChart, null)). It the uses chartLib.outputScriptlet to send the library to the browser. This seems to be broken. Looking at the page source The library written is /trinidad-demo-context-root/adf/jsLibs/DebugApacheChart1_2_8.js;jsessionid=0bef3a120e9dc7a98a8e960e4626cd56ee02bc717325f73e5bd3a0ae88bfd133. However this file seems to be invalid from the browser viewpoint. I only see jsLibsDebugs/ApacheChart.js in the output director. Does anybody know if the resource loader or something has changed in the latest release to cause this to happen? Venkata On Mon, May 19, 2008 at 12:09 PM, Scott O'Bryan [EMAIL PROTECTED] wrote: Cool, thanks Venkata, I'll wait to hear back as to whether the issue is in the demo or the component before I close the vote. Scott venkata guddanti wrote: I will investigate the chart not working in 1.2.8 today. Venkata On Thu, May 15, 2008 at 7:32 PM, Scott O'Bryan [EMAIL PROTECTED] mailto: [EMAIL PROTECTED] wrote: Hi, I was running the needed tasks to get the 1.2.8 release of the Apache MyFaces Trinidad out. The artifacts are deployed to my private Apache account ([1]). Please take a look at the 1.2.8 artifacts and vote. Please note that this is my first time putting together a release for Trinidad so if you could pay extra attention, I would be much appreciative. [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Scott [1] http://people.apache.org/~sobryan/trinidad/1.2.8http://people.apache.org/%7Esobryan/trinidad/1.2.8 http://people.apache.org/%7Esobryan/trinidad/1.2.8 http://people.apache.org/%7Esobryan/trinidad/1.2.8
Re: [VOTE] Release of Trinidad 1.2.8
Scott, Based on my simple application, which also uses Tomahawk 1.2.3, I give this a qualified +1. The qualified part is because I have not reviewed all of the artifacts, nor have I exercised that much of the functionality. Paul Spencer Scott O'Bryan wrote: Hi, I was running the needed tasks to get the 1.2.8 release of the Apache MyFaces Trinidad out. The artifacts are deployed to my private Apache account ([1]). Please take a look at the 1.2.8 artifacts and vote. Please note that this is my first time putting together a release for Trinidad so if you could pay extra attention, I would be much appreciative. [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Scott [1] http://people.apache.org/~sobryan/trinidad/1.2.8
Re: [VOTE] Release of Trinidad 1.2.8
I am changing my +1 to a -1 because The chart example web application does not display a chart. The 1.2.7 example web application does display the charts. FYI: I added jstl-1.1.2.jar to WEB-INF/lib to get the examples working. Paul Spencer Paul Spencer wrote: Scott, Based on my simple application, which also uses Tomahawk 1.2.3, I give this a qualified +1. The qualified part is because I have not reviewed all of the artifacts, nor have I exercised that much of the functionality. Paul Spencer Scott O'Bryan wrote: Hi, I was running the needed tasks to get the 1.2.8 release of the Apache MyFaces Trinidad out. The artifacts are deployed to my private Apache account ([1]). Please take a look at the 1.2.8 artifacts and vote. Please note that this is my first time putting together a release for Trinidad so if you could pay extra attention, I would be much appreciative. [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Scott [1] http://people.apache.org/~sobryan/trinidad/1.2.8
Re: [VOTE] Release of Trinidad 1.2.8
Matthias, What is not an issue a) The JSTL library must be added in non JavaEE 5 containers. b) Charts working in 1.2.7 and not in 1.2.8. Both version where run using Tomcat 6.0.16 and jdk 1.5.0_11. Paul Spencer Matthias Wessendorf wrote: That is not an issue. A JavaEE 5 container has to ship JSTL 1.2. So... the demo doesn't require that JSTL jar (like the actual JSF jars) Sent from my iPod. Am 16.05.2008 um 22:08 schrieb Paul Spencer [EMAIL PROTECTED]: I am changing my +1 to a -1 because The chart example web application does not display a chart. The 1.2.7 example web application does display the charts. FYI: I added jstl-1.1.2.jar to WEB-INF/lib to get the examples working. Paul Spencer Paul Spencer wrote: Scott, Based on my simple application, which also uses Tomahawk 1.2.3, I give this a qualified +1. The qualified part is because I have not reviewed all of the artifacts, nor have I exercised that much of the functionality. Paul Spencer Scott O'Bryan wrote: Hi, I was running the needed tasks to get the 1.2.8 release of the Apache MyFaces Trinidad out. The artifacts are deployed to my private Apache account ([1]). Please take a look at the 1.2.8 artifacts and vote. Please note that this is my first time putting together a release for Trinidad so if you could pay extra attention, I would be much appreciative. [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Scott [1] http://people.apache.org/~sobryan/trinidad/1.2.8
Re: [COMMUNITY] MyFaces += Hazem Saleh
Hazem, Welcome to MyFaces. Paul Spencer Manfred Geiler wrote: The Myfaces PMC is proud to announce a new addition to our community. Please welcome Hazem Saleh as the newest MyFaces committer! Hazem is an active member of the myfaces community, he contributed some cool components like captcha, password strength and provided many patches. He is also involved in the Apache Myfaces and Facelets book. @Hazem: Please add yourself to the Master-POM at https://svn.apache.org/repos/asf/myfaces/myfaces-master-pom/trunk/pom.xml --Manfred
Re: [VOTE] Release of Trinidad 1.2.8
Matthias, Matthias Wessendorf wrote: a) isn't an issue Trinidad 1.2.x requires a Java EE 5 (web) container. So is b an issue? b) Charts working in 1.2.7 and not in 1.2.8. Both version where run using Tomcat 6.0.16 and jdk 1.5.0_11. But, did 1.2.7 demo ship JSTL ? No BTW. I don't know why tomcat 6 doesn't ship jsf 1.2 and jstl 1.2 out of the box... It does not. snip Paul Spencer
[TRINIDAD] The email demo and panelPageSkinDemo.jspx fail in the 1.2.8 proposed release.
Testing the 1.2.8 proposed release. The email demo and panelPageSkinDemo.jspx fail when using jstl-1.2.jar instead of jstl-1.1.2.jar in WEB-INF/lib in a tomcat 6.0.16 container May 16, 2008 4:42:12 PM javax.faces.webapp._ErrorPageWriter handleException SEVERE: An exception occurred javax.el.PropertyNotFoundException: Property 'skinFamily' not found on type java.lang.String at javax.el.BeanELResolver$BeanProperties.get(BeanELResolver.java:193) at javax.el.BeanELResolver$BeanProperties.access$400(BeanELResolver.java:170) at javax.el.BeanELResolver.property(BeanELResolver.java:279) at javax.el.BeanELResolver.getValue(BeanELResolver.java:60) at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:53) at org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.access$301(FacesCompositeELResolver.java:46) at org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver$4.invoke(FacesCompositeELResolver.java:108) at org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.invoke(FacesCompositeELResolver.java:148) at org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:104) at org.apache.el.parser.AstValue.getValue(AstValue.java:114) at org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:186) at org.apache.myfaces.trinidad.bean.FacesBeanImpl.getProperty(FacesBeanImpl.java:68) at org.apache.myfaces.trinidadinternal.context.RequestContextImpl.getSkinFamily(RequestContextImpl.java:230) at org.apache.myfaces.trinidadinternal.renderkit.core.CoreRenderingContext._initializeSkin(CoreRenderingContext.java:510) at org.apache.myfaces.trinidadinternal.renderkit.core.CoreRenderingContext.init(CoreRenderingContext.java:85) at org.apache.myfaces.trinidadinternal.renderkit.core.CoreRenderKit.encodeBegin(CoreRenderKit.java:481) at org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:166) at org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:41) at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:140) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:152) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._invokeDoFilter(TrinidadFilterImpl.java:238) at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._doFilterImpl(TrinidadFilterImpl.java:195) at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:138) at org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.myfaces.trinidaddemo.webapp.RedirectFilter.doFilter(RedirectFilter.java:97) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:595) Paul Spencer
Re: [VOTE] Release of Trinidad 1.2.8
Matthias Wessendorf wrote: b) Charts working in 1.2.7 and not in 1.2.8. Both version where run using Tomcat 6.0.16 and jdk 1.5.0_11. Don't think that this is a show-stopper. Are there any other issues with the demo? After seeing the charts in 1.2.7, I would like to use them. So, if the issue is with the charts, then I consider this a show stopper in that functionality that works in a prior release is now broken. If the problem is in the demo, but not the charts, then the demo should be fixed soon after the release. Paul Spencer
Re: [TRINIDAD] The email demo and panelPageSkinDemo.jspx fail in the 1.2.8 proposed release.
Matthias Wessendorf wrote: Does this work w/ the RI? I do not know. This is something can test this weekend. B/c my right arm is broken, I can't test that on my own. Sorry about that. I hope it get better soon. Paul Spencer
Has someone tested charts? ( was Re: [VOTE] Release of Trinidad 1.2.8)
Matthias, I am not in a position to test the charts either. Has someone tested the charts in this proposed release? If not, will someone test them. Paul Spencer Matthias Wessendorf wrote: Matthias Wessendorf wrote: b) Charts working in 1.2.7 and not in 1.2.8. Both version where run using Tomcat 6.0.16 and jdk 1.5.0_11. Don't think that this is a show-stopper. Are there any other issues with the demo? After seeing the charts in 1.2.7, I would like to use them. So, if the issue is with the charts, then I consider this a show stopper in that functionality that works in a prior release is now broken. If the I agree problem is in the demo, but not the charts, then the demo should be fixed soon after the release. I agree as well. Can't help for some reasons. Good luck! -M Paul Spencer
[jira] Created: (TRINIDAD-1080) CSS entry for tr:icon name=... documention clairification
CSS entry for tr:icon name=... documention clairification - Key: TRINIDAD-1080 URL: https://issues.apache.org/jira/browse/TRINIDAD-1080 Project: MyFaces Trinidad Issue Type: Bug Components: Components, Documentation Affects Versions: 1.2.7-core Reporter: Paul Spencer Priority: Minor Both the TLD description of tr:icon and the Icon Skinning Key section in the Developer guide need to be updated in the following ways: o The CSS Entry associated with an name is .AFNameIcon:alias not af|name-icon o The first character of the name is upcased in the CSS entry. So tr:icon name=myLogo and tr:icon name=MyLogo both refer to the CSS entry .AFMyLogoIcon:alias -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[TRINIDAD] Type-o on web site navigation panel (site.xml)
The work Overview is misspelled in /myfaces/trinidad/trunk/src/site/site.xml. It is currently on the page as Overwie Paul Spencer
Re: [jira] Commented: (TOMAHAWK-717) Tabbed Pane: dataModel inside tabs is not updated when switching between tabs and coming back
Christian,
Adding a Selenium test case[1] would go a long way in getting this issue
resolved. You can see some examples of Selenium tests in
examples/simple/src/test/selenium[2].
If you submit a test case as a patch, I will review and commit it.
Paul Spencer
[1] http://myfaces.apache.org/tomahawk/testing/selenium.html
[2]
http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/examples/simple/src/test/selenium/
Christian Koelle (JIRA) wrote:
[ https://issues.apache.org/jira/browse/TOMAHAWK-717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12593252#action_12593252 ]
Christian Koelle commented on TOMAHAWK-717:
---
I can confirm that this bug exists.
It can be reproduced with the MyFaces-Simple-Demo-Application V. 1.1.6 on
Tomcat 5.5.20 by doing the following:
a.) Amend the content of the server-side-switched tab1 in the demo's TabbedPane.jsp to the the following, i.e. a a dataTable:
t:panelTab id=tab1 label=#{example_messages['tabbed_tab1']}
rendered=#{tabbedPaneBean.tab1Visible}
t:dataTable
headerClass=myTableHeader
rowClasses=myTableRow1,myTableRow2
var=r
preserveDataModel=false
preserveRowStates=false
preserveSort=false
value=#{tabbedPaneBean.testBeans}
h:column
f:facet name=header
h:outputText
value=--Header 1 -- /
/f:facet
t:inputText
id=inputField002
value=#{r.s1} /
/h:column
h:column
f:facet name=header
h:outputText
value=--Header 2 -- /
/f:facet
t:inputText
id=inputField001
value=#{r.s2} /
/h:column
/t:dataTable
b.) Add a TestBean to the application:
pulbic class TestBean implements Serializable{
private String _s1;
private String _s2;
// + getter and setter
}
c.) Extend the TabbedPaneBean with one property holding a list of TestBeans:
private ListTestBean testBeans;
// + getter and setter
d.) Initialise the property testBeans, with a few objects, e. g. by adding a
default contructor containing the following lines:
this.testBeans = new ArrayListTestBean();
this.testBeans.add(new TestBean());
this.testBeans.add(new TestBean());
There will be two table rows @ 2 input fields on the the tabbedPane-demopage after
this amendment. Data entered into it, will be lost on Tab-change, contrary to the
input fields outside of the t:dataTable.
As far as I could spent time to debug this, I can say that after the Apply-Request-Values-Phase (i. e. processDecodes) the UIcomponent (UIInput), which loses the entered values holds the submitted value in the attribue _submittedValue but somehow afterwards, the value will not be written into the bound bean model property.
Somehow it appears that the tabswitching has some kind of immediate-alike behaviour, i.
e. if you switch tabs, all fields of TabbedPane.jsp which are to be validated, will not
be validated, contrary to what's happening when you use the already provided Common
submit button.
It is interesting, that entered data will be correctly written to the bound model
properties, if you use UIInput-components outside of a t:dataTable as already
provided within the demo application.
Please let me know, if you need more information on this or if you cannot
reproduce it with the given information.
Regards and thanks in advance.
Christian
Tabbed Pane: dataModel inside tabs is not updated when switching between tabs
and coming back
-
Key: TOMAHAWK-717
URL: https://issues.apache.org/jira/browse/TOMAHAWK-717
Project: MyFaces Tomahawk
Issue Type: Bug
Components: Tabbed Pane
Affects Versions: 1.1.3
Reporter: Gerald Müllan
I have worked several times with the tabbed pane component, but never got aware of this bug.
There is a dataTable inside one tab and some new values were put in some input components. After switching to another tab and coming back, the values are gone and only the old ones are rendered out. This bug seems to be actual since 1.1.3 and before.
Re: dojo quo vadis
Werner, An implied restriction would be only 1 version of DoJo per webapp. Backward compatibility is my main concern. I will upgrade to the latest DoJo in implement in Tomahawk, but it will be the entire application not a page at a time. Paul Spencer My application is using the Dojo in Tomahawk now. Werner Punz wrote: Paul Spencer schrieb: Werner, I am excited to see you are planning to upgrade the DoJo support. I would like to see support for multiple versions, including the one currently in Tomahawk. The desired version to use for any project should be configurable. Hello Paul first thanks for the kind words, anyway dont expect anything too soon. (I am making good progress but there is still a load of work) Multiple versions are planned one way or the other probably I will add a source override flag to enable the loading of another dojo version instead of the default one. If I do that however there will be a culprit the old version will only be usable from the client the components will be adjusted to the latest version. And a mix of 2 versions on one page is not possible, this is a dojo inherent problem. Werner
Re: dojo quo vadis
Werner, I am excited to see you are planning to upgrade the DoJo support. I would like to see support for multiple versions, including the one currently in Tomahawk. The desired version to use for any project should be configurable. Paul Spencer Werner Punz wrote: hello everyone I just wanted to drop a short note, start a discussion here. I was busy the last few weeks regarding dojo after getting weblets 1.0 out of the door. Well here is a plan. As you all know we currently have dojo in Tomahawk, well the main issue is, this is a huge dependency. I have quietly started a small Tomahawk extension framework which should get Dojo out of Tomahawk and should encapsule the most important components. I cannot showcase too much but in a few weeks I will be able to showcase some stuff, depending on the time I can work on it. Ok here is my plan I want to get Dojo and the Dojo Initializer in its own Tomahawk dependend subproject. Dojo itself wont be packed into the sourcetree anymore, but I will move it to weblets (Actually this is working already) so that we can add it as binary dependency and also will get versioning, so that it becomes easier to change dojo versions. This stuff is working already and it works really well. What I have planned additionally, and upgrade to the latest Dojo version and encapsulation of the most important dijit components in their own tags. (This is what I am working on currently, I got my base frameworks mostly stabilized and added some code generation today(The code gens do not overlap with Leonardos and Simons work I took care of that I do not want to duplicate existing code functionalitywise)) And last but not least we have to take a proper look at the sandbox on what we will take also into our dojo extensions stuff, I want the sandbox to become smaller and I do not want a component clutter in the extension lib. This means maybe we might deprecate some sandbox components if possible. Also the moving of the sandbox components means some overhaul and some work to be done, that also means someone have to jump in here and give a helping hand. (Once the other parts are done) Those are my plans what is your opinion about this. The main issue why I started this project is to get dojo out of the tomahawk core and to make it easier to upgrade dojo. Werner
Re: shale-test location (was RE: JSF 2.0 component set)
Gary, I also use shale-test. One of the feature in the unreleased 1.1.0 allows you the test against any JSF 1.1/1.2 implementation without having to replace the faces.xml configuration inside the test. Thus keeping the test framework independent from an implantation. Which is a good thing and something I support. Gary VanMatre has been named Shale's PMC, and hopefully he, with our help, will revive the community. FYI: Their have been many threads related to moving parts of Shale into MyFaces. Lets not start another one while Shale is still alive. Paul Spencer Gary VanMatre wrote: -- Original message -- From: Scott O'Bryan [EMAIL PROTECTED] I don't really see why the physical location affects the ability to fix bugs or do enhancements in parallel, unless it depends on some common implementation classes. Or, are you talking more about releases? Well releases are part of it. I was meerly bringing up that the Bridge (even MyFaces) have impls which perform the logic for ExternalContext expected of their various specs. These are duplicated somewhat in the shale-tests. If it were moved over to faces, both the core-team and the bridge team would be able to maintain the test harnesses with the code they are writing. For instance, Mock the Bridge and Servlet API's and Mock the FacesContextFactory. It would, in turn, return an ExternalContext which (while being based off the myfaces or bridge impl) would also expose the setters needed to test thing. But ultimately, the underlying implementations would run under the covers. This would much easier reflect reality. That said, I was just bringing up the idea that I wouldn't argue against it. The Bridge (and some of the projects I'm doing in commons) need released versions of a portlet test harness and I wouldn't mind adding these test cases to Trinidad either. Whether I pull them from Shale or MyFaces makes no real difference to me, but I could help maintain them better if they were in MyFaces -- for a current committer of shale I am not. :) Well, I'm not a MyFaces committer either. Ok, I'll bore you - I had to work on Clay under Struts for 6 months submitting patches to the code I contributed before I was nominated to join. Of course, that was then and this is now but I'd like to see Shale grow as a community. The reality is that the majority of Shale was Craig's work. I don't think that anyone would dispute that. David Geary also had a hand in the inception. That's why I'm into the all or nothing versus the cafeteria plan. Shale test is one of the nuggets. The annotation and remoting are also being used as the foundation - point of discussion for JSF 2.0. Shale controller + shale dialog is a simplified version of ADFc 11g. I don't know... I think we all know how to work together amongst apache communities. I'm sorta disappointed but at the same time it makes sense. I remember Ted Husted (someone else I have great respect for) saying open source is sometimes like a jealous mistress. I think he might have told me that just before the merger with webwork. The interesting bit there is that struts 1.x code base still exists. Gary Scott Well, I'm happy whether it's in MyFaces or Shale, as long as we can update it for JSF 1.2 and the Bridge. So, if you want it to be part of MyFaces and are willing to deal with the work of getting it established, I think you'd have a good case. What do others think (especially Gary)? Kito D. Mann wrote: *From:* Gary VanMatre [mailto:[EMAIL PROTECTED] *Sent:* Wednesday, April 02, 2008 11:16 AM *To:* MyFaces Development; [EMAIL PROTECTED]; 'MyFaces Development' *Cc:* Kito D. Mann *Subject:* RE: JSF 2.0 component set From: Kito D. Mann [EMAIL PROTECTED] I just want to add that when we were talking about moving Shale over to MyFaces, people were worried about resources for maintaining it. And Shale is an *existing* code base :-). I think it'd make a lot more sense to migrate the existing suites to JSF 2 branches. The big issue I had with merging was that the majority didn't want to bring over all of shale. At this point, I don't think it would be responsible just to drop support unless you could offer a comparable feature. True. I thought it might make sense to bring the biggest pieces over to MyFaces, but if we can revive part of Shale's development, I'm fine with that too. I just wanted to avoid atrophy of the entire Shale code base :-). The shale's test library is one of the few that have not been reinvented over and over and that seemed to be where the root interest is with myfaces. In terms of maintaining Shale, we most certainly encourage contributions the same as myfaces :-) Of course :-). Gary ~~~ Kito D. Mann
Re: Wildcard patterns in javax.faces.CONFIG_FILES parameter
Danny, Sounds like a good idea. I am not sure if the non-spec compliant use of the parameter javax.faces.CONFIG_FILES in conjunction with a parameter not defined by the spec, like org.apache.myfaces.ENABLE_WILD_CARD_IN_CONFIG_FILES, would violate the spec. At the very least it would complicate the documentation of javax.faces.CONFIG_FILES. Would a better solution be to create a parameter, like org.apache.myfaces.ADDITIONAL_CONFIG_FILES, which supports wildcards and pattern matching? The resulting set of configuration files would be the config files identified by BOTH parameters. Paul Spencer Danny Robinson wrote: Guys, I don't think it's possible to dynamically specify wildcard config loading patterns for JSF currently. However, most all other frameworks today seem to be able to handle something similar for loading files by naming/location conventions. I know JSF will pick-up META-INF/faces-confg.xml inside the jars, but my concern is mainly with navigation rules and creating modular UI bundles. Would there be appetite to have this as feature in the MyFaces implementation, disabled by default (for compliant with spec.), but enabled via a config setting? Thanks, Danny
Re: [tomahawk] why bother with 1.2?
I am very invested in Tomahawk. I agree we need to simplify things, but we MUST maintain Tomahawk. If we do not, then who will use ANY of the MyFaces component libraries if we let libraries die. Paul Spencer Martin Marinschek wrote: Simon, is your conclusion then that Tomahawk should die? To be honest, my perception is quite different from this. We have a large user-base, and I'm certainly all for keeping Tomahawk up-to-date as much as possible and still improve it where we can. And, I generally don't see the use of having 10 different ways of maintaining components in MyFaces, the first step to a more maintainable Tomahawk-component-set must therefore be to change the build-system to the one used by MyFaces 1.2, Trinidad and (hopefully also) the new commons library! regards, Martin On 1/30/08, Cagatay Civici [EMAIL PROTECTED] wrote: Hi, As being the guy who has created the tomahawk 1.2 branch and spent a lot of time with it, upgrading to 1.2 is not an easy task because as Simon mentioned the code is old and crusty. I agree that non rendering stuff should be moved to commons, I've some candidates on my own from sandbox and tomahawk for commons. For autogeneration, one must generate all the component metadata, this all has been discussed on ML by the way. I still think tomahawk 1.2 makes sense. Cagatay On Jan 30, 2008 11:02 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, On Jan 30, 2008 9:53 AM, Simon Kitching [EMAIL PROTECTED] wrote: Hi, I see Leonard is currently doing a lot of work on something called tomahawk 1.2, which surprised me a little. I have checked the mail archives, and see some discussions happening around june 2007 regarding having a version of tomahawk specifically for JSF1.2. I saw the activity on tomahawk 1.2 as well, and was also a little surprised, since nothing regarding that has been discussed here on the ML. But since then, we have started apache commons. I think therefore that rather than have a tomahawk 1.2, it would be better to split tomahawk up into pieces that live in commons modules, or at least extract all the bits we can, then call the remaining bits something other than tomahawk. +1 that sounds good; commons can be used in a wider range (like in tobago, trinidad, ice-faces, ...) the additional UI comps (like nice (dojo-based) tables etc can become Tomahawk) also worth to check for promotions of the sandbox (was recently already discussed), like the PPR stuff. Tomahawk code is really rather old and crusty and I don't see a lot of point moving it as-is to JSF1.2. Getting a release of tomahawk 1.1.7 out, however, would be a very good idea. +1 here as well -Matthias Regards, Simon -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Is the version in pom.xml wrong in the 1.2 Trunk?
In the MyFaces 1.2 trunk, core/trunk_1.2.x [1], the version in pom.xml is 1.2.1-SNAPSHOT. Should it be 1.2.3-SNAPSHOT? Paul Spencer [1] http://svn.apache.org/repos/asf/myfaces/core/trunk_1.2.x/pom.xml
Tomahawk's compatibility matrix is out of date!
Tomahawk's compatibility matrix [1] is out of date. Specifically the Tomahawk 1.1.6 row and the MyFaces 1.2.0 column. I know MyFaces 1.2.1 is in the works, so whomever updates the matrix could also add this column. I am not sure of the compatibility data so did not update the table. Paul Spencer [1] http://wiki.apache.org/myfaces/CompatibilityMatrix
Re: [MyFaces 1.2.2] so... why is there no 1.2.1 (was: Re: svn commit: r613971 - /myfaces/core/branches/1_2_2prepare/)
Because artifacts where published, even if that was not the intent, the version number should be consider used. Paul Spencer Matthias Wessendorf wrote: On Jan 21, 2008 1:08 PM, Mike Kienenberger [EMAIL PROTECTED] wrote: If something was publicly released as 1.2.1 already, then -- even if it was pulled -- please do not release 1.2.1 again. it wasn't released. Just the impl jars made it to public repo. which is (from the effect) close to a release ;-) -M Skipping a version number might cause some questions on the list. However, reusing a version number will result in the end user not knowing if they have the good version or the bad version, nor will anyone who tries to help them debug issues. On Jan 21, 2008 4:00 PM, Leonardo Uribe [EMAIL PROTECTED] wrote: So we agree on 1.2.2?
Re: Taglibdoc documentation is missing for Core 1.1 and Core 1.2 projects
Simon, Thank you for correct the taglib documentation. Paul Spencer simon wrote: I looked into it a bit more. Core 11 impl did have a tlddoc report. Core 1.2 did not for some reason, but just regenerating the site fixed that. Odd. I've cleaned up the site a bit more anyway, and in particular got rid of the pointless project reports link from the core12 main site. Note that the tlddocs are reports on the *impl* modules. Thanks for reporting this. Regards, Simon On Wed, 2008-01-09 at 12:29 -0500, Paul Spencer wrote: Simon, I was looking for the tlddocs in Project Reports, which is where they have been in the past. Tomahawk still has them in Project Reports [1]. Paul Spencer [1] http://myfaces.apache.org/tomahawk/project-reports.html Simon Kitching wrote: Hi Paul, Paul Spencer [EMAIL PROTECTED] schrieb: The Taglibdoc documentation report is missing the API and Impl subprojects of the Core 1.1 and Core 1.2 projects. The documentation may be missing from other subprojects, I have not checked :( What Taglibdoc report do you mean? I cannot see any such report in the reports section of core 1.1 or core 1.2. Do you mean perhaps that there is a link in the reports section for Trinidad and you want a similar link in the reports for core too? There *are* taglib docs available via the Documentation|Javadocs link in both projects: http://myfaces.apache.org/core11/javadoc.html http://myfaces.apache.org/core12/javadoc.html Umm..well, it appears that although the direct links above work, the 1.1 stuff cannot be got to from the main page. It worked earlier today. It appears that there is some automated process (or sadistic person) periodically redeploying old versions of parts of the myfaces website. Grrr. I suspect Continuum... I'll disable website builds from continuum and redeploy core1.1 site. But the tld docs are there. It would be nice to have them in the reports section too, but I have absolutely no idea how to do that, and no interest in finding out. Feel free to implement that if you want.. Regards, Simon
Re: [Vote] MyFaces site design
I like the rounded corners and separation of #4. +1 for #4 Paul Spencer Catalin Kormos wrote: Hi, The latest designs provided by Adonis are available now at [1]; we think it would be better to do a voting on these, as there are several versions that he came up with, all quite great. Please pick one by specifying the number of the design you like, the one with the most votes will win and be integrated into the MyFaces Maven skin. Thanks, Catalin [1] http://people.apache.org/~ckormos/myfaces/vote/
Taglibdoc documentation is missing for Core 1.1 and Core 1.2 projects
The Taglibdoc documentation report is missing the API and Impl subprojects of the Core 1.1 and Core 1.2 projects. The documentation may be missing from other subprojects, I have not checked :( Paul Spencer
Re: Taglibdoc documentation is missing for Core 1.1 and Core 1.2 projects
Simon, I was looking for the tlddocs in Project Reports, which is where they have been in the past. Tomahawk still has them in Project Reports [1]. Paul Spencer [1] http://myfaces.apache.org/tomahawk/project-reports.html Simon Kitching wrote: Hi Paul, Paul Spencer [EMAIL PROTECTED] schrieb: The Taglibdoc documentation report is missing the API and Impl subprojects of the Core 1.1 and Core 1.2 projects. The documentation may be missing from other subprojects, I have not checked :( What Taglibdoc report do you mean? I cannot see any such report in the reports section of core 1.1 or core 1.2. Do you mean perhaps that there is a link in the reports section for Trinidad and you want a similar link in the reports for core too? There *are* taglib docs available via the Documentation|Javadocs link in both projects: http://myfaces.apache.org/core11/javadoc.html http://myfaces.apache.org/core12/javadoc.html Umm..well, it appears that although the direct links above work, the 1.1 stuff cannot be got to from the main page. It worked earlier today. It appears that there is some automated process (or sadistic person) periodically redeploying old versions of parts of the myfaces website. Grrr. I suspect Continuum... I'll disable website builds from continuum and redeploy core1.1 site. But the tld docs are there. It would be nice to have them in the reports section too, but I have absolutely no idea how to do that, and no interest in finding out. Feel free to implement that if you want.. Regards, Simon
Re: [COMMUNITY] MyFaces += Michael Freedman
Welcome Michael. Paul Spencer Manfred Geiler wrote: The Myfaces PMC is proud to announce a new addition to our community. Please welcome Michael Freedman as the newest MyFaces committer. Michael has been very, very active with the portlet-bridge project, has submitted a lot of patches, most of which already have been applied, and he is also active in the community. @Michael: Please add yourself to the Master-POM at https://svn.apache.org/repos/asf/myfaces/myfaces-master-pom/trunk/pom.xml --Manfred
Re: [commons] What Logger ?
I agree with Simon, that all MyFaces projects need to use one logger. That said, we must assume that application developers using MyFaces projects will not use the same logger that MyFaces uses. Thus the logger we use should be pluggable so the application developer can use one logger for his application and MyFaces. In many ways commons-logging has worked for both MyFaces and the application developer. Simon has a case in which it does not. In my case, I have used commons-logging with Log4J for years in the applications I distribute and support. The support staff and customers are trained on how to use and adjust the Log4J configuration and how to use the log files produced, so any logging changes by MyFaces will be evaluated in part on the impact to my customers and staff. Paul Spencer simon wrote: On Sun, 2007-12-16 at 12:07 +0100, Bernd Bohmann wrote: Hello, i think slf4j is a better alternative for logging compare to commons-logging. I don't like to start a slf4j vs commons-logging battle. Just ask google. I will change the tobago logging to slf4j. Asking google is a very bad idea in this case. What you get is the average opinion. And the *average* coder out there is a fool. Even sites by people claiming to be experts must be treated carefully; he who shouts loudest, and makes the boldest claims, is not always the wisest. If you do not care about supporting localised error messages, and do not intend to use slf4j-specific features like markers then the commons-logging API is the best because it is the simplest. Note that we are talking about just what API myfaces code should call. Other implementations than the one from commons can be used; for example slf4j provides one. Whether the commons-logging implementation is good can be debated, but there is nothing really wrong with the api - except *possibly* for localised messages. If you do care about supporting localised error messages, then I suggest you keep an eye on this thread: http://www.nabble.com/Internationalisation-of-log-messages-to14360301.html Commons-logging deliberately does not support localisation *within* the logging library, leaving that to the caller. But as raised in that thread, it is not currently clear that slf4j properly supports localisation either. The java.util.logging api does support localisation, but it's not clear to me that this is in practice useable. The default implementation is crap, and there are not many alternatives because the api is horrible to implement. It would be better if all the myfaces projects agree on some logging approach; otherwise an app using myfaces-core+myfaces-commons+trinidad +tobago might need 4 different logging wrappers in the classpath. Regards, Simon
Re: Merging Shale into MyFaces
Their is a feature in the SNAPSHOT version of test-framework that reads the implementation's configuration, i.e. faces.xml, when setting up the environment. This feature is valuable when testing against different implementations, i.e. RI 1.1. In tomahawk 1.1.x, I hard coded some of the configuration to enable some of the component testing. This hard coding fails when testing against the RI. At one time I did modify the test to use the SNAPSHOT version of test-framework to run the tests against the RI, but I never committed the works because I did not want to introduce a SNAPSHOT dependency. Move the test-framework into MyFaces and I will commit the work. I request that test-framework be moved into MyFace. Paul Spencer Matthias Wessendorf wrote: to bring light to this discussion; On Oct 24, 2007 8:15 AM, Martin Marinschek [EMAIL PROTECTED] wrote: For me, a merger makes sense. The question is who will do the work, though. yup! That's right. Some reflections on the modules: - ViewController/Dialog: I hope Orchestra can take in what makes sense here (the notion of subflows which I think the Orchestra VC is pretty solid, right now; I personally like it more. What potential makes sense (as an addition) is the Dialog mgr + the XML-W3C-thing (forgot the name :-) ) - Clay: Yes, obviously Facelets has won the race - we should all concentrate our efforts there, so that the JSF community can profit as a whole (and is not splitted) yes, no need for that, sorry to say. - Tiger-extensions: again, this would make sense in Orchestra, as an alternative way of configuring Orchestras beans (and also other beans, of course) to using Spring for the discussion I have the understanding, that Tiger will be used as JSF2 @nnotation solution. We should take that bit for the next impl... :) - test-framework: we've long used it in MyFaces, but for recent tests both Matthias and me have used EasyMock, it is somewhat easier to define changing interface behaviour with EasyMock than with static mock-classes. Still, this is valuable, and should be a separate module in the merger. - validators - no, probably not really please no - s:token: I'd love to have a generic way of preventing duplicated posts. But I guess this is something that Orchestra could eventually handle? apart from that, I don't know much more about Shale - sorry. other bits, that were discussed were: -AppController looks like nobody is really interested in this -Remoting sounds like a nice enhancement; and may be JSF 2.0 (as mentioned by some folks here) -Spring-Integration no need for that (Did I miss a module?) It was discussed, that Shale should have a final release; I am +1 on that. I am not sure, if all modules should really make it into MyFaces. I can see interest in these Shale-modules: -Dialog -Remoting -Test -Tiger -ViewController What happens to the rest? I don't know; Will they be maintained ? I don't know; regards, Martin On 10/22/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Ok, so what about having a 'myfaces dormant' project where each module gets added where it seems there is no real maintainer. This could be a place for abandoned sandbox stuff too. I know, the word 'maintainer' is not well placed in the context of an apache community, but in the end I think it would be fair to show to users that no one is really working on an project. Mario -Original Message- From: Grant Smith [EMAIL PROTECTED] Date: Monday, Okt 22, 2007 6:02 pm Subject: Re: Merging Shale into MyFaces To: Reply-MyFaces Development dev@myfaces.apache.orgTo: MyFaces Development dev@myfaces.apache.org Conceptually, I am in favor of a merge. I wouldn't wait for JSF 2.0 to do it, though. +1. On 10/22/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:At least, 1 year, that is my guess. So, I agree w/ Kito here -M On 10/22/07, Kito D. Mann [EMAIL PROTECTED] wrote: I don't think that's a good idea, since JSF 2.0 is a year or more away ~~~ Kito D. Mann - Author, JavaServer Faces in Action http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info -Original Message- From: Bernhard Slominski [mailto:[EMAIL PROTECTED] Sent: Monday, October 22, 2007 8:41 AM To: '[EMAIL PROTECTED]'; MyFaces Development Subject: AW: Merging Shale into MyFaces Hi all, I guess it makes sense, to make the merger a post JSF 2 project. So all features, which are included in JSF 2 (e.g Remoting) should not move, but just stay in Shale. Also let's see where templating and component development goes before making a decision about Clay. So Shale is then the JSF 1.X add-on framework, when it comes to JSF 2 all Add-Ons move to MyFaces. Bernhard -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Auftrag von Craig McClanahan Gesendet: Montag, 22. Oktober
Re: Merging Shale into MyFaces
Matthias, I made this same request, in addition to moving parts or all of Shale into MyFaces, to Wendy Smoak at ApacheCon in Atlanta. She said that she would look into it. Paul Spencer Matthias Wessendorf wrote: It was discussed, that Shale should have a final release; I am +1 on that. snip/ What do you have in mind, other than cutting the release? I may be able to help with the release (depends when etc.). v1.0.5 or v1.1.0 or both? it was now a while, since the last release; and a release (1.0.5 and 1.1.0 IMO) is needed. What happens after such a release? I don't know. Shale is quite now, besides some committs, that you do :-) I am not sure, if all modules should really make it into MyFaces. I can see interest in these Shale-modules: -Dialog -Remoting -Test -Tiger -ViewController What happens to the rest? I don't know; Will they be maintained ? I don't know; snap/ I intend to remain involved with the dialog modules, at the least. nice to hear. I have no problem with making the Shale committers MyFaces committers. Some are already. -M -Rahul
Re: [VOTE] Commons API JSF 1.2 only
+1 Andrew Robinson wrote: Lets make the myfaces commons JSF API an official vote so we can have a fixed time frame on this decision +1 [ ] -- make JSF 1.2 the minimum requirement for the new myfaces commons project +0 [ ] -- you don't mind supporting a 1.1 trunk in addition to a 1.2 trunk -1 [ ] -- you feel that 1.1 should be required and why you feel that it is needed My vote: +1 -Andrew
Re: MyFaces JSF Commons Project
Scott, My concern is when components, like Tomahawk, become dependent on JSF Commons, then they will inherit the dependencies of JSF Commons. If a component in JSF Commons is not intended to be used with JSF 1.1, or none of JSF 1.1 components, like Tomahawk, require the commons component, then I have no objection for a non-JSF 1.1. compliant dependency. Paul Spencer Scott O'Bryan wrote: Cool, I was hoping we had one. :) Paul, you mind if I ask you some questions about this? I can totally understand the want/need for the converters and validators to be ported to 1.1 (and thus need 1.4 support), but what about the utilities? Currently Trinidad, Tomahawk, and Tobago support JDK 1.1 and therefore their adoption of the common utilities would be slow if not non-existant. I know that the logic I'm trying to introduce, although it could be used in JSF 1.1 environments, really becomes most useful when dealing with JSF 1.2 and the portlet bridge. I also wouldn't think that things like unified multi-part form processing would be likely to make it into current 1.1 renderkits since it would require a lot of code to be rewritten and may not be backward compatible. Scott Paul Spencer wrote: +1 on JSF 1.2 only +1 on 1.1 support with JDK 1.5 required on both. +1 on 1.1 w/ 1.4 I have projects I support on HP-UX that are currently running JDK 1.4. Paul Spencer Andrew Robinson wrote: I would go for: +1 on JSF 1.2 only This is open source, so no one is required to use it and embracing 1.2 is only going to help the development community move forward. +0.5 on 1.1 support with JDK 1.5 required on both. Just because the specification supports 1.4 does mean libraries have to. JDK 1.5 has been out plenty long enough for companies to adopt it. If they cannot adopt it, they should be willing to forgo new libraries and functionality -1 on 1.1 w/ 1.4 This is too much work and will really hold nicer features back (I also would have no interest in developing and testing it personally). Just my $.02 -Andrew On Nov 29, 2007 10:06 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote: On Nov 29, 2007 5:57 PM, Scott O'Bryan [EMAIL PROTECTED] wrote: Hey everyone, I'm going to try to put together a proposal for some items it add to the jsf commons fairly soon for your purusal. First off, however, I'd like some technical information on this project as it may effect how the project is set up. 1. Which version of JSF will be the minimum for this project? One of my proposals involves needing an ExternalContextWrapper and the version of JSF does make a difference. I, personally, would like to see this based off 1.2 but if we need a 1.1 Faces Commons then I would recommend both a 1.1 and a 1.2 branch. here we go; my understanding is, that 1.1 is a must 2. What is the minimum JDK we are going to use for this project. My preference would be J2SE 5 for the build. I could even live with making sure that code can be compiled with J2SE 5 in 1.4 compatibility mode but I think we need to be able to support generics at the very least. Of course if we're basing the commons project off of JSF 1.2, J2SE5 is a no-brainer. :) JSF 1.1 = java1.4 JSF 1.2 = JDK5 -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: MyFaces JSF Commons Project
+1 on JSF 1.2 only +1 on 1.1 support with JDK 1.5 required on both. +1 on 1.1 w/ 1.4 I have projects I support on HP-UX that are currently running JDK 1.4. Paul Spencer Andrew Robinson wrote: I would go for: +1 on JSF 1.2 only This is open source, so no one is required to use it and embracing 1.2 is only going to help the development community move forward. +0.5 on 1.1 support with JDK 1.5 required on both. Just because the specification supports 1.4 does mean libraries have to. JDK 1.5 has been out plenty long enough for companies to adopt it. If they cannot adopt it, they should be willing to forgo new libraries and functionality -1 on 1.1 w/ 1.4 This is too much work and will really hold nicer features back (I also would have no interest in developing and testing it personally). Just my $.02 -Andrew On Nov 29, 2007 10:06 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote: On Nov 29, 2007 5:57 PM, Scott O'Bryan [EMAIL PROTECTED] wrote: Hey everyone, I'm going to try to put together a proposal for some items it add to the jsf commons fairly soon for your purusal. First off, however, I'd like some technical information on this project as it may effect how the project is set up. 1. Which version of JSF will be the minimum for this project? One of my proposals involves needing an ExternalContextWrapper and the version of JSF does make a difference. I, personally, would like to see this based off 1.2 but if we need a 1.1 Faces Commons then I would recommend both a 1.1 and a 1.2 branch. here we go; my understanding is, that 1.1 is a must 2. What is the minimum JDK we are going to use for this project. My preference would be J2SE 5 for the build. I could even live with making sure that code can be compiled with J2SE 5 in 1.4 compatibility mode but I think we need to be able to support generics at the very least. Of course if we're basing the commons project off of JSF 1.2, J2SE5 is a no-brainer. :) JSF 1.1 = java1.4 JSF 1.2 = JDK5 -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: [Vote] Oracle's donation of translations to the Apache MyFaces Trinidad project
+1 Matthias Wessendorf wrote: This is the official vote for the acceptance of Oracle's donation of translated messages ([1]) for the Apache MyFaces Trinidad component library. Please note that - since the codebase is small enough and it makes only sense in addition to the Apache MyFaces Trinidad - the intellectual property issues are handled by IP clearance [2] rather than incubation. There are no new committers, based on this donation. You can find a draft of the current IP clearance status at [1]. I'll work with Oracle's Omar Tazi to get the donation added to Oracle's CCLA (Schedule B). Please note: This vote is for the latest code drop at [1] with the following checksum. MD5: 0cd1c909689cd69bdd71b74b81f423ef After this vote, I'll run the second vote, on the [EMAIL PROTECTED] list Regards, Matthias Weßendorf [1] https://issues.apache.org/jira/browse/TRINIDAD-744 [2] http://incubator.apache.org/ip-clearance/index.html
Re: [Trinidad] hosted demos
Matthias, I believe we can setup a zone to host a running demo. Cocoon has done this [1]. Paul Spencer [1] http://cocoon.zones.apache.org/ Matthias Wessendorf wrote: These demos are hosted by the company Irian. So, there is no real process for updating those demos :-) Usually the update them after every release. But... there is a nightly build, that replaces the Trinidad-demos every night. Not sure if the infrastructure (here at Apache) will give us a Tomcat for that. -M On Nov 20, 2007 6:46 PM, Jeanne Waldman [EMAIL PROTECTED] wrote: Hi there, I see the Trinidad demos hosted here: http://www.irian.at/trinidad-demo/faces/index.jspx The revision is 1.0.2. I see we don't update this with every release, but it seems that we should. What's the process for doing this? Thanks, Jeanne
Name for MyFaces Common Project was Re: [result][vote] start up the MyFaces Commons project
I like Manfred Geiler idea around MyFaces JSF Commons. Paul Spencer Simon Lessard wrote: I can live with that as well, the name speaks for itself, but it's s loong. ~ Simon On 10/31/07, Ron Smits [EMAIL PROTECTED] wrote: I can live with that Ron On 10/31/07, Manfred Geiler [EMAIL PROTECTED] wrote: Since there where some discussions about what should be in this new project and what not: Renderkit independent components yes/no? Only static utils, convenient base classes? I have a suggestion that would solve this (and the naming as well): Let's start a new MLP* called MyFaces JSF Commons which is itself an umbrella project for two artifacts** called MyFaces JSF Commons Utils and MyFaces JSF Commons Components For the artifact names I propose: myfaces-jsfcommons-utils and myfaces-jsfcommons-components The myfaces-jsfcommons-components artifact would have a compile dependency to myfaces-jsfcommons-utils. WDYT? --Manfred * Myfaces Level Project ;-) ** We should not use the Apache Commons terminology and call those artifacts or sub projects Components for obvious reasons ;-) On 10/31/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: True! ...and also the name common is very common... :-) And therefore not reserved for Apache Commons ... -M On 10/31/07, Volker Weber [EMAIL PROTECTED] wrote: It is a apache commons like project, just not located in commons.apache.org. If it is named myfaces-jsf-commons it should clear enough this is a myfaces project. And imho it should contain tools, components, ... for jsf users like apache-commons-beanutils contains java-collection stuff for java users. Regards, Volker 2007/10/30, Ron Smits [EMAIL PROTECTED]: Grins, I so do not want to start a 'poco sensitive' discussion. But I agree with several other writers here, that commons sounds too much like the apache commons project Ron On 10/30/07, Manfred Geiler [EMAIL PROTECTED] wrote: Oh no! Not that discussion again... :-( Ron, you might not be aware of former discussions on this list - not your fault of course. Yes, there are many ASF projects which have names related to Native Americans, BUT there are also many people concerned that those names could be offensive to Native Americans. And MyFaces is - of course - not the only ASF project where such discussions took place: see [1] to get an idea about such discussions in the Geronimo community. BTW, did you know they once had Tomahawk in their list of suggest alternatives? ;-) Don't get me wrong, my personal opinion is +/-0 for names related to Native Americans Just wanted to sensitize. --Manfred [1] http://cwiki.apache.org/GMOxSBOX/why-apache-geronimo.html On 10/30/07, Ron Smits [EMAIL PROTECTED] wrote: How about Tsalagi? that is the name of the cherokee language On 10/30/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! How about a new ASF style name instead of basic, commons or something else that could be more easily misconstrued? Could you give an ASF style name for example? --- Mario -- I reject your reality and substitute my own --- Adam Savage, the mythbusters -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- I reject your reality and substitute my own --- Adam Savage, the mythbusters -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- I reject your reality and substitute my own --- Adam Savage, the mythbusters
Need summary of intent and contend to each MyFaces JSF Commons subproject was (Re: [result][vote] start up the MyFaces Commons project)
Please summarize the intent and proposed contents of each subproject on a wiki page. A common refactoring page already exists [1]. The resulting pages should be moved in each project's site documentation Paul Spencer [1] http://wiki.apache.org/myfaces/MyFaces_Commons_Refactoring Simon Lessard wrote: I can live with that as well, the name speaks for itself, but it's s loong. ~ Simon On 10/31/07, Ron Smits [EMAIL PROTECTED] wrote: I can live with that Ron On 10/31/07, Manfred Geiler [EMAIL PROTECTED] wrote: Since there where some discussions about what should be in this new project and what not: Renderkit independent components yes/no? Only static utils, convenient base classes? I have a suggestion that would solve this (and the naming as well): Let's start a new MLP* called MyFaces JSF Commons which is itself an umbrella project for two artifacts** called MyFaces JSF Commons Utils and MyFaces JSF Commons Components For the artifact names I propose: myfaces-jsfcommons-utils and myfaces-jsfcommons-components The myfaces-jsfcommons-components artifact would have a compile dependency to myfaces-jsfcommons-utils. WDYT? --Manfred * Myfaces Level Project ;-) ** We should not use the Apache Commons terminology and call those artifacts or sub projects Components for obvious reasons ;-) On 10/31/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: True! ...and also the name common is very common... :-) And therefore not reserved for Apache Commons ... -M On 10/31/07, Volker Weber [EMAIL PROTECTED] wrote: It is a apache commons like project, just not located in commons.apache.org. If it is named myfaces-jsf-commons it should clear enough this is a myfaces project. And imho it should contain tools, components, ... for jsf users like apache-commons-beanutils contains java-collection stuff for java users. Regards, Volker 2007/10/30, Ron Smits [EMAIL PROTECTED]: Grins, I so do not want to start a 'poco sensitive' discussion. But I agree with several other writers here, that commons sounds too much like the apache commons project Ron On 10/30/07, Manfred Geiler [EMAIL PROTECTED] wrote: Oh no! Not that discussion again... :-( Ron, you might not be aware of former discussions on this list - not your fault of course. Yes, there are many ASF projects which have names related to Native Americans, BUT there are also many people concerned that those names could be offensive to Native Americans. And MyFaces is - of course - not the only ASF project where such discussions took place: see [1] to get an idea about such discussions in the Geronimo community. BTW, did you know they once had Tomahawk in their list of suggest alternatives? ;-) Don't get me wrong, my personal opinion is +/-0 for names related to Native Americans Just wanted to sensitize. --Manfred [1] http://cwiki.apache.org/GMOxSBOX/why-apache-geronimo.html On 10/30/07, Ron Smits [EMAIL PROTECTED] wrote: How about Tsalagi? that is the name of the cherokee language On 10/30/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! How about a new ASF style name instead of basic, commons or something else that could be more easily misconstrued? Could you give an ASF style name for example? --- Mario -- I reject your reality and substitute my own --- Adam Savage, the mythbusters -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- I reject your reality and substitute my own --- Adam Savage, the mythbusters -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- I reject your reality and substitute my own --- Adam Savage, the mythbusters
ApacheCon US plans?
I am planing on attending ApacheCon in Atlanta this year. Is are their any MyFaces gathering planned? Paul Spencer
Need summary of intent and contend to each MyFaces JSF Commons subproject was (Re: [result][vote] start up the MyFaces Commons project)
Please summarize the intent and proposed contents of each subproject on a wiki page. A common refactoring page already exists [1]. The resulting pages should be moved in each project's site documentation Paul Spencer [1] http://wiki.apache.org/myfaces/MyFaces_Commons_Refactoring Simon Lessard wrote: I can live with that as well, the name speaks for itself, but it's s loong. ~ Simon On 10/31/07, Ron Smits [EMAIL PROTECTED] wrote: I can live with that Ron On 10/31/07, Manfred Geiler [EMAIL PROTECTED] wrote: Since there where some discussions about what should be in this new project and what not: Renderkit independent components yes/no? Only static utils, convenient base classes? I have a suggestion that would solve this (and the naming as well): Let's start a new MLP* called MyFaces JSF Commons which is itself an umbrella project for two artifacts** called MyFaces JSF Commons Utils and MyFaces JSF Commons Components For the artifact names I propose: myfaces-jsfcommons-utils and myfaces-jsfcommons-components The myfaces-jsfcommons-components artifact would have a compile dependency to myfaces-jsfcommons-utils. WDYT? --Manfred * Myfaces Level Project ;-) ** We should not use the Apache Commons terminology and call those artifacts or sub projects Components for obvious reasons ;-) On 10/31/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: True! ...and also the name common is very common... :-) And therefore not reserved for Apache Commons ... -M On 10/31/07, Volker Weber [EMAIL PROTECTED] wrote: It is a apache commons like project, just not located in commons.apache.org. If it is named myfaces-jsf-commons it should clear enough this is a myfaces project. And imho it should contain tools, components, ... for jsf users like apache-commons-beanutils contains java-collection stuff for java users. Regards, Volker 2007/10/30, Ron Smits [EMAIL PROTECTED]: Grins, I so do not want to start a 'poco sensitive' discussion. But I agree with several other writers here, that commons sounds too much like the apache commons project Ron On 10/30/07, Manfred Geiler [EMAIL PROTECTED] wrote: Oh no! Not that discussion again... :-( Ron, you might not be aware of former discussions on this list - not your fault of course. Yes, there are many ASF projects which have names related to Native Americans, BUT there are also many people concerned that those names could be offensive to Native Americans. And MyFaces is - of course - not the only ASF project where such discussions took place: see [1] to get an idea about such discussions in the Geronimo community. BTW, did you know they once had Tomahawk in their list of suggest alternatives? ;-) Don't get me wrong, my personal opinion is +/-0 for names related to Native Americans Just wanted to sensitize. --Manfred [1] http://cwiki.apache.org/GMOxSBOX/why-apache-geronimo.html On 10/30/07, Ron Smits [EMAIL PROTECTED] wrote: How about Tsalagi? that is the name of the cherokee language On 10/30/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! How about a new ASF style name instead of basic, commons or something else that could be more easily misconstrued? Could you give an ASF style name for example? --- Mario -- I reject your reality and substitute my own --- Adam Savage, the mythbusters -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- I reject your reality and substitute my own --- Adam Savage, the mythbusters -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- I reject your reality and substitute my own --- Adam Savage, the mythbusters
Re: [vote] start up the MyFaces Commons project
+1 for the commons project. Paul Spencer Mario Ivankovits wrote: Hi! 1) Will their be a JSF version specific version, i.e. commons_1.2 and commons_2.0? H I don't think so, at least for the start not. Lets start another module once we cross that bridge. 2) What are some of the module will you be moving into the project(s)? Some stuff from the shared project which is definitely stable like parts of org.apache.myfaces.shared_impl.renderkit.RendererUtils The RequestParameterProvider from tomahawk-sandbox which do not have a single component but is required in Orchestra. (Orchestra currently uses a copy of this framework) The RedirectTracker from tomahawk-sandbox. Thats all whats just popping out of my brain. Well, and in general what Mike outlined: Ie, if the validator/component/converter/other can be used with any reasonable[1] combination of JSF_RI/MyFacesCore/Tomahawk/Tobago/Trinidad/IceFaces/RichFaces/PortletBridge, then it should be available here. There is room for this project, exact details about what we take over could be discussed then. Ciao, Mario
Re: [vote] start up the MyFaces Commons project
Mario, In general agree with the need for a commons project. Before voting, I need some more information: 1) Will their be a JSF version specific version, i.e. commons_1.2 and commons_2.0? 2) What are some of the module will you be moving into the project(s)? Paul Spencer Mario Ivankovits wrote: Hi! Lets start up the long awaited MyFaces Commons project. The aim of this project will be to contain all stuff which do not belong to a component. [ ] +1 yea, lets start [ ] +0 [ ] -1 no, for those reasons . I'll do the maven work then (a not very sophisticated one, just copy it from another of our modules) Ciao, Mario
common-bridge and supported JSF versions was (Re: [vote] start up the MyFaces Commons project)
At the moment I am stuck with JSF 1.1. This is due in part to the version of Java available on some HP-UX servers. Although I would like to move to JSF 1.2, this will not occur in the near future. If this is a common situation, then I suggest JSF 1.1 AND JSF 1.2 should be current relative to MyFaces projects. Granted some project will not support JSF 1.1, but the ones that do should continue to develop in the JSF 1.1 environment. The use of a bridge to simplify development efforts for those projects that support 1.1 and 1.2 is a good idea. Paul Spencer Matthias Wessendorf wrote: On 10/24/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! 1) Will their be a JSF version specific version, i.e. commons_1.2 and commons_2.0? H I don't think so, at least for the start not. Lets start another module once we cross that bridge. I think, this is a valid question. The current version of JSF is 1.2. The old version is 1.1 But for some reasons that is the one, that the most people use. I think, that such a common-bridge should at least support current development and optionally support the old one. The bad news is, that almost nobody here uses JSF 1.2 :-) So reasonable to understand that this bridge starts with JSF 1.1 What do others think... 2) What are some of the module will you be moving into the project(s)? Some stuff from the shared project which is definitely stable like parts of org.apache.myfaces.shared_impl.renderkit.RendererUtils The RequestParameterProvider from tomahawk-sandbox which do not have a single component but is required in Orchestra. (Orchestra currently uses a copy of this framework) The RedirectTracker from tomahawk-sandbox. Thats all whats just popping out of my brain. Well, and in general what Mike outlined: Ie, if the validator/component/converter/other can be used with any reasonable[1] combination of JSF_RI/MyFacesCore/Tomahawk/Tobago/Trinidad/IceFaces/RichFaces/PortletBridge, then it should be available here. There is room for this project, exact details about what we take over could be discussed then. Ciao, Mario
Re: [VOTE] MyFaces 1.2.x become trunk
Manfred, +1 for the following! /branches /branches/1_1_6 /branches/1_2_1 /tags /tags/1_1_2 /tags/1_1_3 /tags/1_1_4 /tags/1_1_5 /tags/1_2_0 /tags/1_2_1 /1_1_x --- the trunk for JSF 1.1 development /1_2_x --- the trunk for JSF 1.2 development Are their any changes to the SCM tag in the POMs? Paul Spencer Manfred Geiler wrote: BTW, thanks Matthias for the successful 1.2 release. Good to know that someone keeps the business running while oneself is lying in the sun beeing on vacation... ;-) Regarding the repo structure. We had some discussions before. One proposal was the follwing structure. And AFAIR there where no objections. I just copy and paste parts of this thread: Just had a look at the tomcat repo and I like the structure they use. Main issue is that they do not name their trunk folder trunk but rather give it a name corresponding to the actual major/minor version (eg tc5.5.x). I like this idea. And what is more: moving the current trunk to branches sounds weird to me. The 1.1.x is no branch and never will be a real branch of 1.2.x. So, why force it into the branches folder? MyFaces 1.1.x and MyFaces 1.2.x have more the nature of two separate development trunks because they implement different specs. The Tomcat guys address such issues in the way I just described. So, why not learn from them? So, if we follow that path consistently our (sub)projects will each have the following structure: /branches /branches/1_1_6 /branches/1_2_1 /tags /tags/1_1_2 /tags/1_1_3 /tags/1_1_4 /tags/1_1_5 /tags/1_2_0 /tags/1_2_1 /1_1_x --- the trunk for JSF 1.1 development /1_2_x --- the trunk for JSF 1.2 development The great advantage: We can do this step by step without breaking anything. All we need to do is point the externals in the current project to the right trunk folder. We even can do the restructuring first and point the externals to the corresponding 1_1_x trunks and in a second step switch current to the 1_2_x trunks without a need to restructure again. WDYT? --Manfred On 7/20/07, Paul Spencer [EMAIL PROTECTED] wrote: I do not like the idea of current (symlink to jsf1.2). To me JSF 1.1 and 1.2 are two products and should be treated as such. Paul Spencer Andrew Robinson wrote: Not to be too anal, but would: current (symlink to jsf1.2) jsf1.1 jsf1.2 Be a little more tidy? It should also consider the web site right? Right now, it only shows the current/trunk branch. Perhaps the site should be versioned as well. Example using tomahawk: myfaces.apache.org/tomahawk/current (symlink to 1.2) myfaces.apache.org/tomahawk/1.2 myfaces.apache.org/tomahawk/1.1 On 7/20/07, Cagatay Civici [EMAIL PROTECTED] wrote: Why not: how many users are ready to make the jump to JSF 1.2? Many of our users, Tomahawk, Trinidad, Tobago, are on JSP 2.0 or earlier. Yeah, but we're just making 1.2 the trunk, not forcing people to use 1.2. Again two active branches current11 and current12 sounds good to me, where current12 has the trunks Cagatay On 7/20/07, Matt Cooper [EMAIL PROTECTED] wrote: +1 (non-binding) On 7/20/07, Adam Winer [EMAIL PROTECTED] wrote: Why not: how many users are ready to make the jump to JSF 1.2? Many of our users, Tomahawk, Trinidad, Tobago, are on JSP 2.0 or earlier. It'd make my life way easier if the Trinidad trunk were 1.2, definitely, I just doubt that would hold true for the users. Just for starters, what about the committers? How many of us can stick to 1.2? -- Adam On 7/20/07, Cagatay Civici [EMAIL PROTECTED] wrote: About subprojects, I think the case is same for them, if we make 1.2 the trunk for api, why not set 1.2 branches of subprojects as trunks too? Also after doing it, we may need to reconfigure current and current12 too. On 7/19/07, Paul Spencer [EMAIL PROTECTED] wrote: Assuming MyFaces 1.1.7 is released so the SVN configuration in the POM of next version of MyFaces will be correct. Otherwise people, including Continuum, who are using 1.1.7-SNAPSHOT from the repository will be in for a very big surprise. Qualified +1 otherwise -0 for the above reason Although I missed the discussion, my preference would be for a MyFaces 1.1 and 1.2 trunk/branch since both are active products. Paul Spencer Matthias Wessendorf wrote: Hi, this is a vote for making the JSF 1.2 efforts by our group to become the current trunk. Currently the JSF 1.2-work lives on a branch ( 1.2.1-SNAPSHOT is the current version). Please cast your vote [ ] +1 for moving the myfaces 1.2.x to trunk [ ] +0 [ ] -1 and why.. -M
Re: [VOTE] MyFaces 1.2.x become trunk
I do not like the idea of current (symlink to jsf1.2). To me JSF 1.1 and 1.2 are two products and should be treated as such. Paul Spencer Andrew Robinson wrote: Not to be too anal, but would: current (symlink to jsf1.2) jsf1.1 jsf1.2 Be a little more tidy? It should also consider the web site right? Right now, it only shows the current/trunk branch. Perhaps the site should be versioned as well. Example using tomahawk: myfaces.apache.org/tomahawk/current (symlink to 1.2) myfaces.apache.org/tomahawk/1.2 myfaces.apache.org/tomahawk/1.1 On 7/20/07, Cagatay Civici [EMAIL PROTECTED] wrote: Why not: how many users are ready to make the jump to JSF 1.2? Many of our users, Tomahawk, Trinidad, Tobago, are on JSP 2.0 or earlier. Yeah, but we're just making 1.2 the trunk, not forcing people to use 1.2. Again two active branches current11 and current12 sounds good to me, where current12 has the trunks Cagatay On 7/20/07, Matt Cooper [EMAIL PROTECTED] wrote: +1 (non-binding) On 7/20/07, Adam Winer [EMAIL PROTECTED] wrote: Why not: how many users are ready to make the jump to JSF 1.2? Many of our users, Tomahawk, Trinidad, Tobago, are on JSP 2.0 or earlier. It'd make my life way easier if the Trinidad trunk were 1.2, definitely, I just doubt that would hold true for the users. Just for starters, what about the committers? How many of us can stick to 1.2? -- Adam On 7/20/07, Cagatay Civici [EMAIL PROTECTED] wrote: About subprojects, I think the case is same for them, if we make 1.2 the trunk for api, why not set 1.2 branches of subprojects as trunks too? Also after doing it, we may need to reconfigure current and current12 too. On 7/19/07, Paul Spencer [EMAIL PROTECTED] wrote: Assuming MyFaces 1.1.7 is released so the SVN configuration in the POM of next version of MyFaces will be correct. Otherwise people, including Continuum, who are using 1.1.7-SNAPSHOT from the repository will be in for a very big surprise. Qualified +1 otherwise -0 for the above reason Although I missed the discussion, my preference would be for a MyFaces 1.1 and 1.2 trunk/branch since both are active products. Paul Spencer Matthias Wessendorf wrote: Hi, this is a vote for making the JSF 1.2 efforts by our group to become the current trunk. Currently the JSF 1.2-work lives on a branch ( 1.2.1-SNAPSHOT is the current version). Please cast your vote [ ] +1 for moving the myfaces 1.2.x to trunk [ ] +0 [ ] -1 and why.. -M
Re: [VOTE] MyFaces 1.2.x become trunk
I do not like the idea of current (symlink to jsf1.2). To me JSF 1.1 and 1.2 are two products and should be treated as such. Paul Spencer Andrew Robinson wrote: Not to be too anal, but would: current (symlink to jsf1.2) jsf1.1 jsf1.2 Be a little more tidy? It should also consider the web site right? Right now, it only shows the current/trunk branch. Perhaps the site should be versioned as well. Example using tomahawk: myfaces.apache.org/tomahawk/current (symlink to 1.2) myfaces.apache.org/tomahawk/1.2 myfaces.apache.org/tomahawk/1.1 On 7/20/07, Cagatay Civici [EMAIL PROTECTED] wrote: Why not: how many users are ready to make the jump to JSF 1.2? Many of our users, Tomahawk, Trinidad, Tobago, are on JSP 2.0 or earlier. Yeah, but we're just making 1.2 the trunk, not forcing people to use 1.2. Again two active branches current11 and current12 sounds good to me, where current12 has the trunks Cagatay On 7/20/07, Matt Cooper [EMAIL PROTECTED] wrote: +1 (non-binding) On 7/20/07, Adam Winer [EMAIL PROTECTED] wrote: Why not: how many users are ready to make the jump to JSF 1.2? Many of our users, Tomahawk, Trinidad, Tobago, are on JSP 2.0 or earlier. It'd make my life way easier if the Trinidad trunk were 1.2, definitely, I just doubt that would hold true for the users. Just for starters, what about the committers? How many of us can stick to 1.2? -- Adam On 7/20/07, Cagatay Civici [EMAIL PROTECTED] wrote: About subprojects, I think the case is same for them, if we make 1.2 the trunk for api, why not set 1.2 branches of subprojects as trunks too? Also after doing it, we may need to reconfigure current and current12 too. On 7/19/07, Paul Spencer [EMAIL PROTECTED] wrote: Assuming MyFaces 1.1.7 is released so the SVN configuration in the POM of next version of MyFaces will be correct. Otherwise people, including Continuum, who are using 1.1.7-SNAPSHOT from the repository will be in for a very big surprise. Qualified +1 otherwise -0 for the above reason Although I missed the discussion, my preference would be for a MyFaces 1.1 and 1.2 trunk/branch since both are active products. Paul Spencer Matthias Wessendorf wrote: Hi, this is a vote for making the JSF 1.2 efforts by our group to become the current trunk. Currently the JSF 1.2-work lives on a branch ( 1.2.1-SNAPSHOT is the current version). Please cast your vote [ ] +1 for moving the myfaces 1.2.x to trunk [ ] +0 [ ] -1 and why.. -M
Re: [VOTE] MyFaces 1.2.x become trunk
At this point all of my project are based on JSF 1.1, primarily because the infrastructure to support JSF 1.2 is not available on the deployment platforms. Paul Spencer Adam Winer wrote: Why not: how many users are ready to make the jump to JSF 1.2? Many of our users, Tomahawk, Trinidad, Tobago, are on JSP 2.0 or earlier. It'd make my life way easier if the Trinidad trunk were 1.2, definitely, I just doubt that would hold true for the users. Just for starters, what about the committers? How many of us can stick to 1.2? -- Adam On 7/20/07, Cagatay Civici [EMAIL PROTECTED] wrote: About subprojects, I think the case is same for them, if we make 1.2 the trunk for api, why not set 1.2 branches of subprojects as trunks too? Also after doing it, we may need to reconfigure current and current12 too. On 7/19/07, Paul Spencer [EMAIL PROTECTED] wrote: Assuming MyFaces 1.1.7 is released so the SVN configuration in the POM of next version of MyFaces will be correct. Otherwise people, including Continuum, who are using 1.1.7-SNAPSHOT from the repository will be in for a very big surprise. Qualified +1 otherwise -0 for the above reason Although I missed the discussion, my preference would be for a MyFaces 1.1 and 1.2 trunk/branch since both are active products. Paul Spencer Matthias Wessendorf wrote: Hi, this is a vote for making the JSF 1.2 efforts by our group to become the current trunk. Currently the JSF 1.2-work lives on a branch ( 1.2.1-SNAPSHOT is the current version). Please cast your vote [ ] +1 for moving the myfaces 1.2.x to trunk [ ] +0 [ ] -1 and why.. -M
Re: [COMMUNITY] Andrew Robinson - Committer
Welcome aboard Andrew. Paul Spencer Grant Smith wrote: The Myfaces PMC is proud to announce a new addition to our community. Please welcome Andrew Robinson as the newest MyFaces committer. Andrew has been exceedingly helpful in both the users and dev lists and is a great value to this project ! Thanks Andrew!
Re: [COMMUNITY] Peter Mahoney - Committer
Welcome aboard Peter. Paul Spencer Grant Smith wrote: The Myfaces PMC is proud to announce a new addition to our community. Please welcome Peter Mahoney as the newest MyFaces committer. Peter has been exceedingly helpful in providing patches in JIRA and is a great value to this project ! Thanks Peter!
[jira] Created: (TOMAHAWK-1022) HtmlMessage and HtmlMessages fails unit test when using RI
HtmlMessage and HtmlMessages fails unit test when using RI -- Key: TOMAHAWK-1022 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1022 Project: MyFaces Tomahawk Issue Type: Bug Components: Message(s) Reporter: Paul Spencer Fix For: 1.1.6 Below are output from the test failures. The test are run using the following command: cd tomahawk/core mvn test -Djsf=ri --- Test set: org.apache.myfaces.component.html.ext.HtmlMessagesTest --- Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.094 sec FAILURE! testDefaultRenderer(org.apache.myfaces.component.html.ext.HtmlMessagesTest) Time elapsed: 0.032 sec ERROR! java.lang.IllegalStateException: Parent was not null, but this component not related at javax.faces.component.UIComponentBase.eraseParent(UIComponentBase.java:457) at javax.faces.component.UIComponentBase.access$500(UIComponentBase.java:76) at javax.faces.component.UIComponentBase$ChildrenList.add(UIComponentBase.java:1496) at org.apache.myfaces.component.html.ext.HtmlMessagesTest.testDefaultRenderer(HtmlMessagesTest.java:66) --- Test set: org.apache.myfaces.component.html.ext.HtmlMessageTest --- Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.031 sec FAILURE! testDefaultRenderer(org.apache.myfaces.component.html.ext.HtmlMessageTest) Time elapsed: 0 sec ERROR! java.lang.IllegalStateException: Parent was not null, but this component not related at javax.faces.component.UIComponentBase.eraseParent(UIComponentBase.java:457) at javax.faces.component.UIComponentBase.access$500(UIComponentBase.java:76) at javax.faces.component.UIComponentBase$ChildrenList.add(UIComponentBase.java:1496) at org.apache.myfaces.component.html.ext.HtmlMessageTest.testDefaultRenderer(HtmlMessageTest.java:66) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOMAHAWK-1023) HtmlInputHidden fails unit test when using RI
HtmlInputHidden fails unit test when using RI - Key: TOMAHAWK-1023 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1023 Project: MyFaces Tomahawk Issue Type: Bug Reporter: Paul Spencer Fix For: 1.1.6 --- Test set: org.apache.myfaces.component.html.ext.HtmlInputHiddenTest Below are output from the test failures. The test are run using the following command: cd tomahawk/core mvn test -Djsf=ri --- Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.016 sec FAILURE! testDefaultRenderer(org.apache.myfaces.component.html.ext.HtmlInputHiddenTest) Time elapsed: 0.016 sec FAILURE! junit.framework.AssertionFailedError: ID is not null at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.assertTrue(Assert.java:20) at junit.framework.Assert.assertNotNull(Assert.java:220) at org.apache.myfaces.test.AbstractTomahawkViewControllerTestCase.assertIdExists(AbstractTomahawkViewControllerTestCase.java:88) at org.apache.myfaces.component.html.ext.HtmlInputHiddenTest.testDefaultRenderer(HtmlInputHiddenTest.java:64) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Continuum server down?
The Continuum server [1] is not responding. Is it down? Paul Spencer [1] http://myfaces.zones.apache.org:8081/continuum
[jira] Commented: (TOMAHAWK-998) Upgrade testing to allow for testing against other JSF implementations
[ https://issues.apache.org/jira/browse/TOMAHAWK-998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12503839 ] Paul Spencer commented on TOMAHAWK-998: --- This task is currently blocked by TOMAHAWK-1022 and TOMAHAWK-1023. Once those issues are resolved, then the attribute -Djsf=ri need to be added to the build definition of Tomahawk Core in continuum. Upgrade testing to allow for testing against other JSF implementations -- Key: TOMAHAWK-998 URL: https://issues.apache.org/jira/browse/TOMAHAWK-998 Project: MyFaces Tomahawk Issue Type: Improvement Reporter: Paul Spencer Assignee: Paul Spencer Tomahawk's automated testing should support other JSF implementations. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
TabbedPane does not validate non-selected tabs in server side tab switching mode (Relaed to TOMAHAWK-1012)
I use server side switching. Validation of non-selected tab would break many pages in my applications. As an example, one of the applications allows the user to query a database. Each tab is a specific type of query with it's own requirement, i.e. Start Time and End Time fields are required on the Query by Time and SKU is required on the Query by SKU tab. Forcing non-selected tab to pass validation would break this part of the application since many cases the required fields have no default value by design. I can see a case where validation of non-selected tabs is need. As an example, a series of tab that collect customer information where each tab is a type of information, Name Billing Address Shipping Address Whether this should be implement as a validateNonSelectedTab attribute on t:panelTabbedPane and/or t:panelTab is it's own discussion. Paul Spencer
[jira] Commented: (TOMAHAWK-1012) TabbedPane does not validate non-selected tabs in server side tab switching mode
[ https://issues.apache.org/jira/browse/TOMAHAWK-1012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12503421 ] Paul Spencer commented on TOMAHAWK-1012: I have add a thread to the dev list titled TabbedPane does not validate non-selected tabs in server side tab switching mode (Relaed to TOMAHAWK-1012) Paul Spencer TabbedPane does not validate non-selected tabs in server side tab switching mode Key: TOMAHAWK-1012 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1012 Project: MyFaces Tomahawk Issue Type: Bug Components: Tabbed Pane Affects Versions: 1.1.5, 1.1.6-SNAPSHOT Reporter: David Delbecq Attachments: tabbedPaneValidator.diff When your form spreads accross a tabbed pane, the validators of components residing inside not selected tab are not validated. This is a problem because all form need to be validated before writting values to backing beans. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: TabbedPane does not validate non-selected tabs in server side tab switching mode (Relaed to TOMAHAWK-1012)
Mike,
In my query example, each tab contains a form, see below. Is this what
you are talking about?
t:documentBody
t:panelTabbedPane
t:panelTab label=Query by Date
f:form
...
h:inputText value=#{startTime} required=true/
...
/f:form
/t:panelTab
t:panelTab label=Query by SKU
f:form
...
h:inputText value=#{sku} required=true/
...
/f:form
/t:panelTab
/t:panelTabbedPane
/t:documentBody
Paul Spencer
Mike Kienenberger wrote:
I think someone else already pointed this out, but from an ideal
design point of view, the tabbed panes are for organizing information
visually, not for supporting partial validation.
To me, the ideal design would be to have all tabbed panes validated,
just like for any other visual element, and then, if you needed
partial validation, make use of the subForm tag by enclosing each
tabbed pane.
On 6/11/07, Paul Spencer [EMAIL PROTECTED] wrote:
I use server side switching. Validation of non-selected tab would break
many pages in my applications. As an example, one of the applications
allows the user to query a database. Each tab is a specific type of
query with it's own requirement, i.e. Start Time and End Time fields
are required on the Query by Time and SKU is required on the Query
by SKU tab. Forcing non-selected tab to pass validation would break
this part of the application since many cases the required fields have
no default value by design.
I can see a case where validation of non-selected tabs is need. As an
example, a series of tab that collect customer information where each
tab is a type of information, Name Billing Address Shipping
Address Whether this should be implement as a
validateNonSelectedTab attribute on t:panelTabbedPane and/or
t:panelTab is it's own discussion.
Paul Spencer
Status of Tomahawk testing with RI using Continuum
Status of Tomahawk testing with RI using Continuum. I am in the process of adding Build Definitions in Continuum that will test Tomahawk and the Tomahawk sandbox against the 1.1 RI. This is done by adding the argument -Djsf=ri to the definition. *** * Completed *** 1) Filed issued related to 1.1 RI testing with Tomahawk http://issues.apache.org/jira/browse/TOMAHAWK-998 2) Adding the 1.1 RI configuration to the Tomahawk project POM 3) Added a build definition to Tomahawk Sandbox using the 1.1 RI 4) Filed Continuum issues related to the lack of Build Definition information in the Continuum results. This is important because it may be hard, if not impossible, to determine which JSF implementation was used during a build. http://jira.codehaus.org/browse/CONTINUUM-1278 http://jira.codehaus.org/browse/CONTINUUM-1279 *** * To Do: *** 1) File issues for failures exposed by the following test when using the 1.1 RI. testDefaultRenderer(org.apache.myfaces.component.html.ext.HtmlInputHiddenTest) testDefaultRenderer(org.apache.myfaces.component.html.ext.HtmlMessageTest) testDefaultRenderer(org.apache.myfaces.component.html.ext.HtmlMessagesTest) Note: The test can be run locally by adding -Djsf=ri to the mvn command 2) Added a build definition to Tomahawk Core using the 1.1 RI *** * Should we: *** 1) Added a build definition to Tomahawk Core and SandBox using the 1.2 RI? 2) Added a build definition to Tomahawk Core using the MyFaces 1.2/2.0? 2) Added a build definition to Sandbox15 using the 1.2 RI? 4) Add testing with the 1.1 and/or 1.2 RI on other subprojects, i.e. Tobago? Paul Spencer
Re: Possible bug in the columns tag with the convertDateTime tag
Johnny,
The following work for me using MyFaces 1.1.5:
***
* From JSP
***
t:column id=dateColumn
headerstyleClass=dataTableColumnHeader
styleClass=dataColumn_String
rendered=#{manager.summarizeByDay}
f:facet name=header
h:outputLabel for=date value=Date /
/f:facet
h:outputText id=date value=#{row.date}
f:convertDateTime pattern=dd-MMM-
timeZone=#{applicationDefaults.timeZone} /
/h:outputText
/t:column
***
* From applicationDefault bean
***
public TimeZone getTimeZone()
{
return timeZone;
}
Paul Spencer
Johnny Sutherland wrote:
Hi Mike
Thank you for replying so quickly.
I have tried both the TimeZone type and String for the timeZone parameter.
The pattern has always been String.
Johnny
Mike Kienenberger wrote:
What's the data type of #{columnInfo.timeZone}? Both getters should
be of type String.
The docs read:
Time zone in which to interpret any time information in the date
String. Value must be either a VB expression that evaluates to a
java.util.TimeVone instance, or a String that is a timezone ID as
described in the javadocs for java.util.TimeZone.getTimeZone().
On 6/1/07, Johnny Sutherland wrote:
You are correct. That was a typing error from me when writing the bug. I
have entered the correct code below - unfortuntale the problem is still
the
same. We havce also discovered that the problem - the getter is not
called -
exists with all the tags from the JSF Core taglib.
The timeZone and pattern values are not being read from the columnInfo
object when the tag is within a columns tag in a dataTable.
The columnInfo is set by the columns tag but the getter is not called.
However, if we access the values via an outputText tag e.g. (These values
are displayed) (These values are displayed) the getters are accessed and
the
values displayed.
value=#{masterDataController.sortableList.dataModel}
sortColumn=#{masterDataController.sortableList.sort}
sortAscending=#{masterDataController.sortableList.ascending}
preserveSort=false renderedIfEmpty=false
value=#{masterDataController.sortableList.columnInfos}
pattern=#{columnInfo.pattern} / (These values are not accessed)
(These values will be
displayed)
(These values will be
displayed)
Mike Kienenberger wrote:
What you posted isn't valid: You have: -- should be '' not '/' I
could
see how that might cause this tag to be ignored, provided it was parsed
at
all. On 5/31/07, Johnny Sutherland wrote: The timeZone and pattern
values
are not being read from the columnInfo object when the tag is within a
columns tag in a dataTable. The columnInfo is set by the columns tag
but
the getter is not called. However, if we access the values via an
outputText tag e.g. (These values are displayed) (These values are
displayed) the getters are accessed and the values displayed.
Here
is a sample of the code.
headerClass=standardTableHeader
footerClass=standardText rowClasses=standardTable_Row1,
standardTable_Row2 var=data preserveDataModel=false
value=#{masterDataController.sortableList.dataModel}
rows=10
sortColumn=#{masterDataController.sortableList.sort}
sortAscending=#{masterDataController.sortableList.ascending}
preserveSort=false renderedIfEmpty=false
value=#{masterDataController.sortableList.columnInfos}
styleClass=#{masterDataController.sortableList.columnStyleClass}
styleClass=tableHeader immediate=false
action=#{masterDataController.sortableList.sort}
value=#{masterDataController.sortableList.columnValue}
rendered=#{!masterDataController.sortableList.dataModel.selected}
/ pattern=#{columnInfo.pattern} / (These values are not
accessed)
(These values will be displayed) (These values will be
displayed) View
this message in context: Possible bug in the columns tag with the
convertDateTime tag Sent from the My Faces - Dev mailing list archive
at
Nabble.com.
View this message in context: Re: Possible bug in the columns tag with
the
convertDateTime tag
Sent from the My Faces - Dev mailing list archive at Nabble.com.
Re: JavaOne 2007 Slides
Nice to put picture with names. What was the Surprise Announcement ? Paul Spencer Manfred Geiler wrote: Hi all, Some requested them, here they are: The slides of our presentation at the last JavaOne about the MyFaces community. The Faces of MyFaces http://people.apache.org/~manolito/javaone07/BOF-7405.ppt Have fun! Manfred
Re: Continuum server down?
Wendy, Not much I can do. No karma, although I have not asked for it. Paul Spencer Wendy Smoak wrote: On 5/31/07, Paul Spencer [EMAIL PROTECTED] wrote: The Continuum server is not responding. Is it down? Looks like the JVM was hung again. Last time it was an odd Jetty OOME that I haven't had time to track down. Probably needs some settings adjusted. I restarted it using the scripts in ~mrmaven on the zone. There's a Continuum page on the wiki, if you do anything interesting, leave a note there.
Continuum server down?
The Continuum server is not responding. Is it down? Paul Spencer
Checksum error on JSF RI artifacts on continuum server.
I am trying to add a build of Tomahawk against the RI, but there are Checksum errors on JSF RI artifacts on continuum server see[1]. What is the best way to resolve this? I believe the goal dependency:purge-local-repository will remove the artifacts, but it seems extreme since it will remove ALL dependencies. Paul Spencer http://www.mail-archive.com/dev@myfaces.apache.org/msg22700.html
Re: Checksum error on JSF RI artifacts on continuum server.
Wendy, When I build Tomahawk locally, I do not see the errors. In addition I do not have javax.servlet.jsp:jsp-api:jar:1.2.0 in my local repository. I am wondering if the RI artifacts are corrupt/outdated for some strange reason. Based on the following, it appears the artifacts should not be used. Thus leading be to believe the RI artifacts on the continuum server are bad. mvn help:effective-pom displays the following. dependency groupIdjavax.faces/groupId artifactIdjsf-impl/artifactId version1.1_02/version scopetest/scope exclusions exclusion artifactIdjsp-api/artifactId groupIdjava.servlet.servlet.jsp/groupId /exclusion exclusion artifactIdservlet-api/artifactId groupIdjavax.servlet/groupId /exclusion exclusion artifactIdjsp-api/artifactId groupIdjavax.servlet.jsp/groupId /exclusion exclusion artifactIdjstl/artifactId groupIdjavax.servlet.jsp.jstl/groupId /exclusion /exclusions /dependency Paul Spencer Wendy Smoak wrote: On 5/31/07, Paul Spencer [EMAIL PROTECTED] wrote: I am trying to add a build of Tomahawk against the RI, but there are Checksum errors on JSF RI artifacts on continuum server see[1]. What is the best way to resolve this? I believe the goal dependency:purge-local-repository will remove the artifacts, but it seems extreme since it will remove ALL dependencies. It looks to me like the build failure is due to a missing dependency, not bad checksums. Those are just warnings and are ignored. Or are you saying that javax.servlet.jsp:jsp-api:jar:1.2.0 is available in a public repo and Maven is refusing to download it?
Re: Checksum error on JSF RI artifacts on continuum server.
Wendy, I found the problem. The missing dependency was defined in the tomahawk-project pom. I remove it. Paul Spencer Wendy Smoak wrote: On 5/31/07, Paul Spencer [EMAIL PROTECTED] wrote: When I build Tomahawk locally, I do not see the errors. In addition I do not have javax.servlet.jsp:jsp-api:jar:1.2.0 in my local repository. I am wondering if the RI artifacts are corrupt/outdated for some strange reason. Based on the following, it appears the artifacts should not be used. Thus leading be to believe the RI artifacts on the continuum server are bad. What do you want me to do? If you want something deleted from mrmaven's local repo, give the groupId/artifactId.
Re: Checksum error on JSF RI artifacts on continuum server.
Wendy, Right now, nothing. I think I may have found the problem. The checksum problem has gone away, meaning the the warning no longer exists and I do not know why. I am working on the missing dependency problem now. Paul Spencer Wendy Smoak wrote: On 5/31/07, Paul Spencer [EMAIL PROTECTED] wrote: When I build Tomahawk locally, I do not see the errors. In addition I do not have javax.servlet.jsp:jsp-api:jar:1.2.0 in my local repository. I am wondering if the RI artifacts are corrupt/outdated for some strange reason. Based on the following, it appears the artifacts should not be used. Thus leading be to believe the RI artifacts on the continuum server are bad. What do you want me to do? If you want something deleted from mrmaven's local repo, give the groupId/artifactId.
Re: [PROPOSAL] MyFaces JSR-252 Version Number (was MyFaces 2.0.0)
Manfred, Thank you for this! Below are a couple questions. Manfred Geiler wrote: Hi all, snip Ok, here is my compromise proposal, which I hope everyone can live with: C1. We switch MyFaces Core to a 4 digit version numbering: 1.2.0.0 which means major-spec-version.minor-spec-version.minor-impl-version.fix-version Is this supported by Maven? snip C3. Non-core libs will no longer be aligned to Core. Which means that Tomahawk/Trinidad/Tobago will always have the freedom to jump to 1.5.0 or 2.0.0 or any appropriate number whenever there are major feature additions or global refactorings. 1) Although it is inferred, should the version number be in the form? major-spec-version.minor-spec-version.fix-version ([ -qualifier ] | [ -build ]) 2) Should this proposal include the next version number for the mention projects? snip Somebody mentioned that this issue is the most controversial since a while. Well, I hope this proposal is a good compromise and we/I can start the release procedure next week. Regards, Manfred In short I support the compromise. Again, Thank you. Paul Spencer
