Re: [html5] alpha release for myfaces html5
On Wed, Nov 2, 2011 at 11:29 PM, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi matthias, perfect for new GSoC projects, IMO agreed - if the student is a committer (see [1]). however, we would have the same issue afterwards. with codi we started with a community check before adding btw. releasing a new sub-project and imo we have to continue with this approach. not everybody is happy w/ current Labs state (especially as others see Labs as a good area fo GSoC) -M regards, gerhard [1] http://labs.apache.org/bylaws.html http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/11/2 Matthias Wessendorf mat...@apache.org: On Wed, Nov 2, 2011 at 9:13 PM, Gerhard Petracek gerhard.petra...@gmail.com wrote: @matthias: apache labs are only for prototyping and the next step is e.g. the incubator for building a community (see [1]). perfect for new GSoC projects, IMO However, generally Apache Labs is (unfortunately) pretty limited (not sure I why would actually do stuff there (instead of at github etc)) -M regards, gerhard [1] http://labs.apache.org/bylaws.html http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/11/2 Matthias Wessendorf mat...@apache.org: that's stupid :-) Personal releases are IMO possible (e.g. deployment to p.a.o/~asf-id) -M On Wed, Nov 2, 2011 at 6:35 PM, Ali Ok al...@aliok.com.tr wrote: One important point is labs projects are not allowed to make releases. Sent from Android On Nov 2, 2011 1:22 PM, Gerhard Petracek gerhard.petra...@gmail.com wrote: see [1] - esp.: Apache Labs are the place where ASF committers can work on innovative, blue-sky and off-the-wall ideas, without having to worry about fitting in an existing project bylaw or building a community around it... we already know that it works and it's just about a community check - imo labs doesn't fit and the alternative would be the incubator itself. regards, gerhard [1] http://labs.apache.org/bylaws.html http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/11/2 Matthias Wessendorf mat...@apache.org: I don't get why not just having a simple alpha release ? Does not hurt... Or... move the entire thing to Apache Labs... for future experiments ?! -M On Tue, Nov 1, 2011 at 12:03 AM, Ali Ok al...@aliok.com.tr wrote: Hi, So do you think myfaces/incubator/html5 is a good place? Greetings, Ali On Sat, Oct 22, 2011 at 1:37 PM, Ali Ok al...@aliok.com.tr wrote: Hi, In my opinion as long this lib is html5 only it should not be part of the tomahawk project I agree, no relation with Tomahawk. a different idea would be a small myfaces-incubator for new project-ideas (esp. for gsoc projects). Makes more sense to me than Tomahawk. I think (almost) everyone is in favor of moving the project to somewhere else, I am also ok with it. Important thing for the project is having the ability for releases and the jars are deployed to maven repo. Cheers, Ali On Sat, Oct 22, 2011 at 11:05 AM, Mark Struberg strub...@yahoo.de wrote: including our very own little 'attic' :) Actually the big difference between the incubator and a mf subproject would be the IP clearance. We really need to do this upfront before importing. But actually I like this much more than having projects developed outside and only later brought into our SVN - because this causes lots of paperwork (gas grants and a IP clearance review is mandatory). Thus a +1 LieGrue, strub From: Gerhard Petracek gerhard.petra...@gmail.com To: MyFaces Development dev@myfaces.apache.org Sent: Saturday, October 22, 2011 10:58 AM Subject: Re: [html5] alpha release for myfaces html5 a different idea would be a small myfaces-incubator for new project-ideas (esp. for gsoc projects). we can release parts easily and drop them if we see that something doesn't work for our community. if an idea works for the community, we can discuss the correct place for it. we might see new gsoc projects (related to myfaces) every year. imo it's the wrong approach to just add them as new sub-project and we don't have the resources/community to maintain them. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/10/22 Bernd Bohmann bernd.bohm...@atanion.com Ha, I don't think we should wait for the jsf-eg. Hey guys they are asking for a alpha release. In my opinion as long this lib
Re: [html5] alpha release for myfaces html5
On Thu, Nov 3, 2011 at 7:44 AM, Matthias Wessendorf mat...@apache.org wrote: On Wed, Nov 2, 2011 at 11:29 PM, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi matthias, perfect for new GSoC projects, IMO agreed - if the student is a committer (see [1]). however, we would have the same issue afterwards. with codi we started with a community check before adding btw. releasing a new sub-project and imo we have to continue with this approach. not everybody is happy w/ current Labs state (especially as others see Labs as a good area fo GSoC) but also - not sure if changes are coming (soon) :-) -M regards, gerhard [1] http://labs.apache.org/bylaws.html http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/11/2 Matthias Wessendorf mat...@apache.org: On Wed, Nov 2, 2011 at 9:13 PM, Gerhard Petracek gerhard.petra...@gmail.com wrote: @matthias: apache labs are only for prototyping and the next step is e.g. the incubator for building a community (see [1]). perfect for new GSoC projects, IMO However, generally Apache Labs is (unfortunately) pretty limited (not sure I why would actually do stuff there (instead of at github etc)) -M regards, gerhard [1] http://labs.apache.org/bylaws.html http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/11/2 Matthias Wessendorf mat...@apache.org: that's stupid :-) Personal releases are IMO possible (e.g. deployment to p.a.o/~asf-id) -M On Wed, Nov 2, 2011 at 6:35 PM, Ali Ok al...@aliok.com.tr wrote: One important point is labs projects are not allowed to make releases. Sent from Android On Nov 2, 2011 1:22 PM, Gerhard Petracek gerhard.petra...@gmail.com wrote: see [1] - esp.: Apache Labs are the place where ASF committers can work on innovative, blue-sky and off-the-wall ideas, without having to worry about fitting in an existing project bylaw or building a community around it... we already know that it works and it's just about a community check - imo labs doesn't fit and the alternative would be the incubator itself. regards, gerhard [1] http://labs.apache.org/bylaws.html http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/11/2 Matthias Wessendorf mat...@apache.org: I don't get why not just having a simple alpha release ? Does not hurt... Or... move the entire thing to Apache Labs... for future experiments ?! -M On Tue, Nov 1, 2011 at 12:03 AM, Ali Ok al...@aliok.com.tr wrote: Hi, So do you think myfaces/incubator/html5 is a good place? Greetings, Ali On Sat, Oct 22, 2011 at 1:37 PM, Ali Ok al...@aliok.com.tr wrote: Hi, In my opinion as long this lib is html5 only it should not be part of the tomahawk project I agree, no relation with Tomahawk. a different idea would be a small myfaces-incubator for new project-ideas (esp. for gsoc projects). Makes more sense to me than Tomahawk. I think (almost) everyone is in favor of moving the project to somewhere else, I am also ok with it. Important thing for the project is having the ability for releases and the jars are deployed to maven repo. Cheers, Ali On Sat, Oct 22, 2011 at 11:05 AM, Mark Struberg strub...@yahoo.de wrote: including our very own little 'attic' :) Actually the big difference between the incubator and a mf subproject would be the IP clearance. We really need to do this upfront before importing. But actually I like this much more than having projects developed outside and only later brought into our SVN - because this causes lots of paperwork (gas grants and a IP clearance review is mandatory). Thus a +1 LieGrue, strub From: Gerhard Petracek gerhard.petra...@gmail.com To: MyFaces Development dev@myfaces.apache.org Sent: Saturday, October 22, 2011 10:58 AM Subject: Re: [html5] alpha release for myfaces html5 a different idea would be a small myfaces-incubator for new project-ideas (esp. for gsoc projects). we can release parts easily and drop them if we see that something doesn't work for our community. if an idea works for the community, we can discuss the correct place for it. we might see new gsoc projects (related to myfaces) every year. imo it's the wrong approach to just add them as new sub-project and we don't have the resources/community to maintain them. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/10/22 Bernd Bohmann
[jira] [Created] (MYFACES-3382) Snapshot repository missing in MyFaces core pom.xml
Snapshot repository missing in MyFaces core pom.xml --- Key: MYFACES-3382 URL: https://issues.apache.org/jira/browse/MYFACES-3382 Project: MyFaces Core Issue Type: Bug Components: build process Affects Versions: 2.1.3 Reporter: Michael Kurz Currently, the version of org.apache.myfaces:myfaces was changed to 11-SNAPSHOT in the MyFaces core pom.xml. On machines that don't have this dependency in the local repository this breaks the build. The snapshot repository is referenced in the Apache parent which is useless if the MyFaces parent can't be found. I see 2 solutions: 1) (Redundantly) Add snapshot repo to MyFaces core pom.xml. 2) Don't use snapshot versions of the MyFaces parent. If there are no objections, I will commit solution 1. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3382) Snapshot repository missing in MyFaces core pom.xml
[ https://issues.apache.org/jira/browse/MYFACES-3382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13142933#comment-13142933 ] Mark Struberg commented on MYFACES-3382: ad 1.) The problem with redundantly adding the repo to all projects is obvious: it will not get automatically removed when releasing the project. ad 2.) is also no option. This did lead to poorly tested snapshots. E.g. mf-parent-10 was pretty much broken because it contained errors in the plugin config. actually I think there is a much better solution possible: We should update our WiKi to describe how to add an 'myfaces-snapshots' profile in ~/.m2/settings.xml Users who really like to compile those snapshots from source just need to enable this profile with % mvn clean install -Pmyfaces-snapshots Snapshot repository missing in MyFaces core pom.xml --- Key: MYFACES-3382 URL: https://issues.apache.org/jira/browse/MYFACES-3382 Project: MyFaces Core Issue Type: Bug Components: build process Affects Versions: 2.1.3 Reporter: Michael Kurz Currently, the version of org.apache.myfaces:myfaces was changed to 11-SNAPSHOT in the MyFaces core pom.xml. On machines that don't have this dependency in the local repository this breaks the build. The snapshot repository is referenced in the Apache parent which is useless if the MyFaces parent can't be found. I see 2 solutions: 1) (Redundantly) Add snapshot repo to MyFaces core pom.xml. 2) Don't use snapshot versions of the MyFaces parent. If there are no objections, I will commit solution 1. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3383) Self nested Composite Component leads to EL Stack Overflow
Self nested Composite Component leads to EL Stack Overflow -- Key: MYFACES-3383 URL: https://issues.apache.org/jira/browse/MYFACES-3383 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.1.2 Environment: Windows Reporter: Michael Dietrich If the same Composite Component is used inside itself, e.g. as child of an ui:include that is included in the Composite Component, an StackOverflow happens, if an EL Expression is refering CC interface attributes. The use case is a CC to include a facelet, given by name. If the included facelet uses the same CC to include another facelet, CompositeComponentELUtils.getCompositeComponentBasedOnLocation(..) does always find the same CC, which leads to an endless loop. Please see the attached file for an example of the issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3382) Snapshot repository missing in MyFaces core pom.xml
[ https://issues.apache.org/jira/browse/MYFACES-3382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13142947#comment-13142947 ] Michael Kurz commented on MYFACES-3382: --- Do I see this correctly: After calling building with -Pmyfaces-snapshots once you have the parent in your local repository and through the transitive dependency to apache parent you'll always get the current snapshot version from the repository. Even if you don't add -Pmyfaces-snapshots on subsequent builds. Snapshot repository missing in MyFaces core pom.xml --- Key: MYFACES-3382 URL: https://issues.apache.org/jira/browse/MYFACES-3382 Project: MyFaces Core Issue Type: Bug Components: build process Affects Versions: 2.1.3 Reporter: Michael Kurz Currently, the version of org.apache.myfaces:myfaces was changed to 11-SNAPSHOT in the MyFaces core pom.xml. On machines that don't have this dependency in the local repository this breaks the build. The snapshot repository is referenced in the Apache parent which is useless if the MyFaces parent can't be found. I see 2 solutions: 1) (Redundantly) Add snapshot repo to MyFaces core pom.xml. 2) Don't use snapshot versions of the MyFaces parent. If there are no objections, I will commit solution 1. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (MYFACES-3382) Snapshot repository missing in MyFaces core pom.xml
[ https://issues.apache.org/jira/browse/MYFACES-3382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13142947#comment-13142947 ] Michael Kurz edited comment on MYFACES-3382 at 11/3/11 8:26 AM: Do I see this correctly: After building with -Pmyfaces-snapshots once you have the parent in your local repository and through the transitive dependency to apache parent you'll always get the current snapshot version from the repository. Even if you don't add -Pmyfaces-snapshots on subsequent builds. was (Author: dr.gonzo): Do I see this correctly: After calling building with -Pmyfaces-snapshots once you have the parent in your local repository and through the transitive dependency to apache parent you'll always get the current snapshot version from the repository. Even if you don't add -Pmyfaces-snapshots on subsequent builds. Snapshot repository missing in MyFaces core pom.xml --- Key: MYFACES-3382 URL: https://issues.apache.org/jira/browse/MYFACES-3382 Project: MyFaces Core Issue Type: Bug Components: build process Affects Versions: 2.1.3 Reporter: Michael Kurz Currently, the version of org.apache.myfaces:myfaces was changed to 11-SNAPSHOT in the MyFaces core pom.xml. On machines that don't have this dependency in the local repository this breaks the build. The snapshot repository is referenced in the Apache parent which is useless if the MyFaces parent can't be found. I see 2 solutions: 1) (Redundantly) Add snapshot repo to MyFaces core pom.xml. 2) Don't use snapshot versions of the MyFaces parent. If there are no objections, I will commit solution 1. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3382) Snapshot repository missing in MyFaces core pom.xml
[ https://issues.apache.org/jira/browse/MYFACES-3382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13143002#comment-13143002 ] Michael Kurz commented on MYFACES-3382: --- OK, I gave it another thought and I'm not so happy with the profile. What people see is: it does not work. Btw.: If the dependency to the parent can be resolved, we get the snapshot repository anyway via apache parent. So I would say no harm done if we add it again. Snapshot repository missing in MyFaces core pom.xml --- Key: MYFACES-3382 URL: https://issues.apache.org/jira/browse/MYFACES-3382 Project: MyFaces Core Issue Type: Bug Components: build process Affects Versions: 2.1.3 Reporter: Michael Kurz Currently, the version of org.apache.myfaces:myfaces was changed to 11-SNAPSHOT in the MyFaces core pom.xml. On machines that don't have this dependency in the local repository this breaks the build. The snapshot repository is referenced in the Apache parent which is useless if the MyFaces parent can't be found. I see 2 solutions: 1) (Redundantly) Add snapshot repo to MyFaces core pom.xml. 2) Don't use snapshot versions of the MyFaces parent. If there are no objections, I will commit solution 1. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (EXTVAL-126) Implement the DateIsType.beforeOrSame and DateIsType.afterOrSame date comparisons
[ https://issues.apache.org/jira/browse/EXTVAL-126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rudy De Busscher resolved EXTVAL-126. - Resolution: Fixed Fix Version/s: 1.2.5 2.0.5 Implement the DateIsType.beforeOrSame and DateIsType.afterOrSame date comparisons - Key: EXTVAL-126 URL: https://issues.apache.org/jira/browse/EXTVAL-126 Project: MyFaces Extensions Validator Issue Type: Improvement Components: Property Validation Affects Versions: 1.2.4, 2.0.4 Reporter: Rudy De Busscher Priority: Minor Fix For: 2.0.5, 1.2.5 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3384) Cache lastModified info in myfaces-builder-plugin to prevent unnecessary executions
Cache lastModified info in myfaces-builder-plugin to prevent unnecessary executions --- Key: MYFACES-3384 URL: https://issues.apache.org/jira/browse/MYFACES-3384 Project: MyFaces Core Issue Type: Improvement Components: build process Reporter: Leonardo Uribe Assignee: Leonardo Uribe Some weeks ago I saw that maven checkstyle plugin creates a property file that store all lastModified dates of each file that is checked, to prevent unnecessary executions and improve speed. The hack is easy to do, but it is necessary move some refactor some code. In few words, the idea is get the lastModified date of each file parsed or used by myfaces-builder-plugin and save it in a file. When the goal is called again, it checks all files again and if the dates are the same, skip the goal. Additionally, myfaces-metadata.xml lastModified is saved and associated to each generated file. So if myfaces-metadata.xml is refreshed, we can check if the generated file has a previous lastModified date and if that so, create the file again. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MYFACES-3384) Cache lastModified info in myfaces-builder-plugin to prevent unnecessary executions
[ https://issues.apache.org/jira/browse/MYFACES-3384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-3384. - Resolution: Fixed Cache lastModified info in myfaces-builder-plugin to prevent unnecessary executions --- Key: MYFACES-3384 URL: https://issues.apache.org/jira/browse/MYFACES-3384 Project: MyFaces Core Issue Type: Improvement Components: build process Reporter: Leonardo Uribe Assignee: Leonardo Uribe Some weeks ago I saw that maven checkstyle plugin creates a property file that store all lastModified dates of each file that is checked, to prevent unnecessary executions and improve speed. The hack is easy to do, but it is necessary move some refactor some code. In few words, the idea is get the lastModified date of each file parsed or used by myfaces-builder-plugin and save it in a file. When the goal is called again, it checks all files again and if the dates are the same, skip the goal. Additionally, myfaces-metadata.xml lastModified is saved and associated to each generated file. So if myfaces-metadata.xml is refreshed, we can check if the generated file has a previous lastModified date and if that so, create the file again. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TRINIDAD-2156) Enhancements to the upload framework to support multiple files
Enhancements to the upload framework to support multiple files -- Key: TRINIDAD-2156 URL: https://issues.apache.org/jira/browse/TRINIDAD-2156 Project: MyFaces Trinidad Issue Type: Improvement Components: Components Affects Versions: 2.0.2-core Environment: linux x86 Reporter: Kentaro Kinebuchi Attachments: ER10348530-trinidad.patch The attached patch file contains several enhancements to the upload framework: 1. Support the ability to configure the maximum file size which can be uploaded. There is currently a parameter org.apache.myfaces.trinidad.UPLOAD_MAX_DISK_SPACE which controls how large the request can be. However, a request can potentially include multiple files so this parameter is insufficient. Add a new parameter called org.apache.myfaces.trinidad.UPLOAD_MAX_FILE_SIZE. 2. Enhance UploadedFiles to be able to support multiple files. Currently, FileUploadConfiguratorImpl already supports parsing multiple files in a single request but UploadedFiles does not contain the necessary APIs to grab those files. Add the new methods: public ListUploadedFile getUploadedFileList(String name) public MapString, ListUploadedFile getUploadedFileMap() 3. Add the ability to upload multiple files across requests. The upload framework currently disposes of all the uploaded files in a request once the request completes. This means that it is unable to support the behavior of some of the newer upload frameworks which upload files across several requests which enables monitoring of individual file upload progress, retry, cancel, etc. Enable this ability by being able to specially denote multiple file uploades across several requests and save those in the Session so they persist across requests. Add the new APIs below to UploadedFiles: static public UploadedFiles getSessionUploadedFiles(FacesContext context) public static void retrieveSessionUploadedFiles(ExternalContext context, String name) getSessionUploadedFiles() simply returns all the files currently in the Session. retrieveSessionUploadedFiles() will retrieve and remove all the files in the Session and is meant to be called once we have uploaded all the files and are ready to make them available to Faces lifecycle. 4. Update FileUploadConfiguratorImpl to support the additional processing of multiple files uploaded across requests. Those files will have a parameter called org.apache.myfaces.trinidad.UploadedFiles which will have the value of multipleAdd or multipleDelete depending on whether we want to add files to the session or delete them. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
