Re: [vote] release of Trinidad plugins (1.2.6)
did an update, to get TRINIDAD-907 in. -M On Jan 18, 2008 12:46 AM, Bruno Aranda <[EMAIL PROTECTED]> wrote: > +1 > > > On 17/01/2008, Gary Kind <[EMAIL PROTECTED]> wrote: > > +1 > > > > Matthias Wessendorf wrote: > > > Hi, > > > > > > I was running the needed tasks to get the 1.2.6 release of the Apache > > > MyFaces Trinidad Maven 2 Plugins out. > > > > > > The artifacts are deployed to my private Apache account ([1]). > > > > > > Please take a look at the "1.2.6" artifacts and vote. > > > > > > How to test those JARs ? > > > > > > 1. there is now a zip file (org.zip) (see [1]) > > > 2. use the stage repo inside your pom.xml file: > > > ... > > > > > > > > > apache.stage > > > Apache Stage Repository > > > http://people.apache.org/~matzew/126-plugins > > > default > > > > > > > > > ... > > > > > > > > > [ ] +1 for community members who have reviewed and tested 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/126-plugins/ > > > > > > > > > -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
[jira] Resolved: (TRINIDAD-907) Current maven-jdev-plugin does not handle nested maven projects whose packaging is "pom"
[ https://issues.apache.org/jira/browse/TRINIDAD-907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias Weßendorf resolved TRINIDAD-907. - Resolution: Fixed Fix Version/s: 1.2.6-plugins > Current maven-jdev-plugin does not handle nested maven projects whose > packaging is "pom" > > > Key: TRINIDAD-907 > URL: https://issues.apache.org/jira/browse/TRINIDAD-907 > Project: MyFaces Trinidad > Issue Type: Bug >Reporter: Gary Kind > Fix For: 1.2.6-plugins > > Attachments: maven-jdev-plugin-1.2.6-2.patch > > > So if a root project whose packaging is "pom" has a child project whose > packaging is also "pom" the resulting root JDeveloper workspace file, e.g. > trinidad.jws, is incorrect. References to this child project refer to it as > a JDeveloper project, e.g. trinidad-example.jpr, instead of a JDeveloper > workspace file, i.e. trinidad-example.jws, as it should be. > This patch addresses and fixes this problem -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TRINIDAD-908) optimize invokeOnComponent in a namingContainer
[ https://issues.apache.org/jira/browse/TRINIDAD-908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gabrielle Crawford resolved TRINIDAD-908. - Resolution: Fixed Fix Version/s: 1.2.6-core Completed: At revision: 613346 This fix only applies in 1.2 branch as it deals with invokeOnComponent, which is new in JSF 1.2 > optimize invokeOnComponent in a namingContainer > --- > > Key: TRINIDAD-908 > URL: https://issues.apache.org/jira/browse/TRINIDAD-908 > Project: MyFaces Trinidad > Issue Type: Bug >Affects Versions: 1.2.5-core >Reporter: Gabrielle Crawford >Priority: Minor > Fix For: 1.2.6-core > > > Avoid processing children based on id's in invokeOnComponent. > In UIXCollection it implements invokeOnComponent, and unless the client id > passed in starts with the client id of the collection, it doesn't process the > children. However not all our namingContainers are doing this. > NamingContainers that don't avoid processing children based on id's in > invokeOnComponent > * UIXComponentRef > * UIXDecorateCollection > * UIXMenu > * UIXSubform -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-908) optimize invokeOnComponent in a namingContainer
optimize invokeOnComponent in a namingContainer --- Key: TRINIDAD-908 URL: https://issues.apache.org/jira/browse/TRINIDAD-908 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.2.5-core Reporter: Gabrielle Crawford Priority: Minor Avoid processing children based on id's in invokeOnComponent. In UIXCollection it implements invokeOnComponent, and unless the client id passed in starts with the client id of the collection, it doesn't process the children. However not all our namingContainers are doing this. NamingContainers that don't avoid processing children based on id's in invokeOnComponent * UIXComponentRef * UIXDecorateCollection * UIXMenu * UIXSubform -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (TRINIDAD-906) optimize getClientId - use per thread shared StringBuilder
[ https://issues.apache.org/jira/browse/TRINIDAD-906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12560618#action_12560618 ] gabrielle edited comment on TRINIDAD-906 at 1/18/08 4:46 PM: -- Completed: At revision: 613322 for trunk 1.2 was (Author: gabrielle): Completed: At revision: 613322 > optimize getClientId - use per thread shared StringBuilder > -- > > Key: TRINIDAD-906 > URL: https://issues.apache.org/jira/browse/TRINIDAD-906 > Project: MyFaces Trinidad > Issue Type: Bug >Affects Versions: 1.2.5-core >Reporter: Gabrielle Crawford >Priority: Minor > Fix For: 1.0.6-core, 1.2.6-core > > > In getClientId/getContainerClientId we create a new stringBuilder. > However when creating a client id we only use one stringBuilder at a time, so > have a single instance of a StringBuilder saved on thread local. > Have a utility to get this instance, and any time a user gets the instance, > set the length of the stringBuilder to 0. This will completely break if a > user tries to call it for 2 stringbuilders, so doc this well. > Preliminary testing by a performance person here at Oracle found "the saving > is ~300KB out of 5850KB for the request. This is about 5% total request > memory. As expected profile shows that most of the memory saving comes from > not creating huge number of string builders" -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-906) optimize getClientId - use per thread shared StringBuilder
[ https://issues.apache.org/jira/browse/TRINIDAD-906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12560627#action_12560627 ] Gabrielle Crawford commented on TRINIDAD-906: - Completed: At revision: 613331 for trunk 1.0 > optimize getClientId - use per thread shared StringBuilder > -- > > Key: TRINIDAD-906 > URL: https://issues.apache.org/jira/browse/TRINIDAD-906 > Project: MyFaces Trinidad > Issue Type: Bug >Affects Versions: 1.2.5-core >Reporter: Gabrielle Crawford >Priority: Minor > Fix For: 1.0.6-core, 1.2.6-core > > > In getClientId/getContainerClientId we create a new stringBuilder. > However when creating a client id we only use one stringBuilder at a time, so > have a single instance of a StringBuilder saved on thread local. > Have a utility to get this instance, and any time a user gets the instance, > set the length of the stringBuilder to 0. This will completely break if a > user tries to call it for 2 stringbuilders, so doc this well. > Preliminary testing by a performance person here at Oracle found "the saving > is ~300KB out of 5850KB for the request. This is about 5% total request > memory. As expected profile shows that most of the memory saving comes from > not creating huge number of string builders" -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TRINIDAD-906) optimize getClientId - use per thread shared StringBuilder
[ https://issues.apache.org/jira/browse/TRINIDAD-906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gabrielle Crawford resolved TRINIDAD-906. - Resolution: Fixed Fix Version/s: 1.2.6-core Completed: At revision: 613322 > optimize getClientId - use per thread shared StringBuilder > -- > > Key: TRINIDAD-906 > URL: https://issues.apache.org/jira/browse/TRINIDAD-906 > Project: MyFaces Trinidad > Issue Type: Bug >Affects Versions: 1.2.5-core >Reporter: Gabrielle Crawford >Priority: Minor > Fix For: 1.2.6-core > > > In getClientId/getContainerClientId we create a new stringBuilder. > However when creating a client id we only use one stringBuilder at a time, so > have a single instance of a StringBuilder saved on thread local. > Have a utility to get this instance, and any time a user gets the instance, > set the length of the stringBuilder to 0. This will completely break if a > user tries to call it for 2 stringbuilders, so doc this well. > Preliminary testing by a performance person here at Oracle found "the saving > is ~300KB out of 5850KB for the request. This is about 5% total request > memory. As expected profile shows that most of the memory saving comes from > not creating huge number of string builders" -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-907) Current maven-jdev-plugin does not handle nested maven projects whose packaging is "pom"
Current maven-jdev-plugin does not handle nested maven projects whose packaging is "pom" Key: TRINIDAD-907 URL: https://issues.apache.org/jira/browse/TRINIDAD-907 Project: MyFaces Trinidad Issue Type: Bug Reporter: Gary Kind So if a root project whose packaging is "pom" has a child project whose packaging is also "pom" the resulting root JDeveloper workspace file, e.g. trinidad.jws, is incorrect. References to this child project refer to it as a JDeveloper project, e.g. trinidad-example.jpr, instead of a JDeveloper workspace file, i.e. trinidad-example.jws, as it should be. This patch addresses and fixes this problem -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-906) optimize getClientId - use per thread shared StringBuilder
optimize getClientId - use per thread shared StringBuilder -- Key: TRINIDAD-906 URL: https://issues.apache.org/jira/browse/TRINIDAD-906 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.2.5-core Reporter: Gabrielle Crawford Priority: Minor In getClientId/getContainerClientId we create a new stringBuilder. However when creating a client id we only use one stringBuilder at a time, so have a single instance of a StringBuilder saved on thread local. Have a utility to get this instance, and any time a user gets the instance, set the length of the stringBuilder to 0. This will completely break if a user tries to call it for 2 stringbuilders, so doc this well. Preliminary testing by a performance person here at Oracle found "the saving is ~300KB out of 5850KB for the request. This is about 5% total request memory. As expected profile shows that most of the memory saving comes from not creating huge number of string builders" -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (TOBAGO-602) UITabGroup should be an ActionSource
[ https://issues.apache.org/jira/browse/TOBAGO-602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12560539#action_12560539 ] bommel edited comment on TOBAGO-602 at 1/18/08 1:20 PM: --- UITabGroup has a TabChangeListener and a immediate attribute. Why UITabGroup should not be an ActionSource? TabChangeEvent should be an instance of ActionSource was (Author: bommel): UITabGroup has a TabChangeListener and a imediate attribute. Why UITabGroup should not be an ActionSource? > UITabGroup should be an ActionSource > > > Key: TOBAGO-602 > URL: https://issues.apache.org/jira/browse/TOBAGO-602 > Project: MyFaces Tobago > Issue Type: Improvement > Components: Core >Affects Versions: 1.0.13 >Reporter: Bernd Bohmann >Assignee: Bernd Bohmann > Fix For: 1.1.0 > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOBAGO-602) UITabGroup should be an ActionSource
UITabGroup should be an ActionSource Key: TOBAGO-602 URL: https://issues.apache.org/jira/browse/TOBAGO-602 Project: MyFaces Tobago Issue Type: Improvement Components: Core Affects Versions: 1.0.13 Reporter: Bernd Bohmann Assignee: Bernd Bohmann Fix For: 1.1.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOBAGO-602) UITabGroup should be an ActionSource
[ https://issues.apache.org/jira/browse/TOBAGO-602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12560539#action_12560539 ] Bernd Bohmann commented on TOBAGO-602: -- UITabGroup has a TabChangeListener and a imediate attribute. Why UITabGroup should not be an ActionSource? > UITabGroup should be an ActionSource > > > Key: TOBAGO-602 > URL: https://issues.apache.org/jira/browse/TOBAGO-602 > Project: MyFaces Tobago > Issue Type: Improvement > Components: Core >Affects Versions: 1.0.13 >Reporter: Bernd Bohmann >Assignee: Bernd Bohmann > Fix For: 1.1.0 > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOBAGO-601) UISelectBoolean.isSelected() produces ClassCastException
UISelectBoolean.isSelected() produces ClassCastException
Key: TOBAGO-601
URL: https://issues.apache.org/jira/browse/TOBAGO-601
Project: MyFaces Tobago
Issue Type: Bug
Affects Versions: 1.0.14
Environment: Facelets 1.1.14, MyFaces 1.1.6 snap (08.01.2008), Tobago
1.0.14 snap (16.01.2008)
Reporter: Guido Dubois
...
private Boolean primaryBacking;
private UISelectBoolean primaryBackingSelectBoolean;
...
if (this.primaryBackingSelectBoolean.isSelected()) {
...
Caused by: java.lang.ClassCastException: java.lang.String
at
javax.faces.component.UISelectBoolean.isSelected(UISelectBoolean.java:41)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Myfaces commons utils
// Helpful with tag auto generation. Though this isn't really required. /** * Return the same string. It is there for convenience and makes life easy * while auto generating tags. * @param value * @return */ public static String getString(.. this makes it clear, that the class is not really "nice", but used by the auto generated tags. On Jan 18, 2008 8:52 AM, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: > legacy... from Trinidad, just moved it over... to not brake things.. > > thx > > > On Jan 18, 2008 8:04 AM, Manfred Geiler <[EMAIL PROTECTED]> wrote: > > Just had a look at the new commons-utils module and found the class > > "TagUtils". > > Please forgive me for saying it directly: This piece of code is horrible! > > It seems to be a mixture of various static methods without any direct > > relation to "Tags". Looks like a huge graveyard for quick and dirty > > static code pieces. > > Having in mind a stable API (this is what we intended with these > > commons jars - right?) I must say we SHOULD get rid of this code > > and/or refactor it to several separate utils classes. Each one of them > > having a clear and certain scope. > > > > WDYT? > > > > --Manfred > > > > > > -- > Matthias Wessendorf > > further stuff: > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > mail: matzew-at-apache-dot-org > -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: Myfaces commons utils
legacy... from Trinidad, just moved it over... to not brake things.. thx On Jan 18, 2008 8:04 AM, Manfred Geiler <[EMAIL PROTECTED]> wrote: > Just had a look at the new commons-utils module and found the class > "TagUtils". > Please forgive me for saying it directly: This piece of code is horrible! > It seems to be a mixture of various static methods without any direct > relation to "Tags". Looks like a huge graveyard for quick and dirty > static code pieces. > Having in mind a stable API (this is what we intended with these > commons jars - right?) I must say we SHOULD get rid of this code > and/or refactor it to several separate utils classes. Each one of them > having a clear and certain scope. > > WDYT? > > --Manfred > -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: Myfaces commons utils
interesting class... yes, this should most probably be refactored ;) - even though I do see some methods for Tags (e.g. setting values from tag-attributes to component-attributes). regards, Martin On 1/18/08, Manfred Geiler <[EMAIL PROTECTED]> wrote: > Just had a look at the new commons-utils module and found the class > "TagUtils". > Please forgive me for saying it directly: This piece of code is horrible! > It seems to be a mixture of various static methods without any direct > relation to "Tags". Looks like a huge graveyard for quick and dirty > static code pieces. > Having in mind a stable API (this is what we intended with these > commons jars - right?) I must say we SHOULD get rid of this code > and/or refactor it to several separate utils classes. Each one of them > having a clear and certain scope. > > WDYT? > > --Manfred > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Myfaces commons utils
Just had a look at the new commons-utils module and found the class "TagUtils". Please forgive me for saying it directly: This piece of code is horrible! It seems to be a mixture of various static methods without any direct relation to "Tags". Looks like a huge graveyard for quick and dirty static code pieces. Having in mind a stable API (this is what we intended with these commons jars - right?) I must say we SHOULD get rid of this code and/or refactor it to several separate utils classes. Each one of them having a clear and certain scope. WDYT? --Manfred
[jira] Created: (TOMAHAWK-1178) Columns should support cellClasses attribute alike rowClasses for DataTable
Columns should support cellClasses attribute alike rowClasses for DataTable --- Key: TOMAHAWK-1178 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1178 Project: MyFaces Tomahawk Issue Type: New Feature Components: Columns Environment: All environments. Reporter: Mariusz Lipiński It should be possible to define certain CSS styles for certain data table columns,eg. cellClasses attribute for Columns component could be added and should have a meaning similar to rowClasses attribute for DataTable component. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: MyFaces Build Tools
nice On Jan 18, 2008 4:33 AM, Manfred Geiler <[EMAIL PROTECTED]> wrote: > ok, I will start the myfaces-master-pom release process right now > > --Manfred > > > > On Jan 18, 2008 12:59 PM, Simon Kitching <[EMAIL PROTECTED]> wrote: > > Matthias Wessendorf <[EMAIL PROTECTED]> schrieb: > > > Hi, > > > > > > I ported some "Trinidad fixes" over to the build-tools. > > > > > > I also think it might be the case where we want to release the bits, > > > to get them into usage. > > > > > > I think they are stable (since just created out to Trinidad), so we > > > might want go with a 1.0.0 instead > > > of something like 1.0.0-alpha > > > > > > What do you think? > > > > Sounds good to me. I'd love to see these released, and 1.0.0 sounds > > reasonable as the code is already known to work. > > > > However at the moment, myfaces-plugin-parent depends on the > > myfaces-master-pom version 4. IMO it would be nice to get > > myfaces-master-pom:5 released first, then used by the build plugins. > > > > The trunk version of myfaces-master has: > > (1) a new developer (gerhard) > > (2) updated plugin versions > > (3) versions defined for a bunch of plugins that had no version defined > > previously (ie not reproducable builds) > > > > Sorry, but I cannot offer to help with releasing the master, as I am rather > > overloaded at the moment... > > > > Regards, > > Simon > > > > > > -- > http://www.irian.at > Your JSF powerhouse - JSF Consulting, > Development and Courses in English and > German > > Professional Support for Apache MyFaces > -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: [VOTE] MyFaces Master pom v5
since timezone delay... my +1 is coming now ;) -M On Jan 18, 2008 6:18 AM, Manfred Geiler <[EMAIL PROTECTED]> wrote: > here is my own > +1 > > We got 4 positive votes. I hereby formally close this poll. > > --Manfred > > > > On Jan 18, 2008 2:51 PM, Bruno Aranda <[EMAIL PROTECTED]> wrote: > > +1 > > > > > > On 18/01/2008, Martin Marinschek <[EMAIL PROTECTED]> wrote: > > > +1, > > > > > > regards, > > > > > > Martin > > > > > > On 1/18/08, Simon Kitching <[EMAIL PROTECTED]> wrote: > > > > Manfred Geiler <[EMAIL PROTECTED]> schrieb: > > > > > This is the formal vote for the new myfaces master POM version 5. > > > > > > > > > > You can find the signed release candidate at [1]. > > > > > > > > > > Please vote > > > > > +1 if you reviewed the new master pom version and think we can use it > > > > > -1 if you found a flaw or potential problem with the new master pom > > > > > > > > +1 (non-binding). > > > > > > > > > > > > > -- > > > > > > http://www.irian.at > > > > > > Your JSF powerhouse - > > > JSF Consulting, Development and > > > Courses in English and German > > > > > > Professional Support for Apache MyFaces > > > > > > > > > -- > > http://www.irian.at > Your JSF powerhouse - JSF Consulting, > Development and Courses in English and > German > > Professional Support for Apache MyFaces > -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: MyFaces Build Tools
makes sense. On Jan 18, 2008 3:59 AM, Simon Kitching <[EMAIL PROTECTED]> wrote: > Matthias Wessendorf <[EMAIL PROTECTED]> schrieb: > > Hi, > > > > I ported some "Trinidad fixes" over to the build-tools. > > > > I also think it might be the case where we want to release the bits, > > to get them into usage. > > > > I think they are stable (since just created out to Trinidad), so we > > might want go with a 1.0.0 instead > > of something like 1.0.0-alpha > > > > What do you think? > > Sounds good to me. I'd love to see these released, and 1.0.0 sounds > reasonable as the code is already known to work. > > However at the moment, myfaces-plugin-parent depends on the > myfaces-master-pom version 4. IMO it would be nice to get > myfaces-master-pom:5 released first, then used by the build plugins. > > The trunk version of myfaces-master has: > (1) a new developer (gerhard) > (2) updated plugin versions > (3) versions defined for a bunch of plugins that had no version defined > previously (ie not reproducable builds) > > Sorry, but I cannot offer to help with releasing the master, as I am rather > overloaded at the moment... > > Regards, > Simon > -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: [VOTE] MyFaces Master pom v5
here is my own +1 We got 4 positive votes. I hereby formally close this poll. --Manfred On Jan 18, 2008 2:51 PM, Bruno Aranda <[EMAIL PROTECTED]> wrote: > +1 > > > On 18/01/2008, Martin Marinschek <[EMAIL PROTECTED]> wrote: > > +1, > > > > regards, > > > > Martin > > > > On 1/18/08, Simon Kitching <[EMAIL PROTECTED]> wrote: > > > Manfred Geiler <[EMAIL PROTECTED]> schrieb: > > > > This is the formal vote for the new myfaces master POM version 5. > > > > > > > > You can find the signed release candidate at [1]. > > > > > > > > Please vote > > > > +1 if you reviewed the new master pom version and think we can use it > > > > -1 if you found a flaw or potential problem with the new master pom > > > > > > +1 (non-binding). > > > > > > > > > -- > > > > http://www.irian.at > > > > Your JSF powerhouse - > > JSF Consulting, Development and > > Courses in English and German > > > > Professional Support for Apache MyFaces > > > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [VOTE] MyFaces Master pom v5
+1 On 18/01/2008, Martin Marinschek <[EMAIL PROTECTED]> wrote: > +1, > > regards, > > Martin > > On 1/18/08, Simon Kitching <[EMAIL PROTECTED]> wrote: > > Manfred Geiler <[EMAIL PROTECTED]> schrieb: > > > This is the formal vote for the new myfaces master POM version 5. > > > > > > You can find the signed release candidate at [1]. > > > > > > Please vote > > > +1 if you reviewed the new master pom version and think we can use it > > > -1 if you found a flaw or potential problem with the new master pom > > > > +1 (non-binding). > > > > > -- > > http://www.irian.at > > Your JSF powerhouse - > JSF Consulting, Development and > Courses in English and German > > Professional Support for Apache MyFaces >
[jira] Commented: (TOMAHAWK-1145) t:input calendar adds whitespace to page layout
[
https://issues.apache.org/jira/browse/TOMAHAWK-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12560374#action_12560374
]
Wolf Benz commented on TOMAHAWK-1145:
-
Not here.
I tried both adding
- with t: : document; documentHead, and t:documentBody
- with tr: document
The effects are:
t:calendarInput is not rendered. (not with the t:, nor with tr: solution)
-Wolf
> t:input calendar adds whitespace to page layout
> ---
>
> Key: TOMAHAWK-1145
> URL: https://issues.apache.org/jira/browse/TOMAHAWK-1145
> Project: MyFaces Tomahawk
> Issue Type: Bug
> Components: Calendar
>Affects Versions: 1.1.7-SNAPSHOT
> Environment: Myfaces 1.2.1 - Tomahawk 2.0 Snapshot (also previous
> versions) - Facelets 1.1.13
>Reporter: Wolf Benz
> Fix For: 1.1.7-SNAPSHOT
>
> Attachments: screenshot-1.jpg, screenshot-2.jpg, screenshot-3.jpg
>
>
> First of all: I have correctly set up my extension filter, nothing wrong
> there. Problems started when I "upgraded' to MF 1.2 and Tomahwak116, later
> Tomahawk 2.0 snapshot.
> Secondly: I don't know to what extend the problems I'm having are caused by
> using it n combination with Facelets, but I expect a correct taglib to be a
> central part of the problem as I get very different results, depending on the
> taglib used. (-> Cf. mailing list: repeated request to include the taglib in
> teh META-Inf dir for faclets users!!!)
> What happens is:
> When using this:
>renderAsPopup="true"
> renderPopupButtonAsImage="true"
> popupDateFormat="dd/MM/"
> popupButtonString="Click here to show Calendar"
> value="#{studyOverviewBean.study.plannedStartDate}"
> />
> ... several things happen:
> 1/ the layout is screwed: there is an anormous space between the "input text
> field" where the date is pasted and the actual icon one can click to have the
> calendar pop up.
> What makes it worse: this space is a vertical one...
> 2/ The whole popup thing just doesn't work. It pasts a sortof in-line
> calendar-rendering below the inputfield, which pushes everything underneath
> away, and even after picking a date(after which the inline rendering is
> gone), never corrects this space.
> I had diffrent behavior depeding on what was declared in the various taglibs
> I used (for facelets). I tried one from Google (provided by Bruno) and one
> other (provided by skalasoft) , which gave me the "best" results but even
> these were largely inappropriate.
> Hope this gets corrected soon in one of the intermediate MY1.2.1/Toma2.0
> releases. (by including a correct and complete taglib!!)
> -Wolf.
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [VOTE] MyFaces Master pom v5
+1, regards, Martin On 1/18/08, Simon Kitching <[EMAIL PROTECTED]> wrote: > Manfred Geiler <[EMAIL PROTECTED]> schrieb: > > This is the formal vote for the new myfaces master POM version 5. > > > > You can find the signed release candidate at [1]. > > > > Please vote > > +1 if you reviewed the new master pom version and think we can use it > > -1 if you found a flaw or potential problem with the new master pom > > +1 (non-binding). > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [VOTE] MyFaces Master pom v5
Manfred Geiler <[EMAIL PROTECTED]> schrieb: > This is the formal vote for the new myfaces master POM version 5. > > You can find the signed release candidate at [1]. > > Please vote > +1 if you reviewed the new master pom version and think we can use it > -1 if you found a flaw or potential problem with the new master pom +1 (non-binding).
Re: MyFaces Build Tools
ok, I will start the myfaces-master-pom release process right now --Manfred On Jan 18, 2008 12:59 PM, Simon Kitching <[EMAIL PROTECTED]> wrote: > Matthias Wessendorf <[EMAIL PROTECTED]> schrieb: > > Hi, > > > > I ported some "Trinidad fixes" over to the build-tools. > > > > I also think it might be the case where we want to release the bits, > > to get them into usage. > > > > I think they are stable (since just created out to Trinidad), so we > > might want go with a 1.0.0 instead > > of something like 1.0.0-alpha > > > > What do you think? > > Sounds good to me. I'd love to see these released, and 1.0.0 sounds > reasonable as the code is already known to work. > > However at the moment, myfaces-plugin-parent depends on the > myfaces-master-pom version 4. IMO it would be nice to get > myfaces-master-pom:5 released first, then used by the build plugins. > > The trunk version of myfaces-master has: > (1) a new developer (gerhard) > (2) updated plugin versions > (3) versions defined for a bunch of plugins that had no version defined > previously (ie not reproducable builds) > > Sorry, but I cannot offer to help with releasing the master, as I am rather > overloaded at the moment... > > Regards, > Simon > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[VOTE] MyFaces Master pom v5
This is the formal vote for the new myfaces master POM version 5. You can find the signed release candidate at [1]. Please vote +1 if you reviewed the new master pom version and think we can use it -1 if you found a flaw or potential problem with the new master pom Thanks, --Manfred [1] http://people.apache.org/builds/myfaces/m2-staging-repository/org/apache/myfaces/myfaces/5/
Re: MyFaces Build Tools
Matthias Wessendorf <[EMAIL PROTECTED]> schrieb: > Hi, > > I ported some "Trinidad fixes" over to the build-tools. > > I also think it might be the case where we want to release the bits, > to get them into usage. > > I think they are stable (since just created out to Trinidad), so we > might want go with a 1.0.0 instead > of something like 1.0.0-alpha > > What do you think? Sounds good to me. I'd love to see these released, and 1.0.0 sounds reasonable as the code is already known to work. However at the moment, myfaces-plugin-parent depends on the myfaces-master-pom version 4. IMO it would be nice to get myfaces-master-pom:5 released first, then used by the build plugins. The trunk version of myfaces-master has: (1) a new developer (gerhard) (2) updated plugin versions (3) versions defined for a bunch of plugins that had no version defined previously (ie not reproducable builds) Sorry, but I cannot offer to help with releasing the master, as I am rather overloaded at the moment... Regards, Simon
[jira] Commented: (MYFACES-1794) MF Core causes resources not found(404) errors (recently also corrected in Sun RI for JSF 1.2)
[ https://issues.apache.org/jira/browse/MYFACES-1794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12560333#action_12560333 ] Wolf Benz commented on MYFACES-1794: The problem is not solved - I still get the exact same error as before. (The M2 probs isn't solved either - I manually added the jars) -Wolf > MF Core causes resources not found(404) errors (recently also corrected in > Sun RI for JSF 1.2) > -- > > Key: MYFACES-1794 > URL: https://issues.apache.org/jira/browse/MYFACES-1794 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 1.2.0 > Environment: JSF 1.2 (failures mostly happen with extensions like > with Trinidad e.g.) >Reporter: Wolf Benz > Fix For: 1.2.1 > > > Cf. the MF mailing list: topics like "Dialog issue during ADF->Trinidad > migration" > I came across it using tr:inputDate but in the list topic I mentioned above, > so I first thought it was a Trinidad issue, but people more knowledgeable > with the JSF spec(Adam Winer) pointed out it was a MF 1.2 core issue, and > that the Sun RI had also sufferend from it, yet in the RI, this bug has > recently been corrected. > The error I got was when clicking the calendar icon and expecting a cal > popup. Instead I got: > "description The requested resource (.../__ADFv__.jsp) is not available." > As it potentially affects a lot of other components beyond this trinidad one, > I marked it major as these components just don't work anymore. > E.g. MF mailing list with topic "RE: [Trinidad] HTTP 404 (file not found) > while using DialogFramework" points that out. > --Wolf -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Bridge] Source tree restructuring
looks good to me! regards, Martin On 1/18/08, Scott O'Bryan <[EMAIL PROTECTED]> wrote: > Hey everyone, > > I just got back from a Face 2 Face of the JSR-301 Expert Group (the group > defining the Java Standard for the bridge). As I've been saying for a bit, > there is going to be a different specification for each portlet/jsf version > out there. Initially there will be two specifications produced though this > JSR. The first is the Portlet 1.0 Bridge for JSF 1.2 and the second is the > Portlet 2.0 Bridge for JSF 1.2. Eventually we'll probably have a Portlet > 2.0 Bridge for JSF 2.0 etc. I'm going to find a way to make this very easy > to figure out on the bridge web-site, but I think what we'd like to do is > have a single web-site for the bridge while still being able to maintain the > various (independently versioned) codelines of the bridge. > > So I'm thinking of restructuring the base level of the portlet bridge source > tree and I wanted to get everyones take on the following: > > > portlet-bridge >master > trunk - master pom for all bridges and main site > tags > branches >jsf1.2 > portlet1.0 > trunk > api > impl > demo > tags > branches > portlet2.0 > trunk > api > impl > demo > tags > branches > > Then as future JSR specs are added, we could just add the appropriate > directory and update the master pom file. > > *A NOTE ON THE BRIDGE* - Even though there are different versions of the > spec, the bridges are written such that the bridge for Portlet 1.0 should > run on Portlet 2.0 but without some of the extra functionality/correctness > or speed. An application upgrading to the Portlet 2.0 version of the spec > should have to change very little, if at all. The reason that we thought > that having seperate code trees for these versions was preferable is that > once the code in these codelines has stabilized, hopefully there will be > very little need to change the implementation short of an update to the > specification. So although the initial release of the bridge with these two > specifications in place may well mean we have to apply patches in two > places, I doubt that cost would continue as the project progresses. > > Anyone NOT think this structure is a good one? I'd like to apply it Monday > unless there are any concerns/suggestions. > > Scott > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [vote] release of Trinidad plugins (1.2.6)
+1 On 17/01/2008, Gary Kind <[EMAIL PROTECTED]> wrote: > +1 > > Matthias Wessendorf wrote: > > Hi, > > > > I was running the needed tasks to get the 1.2.6 release of the Apache > > MyFaces Trinidad Maven 2 Plugins out. > > > > The artifacts are deployed to my private Apache account ([1]). > > > > Please take a look at the "1.2.6" artifacts and vote. > > > > How to test those JARs ? > > > > 1. there is now a zip file (org.zip) (see [1]) > > 2. use the stage repo inside your pom.xml file: > > ... > > > > > > apache.stage > > Apache Stage Repository > > http://people.apache.org/~matzew/126-plugins > > default > > > > > > ... > > > > > > [ ] +1 for community members who have reviewed and tested 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/126-plugins/ > > > > >
