Re: [Proposal] Apache MyFaces commons
- Are we looking to define internal utilities shared among Trinidad/Tomahawk/Tobago? yes that's my understanding - Are we looking to define public APIs shared among these projects? yes common api for these projects but not necessarily immutable - Are we going to have a common package name for all such code? +1 IMO, we should: - Have no components at all in here, at least to start, whether or not they render markup. Definitely +1 - Use a common package name +1 - Be very cautious and slow as we build this up, being *really* sure about the APIs we're adding. This should be a foundational stone for a long time. +1 for go slow - Start enforcing a public vs. private API split for real, and be rigorous about when we change public APIs without preserving backwards compatibility. +0 it would be nice to have stable public API but i don't think that its the end of the world if its not stable. primary purpose of this (imo) is to promote consolidation and harmony amongst myfaces subprojects. Also, I don't think build dependencies belong in here, at least not in terms of a packaged JAR. Whether they live in a commons in terms of SVN locations is fine. not sure what this refers to. please explain. -- Adam sean
Re: [jira] [VOTE] MyFaces Core 1.1.5
+1 Thanks to all the new (and old) faces putting this release together. Sean On 2/15/07, Greg Reddin [EMAIL PROTECTED] wrote: +1 non-binding. I'm using the bits right now in our app that will be deployed to production Friday. Greg
ApacheCon Europe
Any MyFaces developers going to be at ApacheCon in Amsterdam? I know Matthias and I will be there? Who else? Looking forward to meeting some of my Europen counterparts... also to catch up on the MyFaces world since I've been a bit out of touch lately. Sean
Re: [Continuum] server down ?
I think we had this issue one other time where the server actually had to be physically rebooted. Very weird. Sean On 1/16/07, Bernd Bohmann [EMAIL PROTECTED] wrote: Hello Matthias, continuum doesn't response anymore. It's look like java or solaris is hanging in the network stack. But I'm not able to get more information. Open an issue on infra https://issues.apache.org/jira/browse/INFRA-1115 Regards Bernd Matthias Wessendorf wrote: Hi devs, I am not able to access myfaces.zones.apache.org:8080/continuum is that a *firewall* issue ? -M
Re: Patch Branch?
A patch release certainly would be a good idea but it takes time and resources to pull off each release. Its probably worth the effort since we tend to shoot ourselves in the foot when we release a whole set of features that sometimes contain radical changes and have not been tested extensively. Although it takes more effort, it might be nice to always have a patch branch available and then have an informal discussion on the dev list about which fixes belong in the patch vs. the next major release. Its the major refactoring that tends to cause problems due to our lack of unit tests. Sean On 1/5/07, Stan Silvert [EMAIL PROTECTED] wrote: Stan, do you have the JIRA issue and svn revision(s) for the portlet bug fix? I need to know if it affects Shared or just Core. -- Wendy It's just core. http://issues.apache.org/jira/browse/MYFACES-1481
Re: [continuum] BUILD FAILURE: Impl
In the meantime can I build the plugin myself? Should I build that
from the trunk?
Sean
On 11/30/06, Bruno Aranda [EMAIL PROTECTED] wrote:
Mmh, yes, probably the maven-faces-plugin used is not up to date (the
latest version is not in the temporary repo used now). Tonight or
tomorrow I will merge the maven-faces-plugin with the changes for
myfaces, with the official branch 1.2 for that plugin (in trinidad)
and I will update the info in the 1.2 myfaces branch,
I guess, you get this message because the UIMessage class is not
properly autogenerated,
Cheers,
Bruno
On 30/11/06, Sean Schofield [EMAIL PROTECTED] wrote:
I'm unable to build locally using a fresh checkout.
D:\open-source\myfaces-1.2\core\api\target\maven-faces-plugin\main\java\javax\fa
ces\component\UIMessage.java:[76,16] illegal start of expression
Sean
On 11/5/06, Dennis Byrne [EMAIL PROTECTED] wrote:
This runs fine for me locally. A confirmation from anyone would be
appreciated. Can one of the Continuum admins lend a hand here?
Dennis Byrne
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Sunday, November 5, 2006 08:17 PM
To: commits@myfaces.apache.org
Subject: [continuum] BUILD FAILURE: Impl
Online report :
http://myfaces.zones.apache.org:8080/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/64/buildId/5974
Build statistics:
State: Failed
Previous State: Failed
Started at: Mon, 6 Nov 2006 01:16:53 +
Finished at: Mon, 6 Nov 2006 01:17:05 +
Total time: 12s
Build Trigger: Schedule
Exit code: 1
Building machine hostname: myfaces.zones.apache.org
Operating system : SunOS(unknown)
Java version : 1.5.0_07(Sun Microsystems Inc.)
Changes
dennisbyrne MYFACES 1320 - finally got this one back
into the build
/myfaces/core/branches/jsf12/impl/pom.xml
/myfaces/core/branches/jsf12/impl/src/test/java/org/apache/myfaces/config/AbstractManagedBeanBuilderTestCase.java
Output:
[INFO] Scanning for projects...
[INFO]
[INFO] Building Impl
[INFO]task-segment: [clean, install]
[INFO]
[INFO] artifact org.codehaus.mojo:dependency-maven-plugin: checking for
updates from baranda-repo
[INFO] [clean:clean]
[INFO] Deleting directory
/local/continuum-1.0.3-SNAPSHOT/apps/continuum/working-directory/64/target
[INFO] Deleting directory
/local/continuum-1.0.3-SNAPSHOT/apps/continuum/working-directory/64/target/classes
[INFO] Deleting directory
/local/continuum-1.0.3-SNAPSHOT/apps/continuum/working-directory/64/target/test-classes
[INFO] snapshot
org.apache.myfaces.shared:myfaces-shared-impl:3.0.0-SNAPSHOT: checking for updates from
java.net
[INFO] snapshot
org.apache.myfaces.shared:myfaces-shared-impl:3.0.0-SNAPSHOT: checking for updates from
apache.snapshots
[INFO] snapshot
org.apache.myfaces.shared:myfaces-shared-project:3.0.0-SNAPSHOT: checking for updates
from java.net
[INFO] snapshot
org.apache.myfaces.shared:myfaces-shared-project:3.0.0-SNAPSHOT: checking for updates
from apache.snapshots
[INFO] snapshot org.apache.myfaces.core:myfaces-api:1.2.0-SNAPSHOT:
checking for updates from java.net
[INFO] snapshot org.apache.myfaces.core:myfaces-api:1.2.0-SNAPSHOT:
checking for updates from apache.snapshots
[INFO] [faces:generate-jsp-taglibs {execution: default}]
[WARNING] Master faces-config.xml not found
[INFO] Nothing to generate - no components found
[INFO] [xslt:transform {execution: default}]
[INFO] # of XML files: 2
[INFO] transform, srcFile:
/local/continuum-1.0.3-SNAPSHOT/apps/continuum/working-directory/64/src/main/tld/myfaces_core.tld,
destFile:
/local/continuum-1.0.3-SNAPSHOT/apps/continuum/working-directory/64/target/classes/META-INF/myfaces_core.tld
[INFO] transform, srcFile:
/local/continuum-1.0.3-SNAPSHOT/apps/continuum/working-directory/64/src/main/tld/myfaces_html.tld,
destFile:
/local/continuum-1.0.3-SNAPSHOT/apps/continuum/working-directory/64/target/classes/META-INF/myfaces_html.tld
[INFO] [faces:generate-faces-config {execution: default}]
[WARNING] Master faces-config.xml not found
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
Compiling 187 source files to
/local/continuum-1.0.3-SNAPSHOT/apps/continuum/working-directory/64/target/classes
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
/local/continuum-1.0.3-SNAPSHOT/apps
Re: [VOTE] s:selectItems to tomahawk
+1 for promoting to tomahawk now and perhaps moving stuff to commons later. Now I need to read the commons proposal ... sean On 11/27/06, Manfred Geiler [EMAIL PROTECTED] wrote: Yes, d'accord! I agree with Zubin that these are two different pairs of shoes. +1 for moving s:selectItems out of the tomahawk(!) sandbox to tomahawk core Let's keep an eye on a future alltogether-compatible-with-everything-components-set but do not not mix up with the commons jsf utils package proposal. If there is need for this common components project, we should start a new thread and bring this to a higher level, because there might be other renderkit-independent or standalone component like goodies as well, not only s:selectItems. Manfred On 11/27/06, Zubin Wadia [EMAIL PROTECTED] wrote: Aren't these 2 different threads? All Cagatay wants to do is promote the component... Then there was a thread just a few days ago about the commons-util, we should continue that conversation there... On 11/27/06, Manfred Geiler [EMAIL PROTECTED] wrote: Ok, now I do not understand anything anymore as well... :-) Seems, like we got our wires crossed. What is your exact proposal for the s:selectItems stuff. Moving it to both tomahawk as well as commons means what? Having a t:selectItems in tomahawk together with a org.apache.myfaces.tomahawk.custom.selectitems.SelectItemsTag that uses a common org.apache.myfaces.commons.component.UISelectItems ? Sorry, I didn't get it. :-( Manfred On 11/27/06, Bernd Bohmann [EMAIL PROTECTED] wrote: Hello Manfred, i don't understand you. What is wrong to move all the common renderkit stuff to a common package. This does't keep you to include this tag in the tomahawk tld. Here is my +1 for moving to tomahawk and +1 for moving in a common whatever artifact. and +1 for starting a myfaces common project. Regards Bernd Manfred Geiler wrote: Even if there is no renderer specific stuff involved, this goody is quite component like. Particularly the tag definition is the thing that makes it diffult to integrate into commons. We should not have another TLD in commons with another recommended prefix (c ?!). Wouldn't that be really confusing for the end user. He would have to define another TLD in his JSP headers which is not really a component collection but rather a... what? Therefore my feeling is, that this one belongs more to a component library than the common jsf utilities collection. This component being a goody that is nice for the tomahawk as well as the trinidad and tobago user is no argument IMO. This should be more a signal for us that we have to compass a one-that-plays-everything component library in the far (bright) future. i.e. Melt together our great component sets. So, I'm -0.5 for putting it into (future) commons, and I'am still +1 for moving it to tomahawk Manfred On 11/27/06, Volker Weber [EMAIL PROTECTED] wrote: Hi, i didn't know this component before, looks very usefull. I prefer to have this in the new commons project, to enabel the use in non tomahawk applications e.g. tobago. There is no renderer specific stuff involed? Regards, Volker 2006/11/26, Cagatay Civici [EMAIL PROTECTED]: Hi, I'm planning to promote s:selectItems to tomahawk. Component satisfies all of the requirements needed for promotion. Regards, Cagatay http://myfaces.apache.org/sandbox/selectItems.html
Re: [continuum] BUILD FAILURE: Impl
I'm unable to build locally using a fresh checkout.
D:\open-source\myfaces-1.2\core\api\target\maven-faces-plugin\main\java\javax\fa
ces\component\UIMessage.java:[76,16] illegal start of expression
Sean
On 11/5/06, Dennis Byrne [EMAIL PROTECTED] wrote:
This runs fine for me locally. A confirmation from anyone would be
appreciated. Can one of the Continuum admins lend a hand here?
Dennis Byrne
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Sunday, November 5, 2006 08:17 PM
To: commits@myfaces.apache.org
Subject: [continuum] BUILD FAILURE: Impl
Online report :
http://myfaces.zones.apache.org:8080/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/64/buildId/5974
Build statistics:
State: Failed
Previous State: Failed
Started at: Mon, 6 Nov 2006 01:16:53 +
Finished at: Mon, 6 Nov 2006 01:17:05 +
Total time: 12s
Build Trigger: Schedule
Exit code: 1
Building machine hostname: myfaces.zones.apache.org
Operating system : SunOS(unknown)
Java version : 1.5.0_07(Sun Microsystems Inc.)
Changes
dennisbyrne MYFACES 1320 - finally got this one back into
the build
/myfaces/core/branches/jsf12/impl/pom.xml
/myfaces/core/branches/jsf12/impl/src/test/java/org/apache/myfaces/config/AbstractManagedBeanBuilderTestCase.java
Output:
[INFO] Scanning for projects...
[INFO]
[INFO] Building Impl
[INFO]task-segment: [clean, install]
[INFO]
[INFO] artifact org.codehaus.mojo:dependency-maven-plugin: checking for
updates from baranda-repo
[INFO] [clean:clean]
[INFO] Deleting directory
/local/continuum-1.0.3-SNAPSHOT/apps/continuum/working-directory/64/target
[INFO] Deleting directory
/local/continuum-1.0.3-SNAPSHOT/apps/continuum/working-directory/64/target/classes
[INFO] Deleting directory
/local/continuum-1.0.3-SNAPSHOT/apps/continuum/working-directory/64/target/test-classes
[INFO] snapshot org.apache.myfaces.shared:myfaces-shared-impl:3.0.0-SNAPSHOT:
checking for updates from java.net
[INFO] snapshot org.apache.myfaces.shared:myfaces-shared-impl:3.0.0-SNAPSHOT:
checking for updates from apache.snapshots
[INFO] snapshot
org.apache.myfaces.shared:myfaces-shared-project:3.0.0-SNAPSHOT: checking for
updates from java.net
[INFO] snapshot
org.apache.myfaces.shared:myfaces-shared-project:3.0.0-SNAPSHOT: checking for
updates from apache.snapshots
[INFO] snapshot org.apache.myfaces.core:myfaces-api:1.2.0-SNAPSHOT: checking
for updates from java.net
[INFO] snapshot org.apache.myfaces.core:myfaces-api:1.2.0-SNAPSHOT: checking
for updates from apache.snapshots
[INFO] [faces:generate-jsp-taglibs {execution: default}]
[WARNING] Master faces-config.xml not found
[INFO] Nothing to generate - no components found
[INFO] [xslt:transform {execution: default}]
[INFO] # of XML files: 2
[INFO] transform, srcFile:
/local/continuum-1.0.3-SNAPSHOT/apps/continuum/working-directory/64/src/main/tld/myfaces_core.tld,
destFile:
/local/continuum-1.0.3-SNAPSHOT/apps/continuum/working-directory/64/target/classes/META-INF/myfaces_core.tld
[INFO] transform, srcFile:
/local/continuum-1.0.3-SNAPSHOT/apps/continuum/working-directory/64/src/main/tld/myfaces_html.tld,
destFile:
/local/continuum-1.0.3-SNAPSHOT/apps/continuum/working-directory/64/target/classes/META-INF/myfaces_html.tld
[INFO] [faces:generate-faces-config {execution: default}]
[WARNING] Master faces-config.xml not found
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
Compiling 187 source files to
/local/continuum-1.0.3-SNAPSHOT/apps/continuum/working-directory/64/target/classes
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
/local/continuum-1.0.3-SNAPSHOT/apps/continuum/working-directory/64/src/main/java/org/apache/myfaces/taglib/core/ConvertNumberTag.java:[19,45]
cannot find symbol
symbol : class UIComponentELTagUtils
location: package org.apache.myfaces.shared_impl.taglib
/local/continuum-1.0.3-SNAPSHOT/apps/continuum/working-directory/64/src/main/java/org/apache/myfaces/taglib/core/VerbatimTag.java:[19,45]
cannot find symbol
symbol : class UIComponentELTagBase
location: package org.apache.myfaces.shared_impl.taglib
/local/continuum-1.0.3-SNAPSHOT/apps/continuum/working-directory/64/src/main/java/org/apache/myfaces/taglib/core/VerbatimTag.java:[32,16]
cannot find symbol
symbol: class UIComponentELTagBase
extends UIComponentELTagBase
[jira] Created: (TOMAHAWK-795) rowCount not available for rendering determination
rowCount not available for rendering determination
--
Key: TOMAHAWK-795
URL: http://issues.apache.org/jira/browse/TOMAHAWK-795
Project: MyFaces Tomahawk
Issue Type: Bug
Components: Data List
Affects Versions: 1.1.5-SNAPSHOT
Reporter: sean schofield
t:dataTable rowCountVar=rowCount rendered=#{rowCount 1} does not
work as expected. The EL expression always evaluates to false.
Workaround:
Add a h:panelGroup rendered=#{rowCount 1} immediately inside the
t:dataList.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [OT] Javapolis 2006
That's a really bad time of year for a conference! I'd love to make it to Javapolis some year since I hear its so much fun but right before Christmas is tough. Sean ps. You going to ApacheCon europe next year? I will be there. On 11/4/06, Bruno Aranda [EMAIL PROTECTED] wrote: Hey, any of you attending to Javapolis 2006 next month in Antwerp. I will be there this time and maybe we could meet! Bruno
Re: Option for NavigationHandler to support viewIds as outcome
I think we should be very careful about adding a feature that encourages people to drift away from the spec. I agree with the reasons that Craig laid out for why the outcomes behave the way they do now. Its true that its not our job to force people to do follow certain standards. Its also true that we shouldn't be putting code into a shared codebase that serves the needs of a minority of the participants. I am not hearing a lot of enthusiastic support for this idea. Reactions are ranging from as long as its optional to this has no place in JSF. I think we should keep this out of Tomahawk. People are free to do whatever they want with their own code so this seems to be a case where that is most appropriate. Use it in your personal code and writeup a wiki or blog entry on it if you want to share it. Not everything has to make it in and it seems like enough people have reservations about it. My .02 Sean On 10/31/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: On 10/31/06, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! 1.) Seperate NavigationHandlerImpl IMHO, this is a must! I think we should *not* implement stuff which silently changes/enhances the behaviour - especially in myfaces-impl!! The TCK might forbid this change anyway ... +1 ! 2.) Configurable Option not required, as everyone can configure this NH in faces-config.xml. right! adding stuff to the web.xml for that is blech! 3.) Custom NH code in the wiki with a discouraged note This might be a good compromise. like we do with the JBoss stuff ? I don't mind that 4.) Not at all I do not mind ;-) 5) Add the new NH to the sandbox (but not configured by default) I like it to put stuff to the sandbox first and see if the community is willing to use them something like the time will tell if its worth. Yes, my understanding is that EVERY new Tomahawk stuff goes to Sandbox first. Components AND framework features. Go ahead Ernstl -M Ciao, Mario -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: How to dynamically show different components for each row in a table
This is probably best discussed on the users list. The dev list is for discussion of new components and general project coordination. Sean On 10/31/06, kevin_zhai [EMAIL PROTECTED] wrote: My table maybe each row(column) need different UI component(radio,button,checkbox,textbox,etc), so,use rendered attribute,it's not enough, I need ,dynamically creat my table depending data type from select from database data, btw,thanks you advise -- View this message in context: http://www.nabble.com/How-to-dynamically-show-different-components-for-each-row-in-a-table-tf2545575.html#a7095132 Sent from the My Faces - Dev mailing list archive at Nabble.com.
[jira] Commented: (TOMAHAWK-738) SaveState fails with a java.util.List implementation other than ArrayList
[
http://issues.apache.org/jira/browse/TOMAHAWK-738?page=comments#action_12442929
]
sean schofield commented on TOMAHAWK-738:
-
I was under the impression the original bug Catagay was trying to fix was that
Lists were not being saved by UISaveState correctly. My point is that they
would be saved correctly if passed to saveAttachedState in UIComponentBase (at
least if the spec were implemented properly.) I'm assuming he had a problem
b/c otherwise he would not have changed the code to check for StateHolder.
According to the spec, ListSerializable should work with UIComponentBase
saveAttachedState. Make sense? By the way, if this code is in Tomahawk 1.1.4
branch it needs to come out. ASAP.
SaveState fails with a java.util.List implementation other than ArrayList
-
Key: TOMAHAWK-738
URL: http://issues.apache.org/jira/browse/TOMAHAWK-738
Project: MyFaces Tomahawk
Issue Type: Bug
Components: UISaveState
Affects Versions: 1.1.4-SNAPSHOT
Reporter: Cagatay Civici
Assigned To: Cagatay Civici
Fix For: 1.1.4-SNAPSHOT
restoreAttachedState of UIComponentBase wraps the lists as an ArrayList so
restoring values fails when a list implementation other than an arraylist is
used.
An example;
private LinkedList list;
private String name;
private String surname;
public LinkedList getList() {
list = new LinkedList();
list.add(name);
list.add(surname);
return list;
}
public void setList(LinkedList list) {
name = (String)list.get(0);
surname = (String)list.get(1);
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TOMAHAWK-738) SaveState fails with a java.util.List implementation other than ArrayList
[
http://issues.apache.org/jira/browse/TOMAHAWK-738?page=comments#action_12442960
]
sean schofield commented on TOMAHAWK-738:
-
Thanks for clarifying. The only stuff I didn't revert was a testcase that
passes under 1.1.4 code and another one that I commented out. So I don't think
anything needs to go to the branch at this point.
SaveState fails with a java.util.List implementation other than ArrayList
-
Key: TOMAHAWK-738
URL: http://issues.apache.org/jira/browse/TOMAHAWK-738
Project: MyFaces Tomahawk
Issue Type: Bug
Components: UISaveState
Affects Versions: 1.1.5-SNAPSHOT
Reporter: Cagatay Civici
Assigned To: Cagatay Civici
Fix For: 1.1.5-SNAPSHOT
restoreAttachedState of UIComponentBase wraps the lists as an ArrayList so
restoring values fails when a list implementation other than an arraylist is
used.
An example;
private LinkedList list;
private String name;
private String surname;
public LinkedList getList() {
list = new LinkedList();
list.add(name);
list.add(surname);
return list;
}
public void setList(LinkedList list) {
name = (String)list.get(0);
surname = (String)list.get(1);
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TOMAHAWK-738) SaveState fails with a java.util.List implementation other than ArrayList
[
http://issues.apache.org/jira/browse/TOMAHAWK-738?page=comments#action_12443114
]
sean schofield commented on TOMAHAWK-738:
-
Again, nobody is saying there's not a problem here its just this solution
merely covers up a problem that exists in the implementation. At a minimum we
should check instanceof StateHolder on the restore call but it would be better
(IMO) to address the root cause of the problem that prevents saveAttachedState
to be called with List or whatever (as it clearly should be able to according
to the HTML docs/spec.)
SaveState fails with a java.util.List implementation other than ArrayList
-
Key: TOMAHAWK-738
URL: http://issues.apache.org/jira/browse/TOMAHAWK-738
Project: MyFaces Tomahawk
Issue Type: Bug
Components: UISaveState
Affects Versions: 1.1.5-SNAPSHOT
Reporter: Cagatay Civici
Assigned To: Cagatay Civici
Fix For: 1.1.5-SNAPSHOT
restoreAttachedState of UIComponentBase wraps the lists as an ArrayList so
restoring values fails when a list implementation other than an arraylist is
used.
An example;
private LinkedList list;
private String name;
private String surname;
public LinkedList getList() {
list = new LinkedList();
list.add(name);
list.add(surname);
return list;
}
public void setList(LinkedList list) {
name = (String)list.get(0);
surname = (String)list.get(1);
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Unable to compile -- Re: svn commit: r464453
Maven is complaining about a facelets plugin. Its not available in a
public repo and it doesn't seem to be in the myfaces/maven project.
Sean
On 10/16/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: tomsp
Date: Mon Oct 16 04:55:58 2006
New Revision: 464453
URL: http://svn.apache.org/viewvc?view=revrev=464453
Log:
TOMAHAWK-743 implemented
Added:
myfaces/tomahawk/trunk/sandbox/core/src/main/java/org/apache/myfaces/custom/fisheye/FishEyeCommandLink.java
myfaces/tomahawk/trunk/sandbox/core/src/main/java/org/apache/myfaces/custom/fisheye/FishEyeCommandLinkTag.java
myfaces/tomahawk/trunk/sandbox/core/src/main/java/org/apache/myfaces/custom/fisheye/FishEyeItem.java
myfaces/tomahawk/trunk/sandbox/core/src/main/tld/entities/html_fishey_commandlink_attributes.xml
myfaces/tomahawk/trunk/sandbox/examples/src/main/java/org/apache/myfaces/examples/fisheye/labels.properties
Modified:
myfaces/tomahawk/trunk/core/pom.xml
myfaces/tomahawk/trunk/sandbox/core/src/main/java/org/apache/myfaces/custom/fisheye/HtmlFishEyeNavigationMenu.java
myfaces/tomahawk/trunk/sandbox/core/src/main/java/org/apache/myfaces/custom/fisheye/HtmlFishEyeNavigationMenuRenderer.java
myfaces/tomahawk/trunk/sandbox/core/src/main/java/org/apache/myfaces/custom/fisheye/HtmlFishEyeNavigationMenuTag.java
myfaces/tomahawk/trunk/sandbox/core/src/main/resources-facesconfig/META-INF/faces-config.xml
myfaces/tomahawk/trunk/sandbox/core/src/main/tld/entities/html_fisheyelist_attributes.xml
myfaces/tomahawk/trunk/sandbox/core/src/main/tld/myfaces_sandbox.tld
myfaces/tomahawk/trunk/sandbox/examples/src/main/java/org/apache/myfaces/examples/fisheye/FishEyeHandler.java
myfaces/tomahawk/trunk/sandbox/examples/src/main/webapp/fisheye.jsp
Modified: myfaces/tomahawk/trunk/core/pom.xml
URL:
http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/core/pom.xml?view=diffrev=464453r1=464452r2=464453
==
--- myfaces/tomahawk/trunk/core/pom.xml (original)
+++ myfaces/tomahawk/trunk/core/pom.xml Mon Oct 16 04:55:58 2006
@@ -230,6 +230,18 @@
plugins
plugin
+groupIdorg.apache.myfaces.maven/groupId
+artifactIdfacelets-plugin/artifactId
+version1.0.5-SNAPSHOT/version
+executions
+ execution
+phasecompile/phase
+goalsgoalgenerate-taglibs/goal/goals
+ /execution
+/executions
+ /plugin
+
+ plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-surefire-plugin/artifactId
configuration
Added:
myfaces/tomahawk/trunk/sandbox/core/src/main/java/org/apache/myfaces/custom/fisheye/FishEyeCommandLink.java
URL:
http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/sandbox/core/src/main/java/org/apache/myfaces/custom/fisheye/FishEyeCommandLink.java?view=autorev=464453
==
---
myfaces/tomahawk/trunk/sandbox/core/src/main/java/org/apache/myfaces/custom/fisheye/FishEyeCommandLink.java
(added)
+++
myfaces/tomahawk/trunk/sandbox/core/src/main/java/org/apache/myfaces/custom/fisheye/FishEyeCommandLink.java
Mon Oct 16 04:55:58 2006
@@ -0,0 +1,66 @@
+package org.apache.myfaces.custom.fisheye;
+
+import org.apache.myfaces.shared_tomahawk.util._ComponentUtils;
+
+import javax.faces.component.UICommand;
+import javax.faces.el.ValueBinding;
+import javax.faces.context.FacesContext;
+
+/**
+ * @author Thomas Spiegl
+ */
+public class FishEyeCommandLink extends UICommand {
+private String _caption;
+private String _iconSrc;
+private String _target;
+
+public static final String COMPONENT_TYPE =
org.apache.myfaces.FishEyeCommandLink;
+public static final String RENDERER_TYPE =
org.apache.myfaces.FishEyeCommandLink;
+
+public String getCaption() {
+if (_caption != null) return _caption;
+ValueBinding vb = getValueBinding(caption);
+return vb != null ? _ComponentUtils.getStringValue(getFacesContext(),
vb) : null;
+}
+
+public void setCaption(String caption) {
+_caption = caption;
+}
+
+public String getIconSrc() {
+if (_iconSrc != null) return _iconSrc;
+ValueBinding vb = getValueBinding(iconSrc);
+return vb != null ? _ComponentUtils.getStringValue(getFacesContext(),
vb) : null;
+}
+
+public void setIconSrc(String iconSrc) {
+_iconSrc = iconSrc;
+}
+
+public String getTarget() {
+if (_target != null) return _target;
+ValueBinding vb = getValueBinding(target);
+return vb != null ? _ComponentUtils.getStringValue(getFacesContext(),
vb) : null;
+}
+
+public void setTarget(String target) {
+_target = target;
+}
+
+public Object saveState(FacesContext context) {
+Object[] state = new Object[4];
+state[0] = super.saveState(context);
+state[1] = _caption;
+
Re: svn commit: r464151 - /myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/savestate/UISaveState.java
Well it worked fine before. Now I get ... java.lang.IllegalStateException: Unknown object type javax.faces.component.UIComponentBase.restoreAttachedState(UIComponentBase.java:1436) org.apache.myfaces.custom.savestate.UISaveState.restoreState(UISaveState.java:74) javax.faces.component.UIComponentBase.processRestoreState(UIComponentBase.java:1147) javax.faces.component.UIComponentBase.processRestoreState(UIComponentBase.java:1163) javax.faces.component.UIComponentBase.processRestoreState(UIComponentBase.java:1163) I will try to come up with a unit test to prove the failure. I noticed Catagay added one to test the usecase he was fixing. This should be our standard practice from now on. We have a distressingly small number of testcases which is really starting to come back and bite us now. Sean On 10/16/06, Martin Marinschek [EMAIL PROTECTED] wrote: I don't see how this would break either. regards, Martin On 10/16/06, Cagatay Civici [EMAIL PROTECTED] wrote: I mean if an object(not List) is serializable saveAttachedState simply returns it so; values[1] = getValue() instanceof StateHolder ? saveAttachedState(context, getValue()) : getValue(); doesn't matter because saveAttachedState(context, getValue()) and getValue() are same for Serializable. Still I couldn't see why it breaks, an example should help. On 10/16/06, Cagatay Civici [EMAIL PROTECTED] wrote: Sean, I see that Serializable is already supported in saveAttachedState. I couldn't get why it's failing in your case, can you give more details? Cagatay On 10/16/06, Sean Schofield [EMAIL PROTECTED] wrote: Catagay this breaks my code. Serializable should also be supported. I have a bunch of Hibernate domain objects that are serializable that I use in a multi page table where I need save state. I'm going to reopen the JIRA issue. Sean On 10/15/06, Cagatay Civici [EMAIL PROTECTED] wrote: Yes sure, I'll apply the same to 1.1.4. Cagatay On 10/15/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 10/15/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: cagatay Date: Sun Oct 15 03:36:01 2006 New Revision: 464151 URL: http://svn.apache.org/viewvc?view=revrev=464151 Log: Fix for TOMAHAWK-738 Does this need to be applied to the branch for 1.1.4? Also... can you please include a short description of the change in addition to the JIRA issue number? It really helps when people who aren't familiar with the code are reviewing commits. And as great as JIRA is, the commit logs will probably outlive it. :) Thanks! -- Wendy -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[jira] Commented: (TOMAHAWK-738) SaveState fails with a java.util.List implementation other than ArrayList
[
http://issues.apache.org/jira/browse/TOMAHAWK-738?page=comments#action_12442650
]
sean schofield commented on TOMAHAWK-738:
-
I discovered the reason why Catagay's fix breaks my code. By not calling
saveAttachedState for Serializable objects that do not implement StateHolder
you will get an exception with the 1.2 RI when calling restoreAttachedState.
You really shouldn't call one without the other. The spec is a little unclear
on this and mentions only that restoreAttachedState is tightly coupled with
saveAttachedState and is meant to be called to restore objects that were saved
with that method.
The real problem is that the MyFaces core seems to have a spec compliance
issue. The original problem was that a List could not be saved and only a
StateHolder could be used. That clearly violates the spec which says:
This method supports saving attached objects of the following type: Objects,
null values, and Lists of these objects. If any contained objects are not Lists
and do not implement StateHolder, they must have zero-argument public
constructors. The exact structure of the returned object is undefined and
opaque, but will be serializable.
I suggest we create a new bug in the core project (with a category of JSF spec
compat) and then mark this bug as Won't Fix as well as link it to the new bug.
Finally, I suggest we add a new unit test to the core to expose the bug and
make it similar to Catagay's test case. Ideally we also change Catagay's test
case for UISaveState to use mocks to verify that save and restoreAttachedState
are being called (suggest JMock). You don't really want the test to pass
depending on which version of the JSF implementation you use.
SaveState fails with a java.util.List implementation other than ArrayList
-
Key: TOMAHAWK-738
URL: http://issues.apache.org/jira/browse/TOMAHAWK-738
Project: MyFaces Tomahawk
Issue Type: Bug
Components: UISaveState
Affects Versions: 1.1.4-SNAPSHOT
Reporter: Cagatay Civici
Assigned To: Cagatay Civici
Fix For: 1.1.4-SNAPSHOT
restoreAttachedState of UIComponentBase wraps the lists as an ArrayList so
restoring values fails when a list implementation other than an arraylist is
used.
An example;
private LinkedList list;
private String name;
private String surname;
public LinkedList getList() {
list = new LinkedList();
list.add(name);
list.add(surname);
return list;
}
public void setList(LinkedList list) {
name = (String)list.get(0);
surname = (String)list.get(1);
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: svn commit: r464151 - /myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/savestate/UISaveState.java
Found some more info. Lets move the discussion to TOMAHAWK-738. Sean On 10/16/06, Sean Schofield [EMAIL PROTECTED] wrote: Well it worked fine before. Now I get ... java.lang.IllegalStateException: Unknown object type javax.faces.component.UIComponentBase.restoreAttachedState(UIComponentBase.java:1436) org.apache.myfaces.custom.savestate.UISaveState.restoreState(UISaveState.java:74) javax.faces.component.UIComponentBase.processRestoreState(UIComponentBase.java:1147) javax.faces.component.UIComponentBase.processRestoreState(UIComponentBase.java:1163) javax.faces.component.UIComponentBase.processRestoreState(UIComponentBase.java:1163) I will try to come up with a unit test to prove the failure. I noticed Catagay added one to test the usecase he was fixing. This should be our standard practice from now on. We have a distressingly small number of testcases which is really starting to come back and bite us now. Sean On 10/16/06, Martin Marinschek [EMAIL PROTECTED] wrote: I don't see how this would break either. regards, Martin On 10/16/06, Cagatay Civici [EMAIL PROTECTED] wrote: I mean if an object(not List) is serializable saveAttachedState simply returns it so; values[1] = getValue() instanceof StateHolder ? saveAttachedState(context, getValue()) : getValue(); doesn't matter because saveAttachedState(context, getValue()) and getValue() are same for Serializable. Still I couldn't see why it breaks, an example should help. On 10/16/06, Cagatay Civici [EMAIL PROTECTED] wrote: Sean, I see that Serializable is already supported in saveAttachedState. I couldn't get why it's failing in your case, can you give more details? Cagatay On 10/16/06, Sean Schofield [EMAIL PROTECTED] wrote: Catagay this breaks my code. Serializable should also be supported. I have a bunch of Hibernate domain objects that are serializable that I use in a multi page table where I need save state. I'm going to reopen the JIRA issue. Sean On 10/15/06, Cagatay Civici [EMAIL PROTECTED] wrote: Yes sure, I'll apply the same to 1.1.4. Cagatay On 10/15/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 10/15/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: cagatay Date: Sun Oct 15 03:36:01 2006 New Revision: 464151 URL: http://svn.apache.org/viewvc?view=revrev=464151 Log: Fix for TOMAHAWK-738 Does this need to be applied to the branch for 1.1.4? Also... can you please include a short description of the change in addition to the JIRA issue number? It really helps when people who aren't familiar with the code are reviewing commits. And as great as JIRA is, the commit logs will probably outlive it. :) Thanks! -- Wendy -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[jira] Commented: (TOMAHAWK-738) SaveState fails with a java.util.List implementation other than ArrayList
[
http://issues.apache.org/jira/browse/TOMAHAWK-738?page=comments#action_12442661
]
sean schofield commented on TOMAHAWK-738:
-
I undid the most of the changes from revision 464151. I tried to create a
suitable test alternative but I ran out of time. Please fix your problem by
addressing the core which is not following the spec in this regard.
SaveState fails with a java.util.List implementation other than ArrayList
-
Key: TOMAHAWK-738
URL: http://issues.apache.org/jira/browse/TOMAHAWK-738
Project: MyFaces Tomahawk
Issue Type: Bug
Components: UISaveState
Affects Versions: 1.1.4-SNAPSHOT
Reporter: Cagatay Civici
Assigned To: Cagatay Civici
Fix For: 1.1.4-SNAPSHOT
restoreAttachedState of UIComponentBase wraps the lists as an ArrayList so
restoring values fails when a list implementation other than an arraylist is
used.
An example;
private LinkedList list;
private String name;
private String surname;
public LinkedList getList() {
list = new LinkedList();
list.add(name);
list.add(surname);
return list;
}
public void setList(LinkedList list) {
name = (String)list.get(0);
surname = (String)list.get(1);
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TOMAHAWK-491) t:columns generates wrong name in children input fields
[
http://issues.apache.org/jira/browse/TOMAHAWK-491?page=comments#action_12442440
]
sean schofield commented on TOMAHAWK-491:
-
m having a problemn passing a commandButton parameter inside of a t:column. I
wonder if this is due to the same problem? The JSF 1.2
setPropertyActionListener is also not working as expected with t:columns.
Instead of passing the one component that was clicked, all of the components in
the row are passed.
t:columns generates wrong name in children input fields
---
Key: TOMAHAWK-491
URL: http://issues.apache.org/jira/browse/TOMAHAWK-491
Project: MyFaces Tomahawk
Issue Type: Bug
Components: Columns
Affects Versions: 1.1.3
Environment: JSF 1.1 reference implementation
Reporter: Daniele Bernardini
Attachments: UIColumns.java
following jsf:
t:columns value=#{beanType.attributes} var=column
t:inputText value=#{bean.attributeValues[column]} id=stringInput/
/t:columns
generates:
tr class=row
tdinput id=_id0:_id1:0:_id2:stringInput
name=_id0:_id1:0:_id2:stringInput type=text value=drgsadsadf
15324//td
tdinput id=_id0:_id1:0:_id2:stringInput
name=_id0:_id1:0:_id2:stringInput type=text value=sdfsadf //td
/tr
tr class=row
tdinput id=_id0:_id1:1:_id2:stringInput
name=_id0:_id1:1:_id2:stringInput type=text value=dsdfasdf//td
tdinput id=_id0:_id1:1:_id2:stringInput
name=_id0:_id1:1:_id2:stringInput type=text value=sdsdfasdgsdgadf
//td
/tr
t:columns contributes always _id2 independently of the column being rendered,
this makes saving data from the input fields impossible.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: svn commit: r464151 - /myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/savestate/UISaveState.java
Catagay this breaks my code. Serializable should also be supported. I have a bunch of Hibernate domain objects that are serializable that I use in a multi page table where I need save state. I'm going to reopen the JIRA issue. Sean On 10/15/06, Cagatay Civici [EMAIL PROTECTED] wrote: Yes sure, I'll apply the same to 1.1.4. Cagatay On 10/15/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 10/15/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: cagatay Date: Sun Oct 15 03:36:01 2006 New Revision: 464151 URL: http://svn.apache.org/viewvc?view=revrev=464151 Log: Fix for TOMAHAWK-738 Does this need to be applied to the branch for 1.1.4? Also... can you please include a short description of the change in addition to the JIRA issue number? It really helps when people who aren't familiar with the code are reviewing commits. And as great as JIRA is, the commit logs will probably outlive it. :) Thanks! -- Wendy
[jira] Reopened: (TOMAHAWK-738) SaveState fails with a java.util.List implementation other than ArrayList
[ http://issues.apache.org/jira/browse/TOMAHAWK-738?page=all ]
sean schofield reopened TOMAHAWK-738:
-
Catagay this breaks my code. Serializable should also be supported. I have a
bunch of Hibernate domain objects that are serializable that I use in a multi
page table where I need save state.
SaveState fails with a java.util.List implementation other than ArrayList
-
Key: TOMAHAWK-738
URL: http://issues.apache.org/jira/browse/TOMAHAWK-738
Project: MyFaces Tomahawk
Issue Type: Bug
Components: UISaveState
Affects Versions: 1.1.5-SNAPSHOT
Reporter: Cagatay Civici
Assigned To: Cagatay Civici
Fix For: 1.1.5-SNAPSHOT
restoreAttachedState of UIComponentBase wraps the lists as an ArrayList so
restoring values fails when a list implementation other than an arraylist is
used.
An example;
private LinkedList list;
private String name;
private String surname;
public LinkedList getList() {
list = new LinkedList();
list.add(name);
list.add(surname);
return list;
}
public void setList(LinkedList list) {
name = (String)list.get(0);
surname = (String)list.get(1);
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TOMAHAWK-491) t:columns generates wrong name in children input fields
[ http://issues.apache.org/jira/browse/TOMAHAWK-491?page=all ]
sean schofield updated TOMAHAWK-491:
Status: Resolved (was: Patch Available)
Fix Version/s: 1.1.5-SNAPSHOT
Resolution: Fixed
I tested the fix and it works great! It also fixed my
f:setPropertyActionListener issue. This was actually a pretty serious bug
because as near as I could tell, all events would be applied to every column
value instead of only the correct column value. Thanks for contributing the
patch.
t:columns generates wrong name in children input fields
---
Key: TOMAHAWK-491
URL: http://issues.apache.org/jira/browse/TOMAHAWK-491
Project: MyFaces Tomahawk
Issue Type: Bug
Components: Columns
Affects Versions: 1.1.3
Environment: JSF 1.1 reference implementation
Reporter: Daniele Bernardini
Assigned To: sean schofield
Fix For: 1.1.5-SNAPSHOT
Attachments: UIColumns.java
following jsf:
t:columns value=#{beanType.attributes} var=column
t:inputText value=#{bean.attributeValues[column]} id=stringInput/
/t:columns
generates:
tr class=row
tdinput id=_id0:_id1:0:_id2:stringInput
name=_id0:_id1:0:_id2:stringInput type=text value=drgsadsadf
15324//td
tdinput id=_id0:_id1:0:_id2:stringInput
name=_id0:_id1:0:_id2:stringInput type=text value=sdfsadf //td
/tr
tr class=row
tdinput id=_id0:_id1:1:_id2:stringInput
name=_id0:_id1:1:_id2:stringInput type=text value=dsdfasdf//td
tdinput id=_id0:_id1:1:_id2:stringInput
name=_id0:_id1:1:_id2:stringInput type=text value=sdsdfasdgsdgadf
//td
/tr
t:columns contributes always _id2 independently of the column being rendered,
this makes saving data from the input fields impossible.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Tree2
The problem was that you changed the TreeWalker interface. I've fixed my TreeWalker implementations but everyone else is going to have to do the same. I suggest at a minimum that you create a JIRA issue and mark it resolved so it makes it into the release notes. Sean On 10/10/06, Martin Marinschek [EMAIL PROTECTED] wrote: Yeah. I've already settled for a subclass. I had to copy over almost everything from the tree-sources. The only thing which rescued me from having to copy all was introducing the interface. Sean, is there a way you can get the interface working according to your needs? regards, Martin On 10/10/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: I don't want the tree to _contain_ EditableValueHolders, but the tree to be an EditableValueHolder itself - imagine a dropdown which shows a tree, and you can select values from it... maybe a subclass is needed here, since that seams not to be a common use case, right? (I think we already said that during this thread) regards, Martin On 10/10/06, Sean Schofield [EMAIL PROTECTED] wrote: Martin, What is the big deal about EditableValueHolder? Why should tree2 implement this? The idea is that Tree2 contains a tree of whatever types of JSF components you choose (just like dataTable.) You can use editable value holders right now if you want to. Just add one to your node. I am probably missing something but at the moment I fail to see the problem. Also, your tree intereface has broken some things on my end. TreeWalker now needs to take an instance of Tree instead of UITreeData. This breaks some custom tree implementations that I have done offline so I may need to revert that. Let me see if I can work with what you have. Sean On 10/5/06, Martin Marinschek [EMAIL PROTECTED] wrote: No, it's a pity that not, but I can't. I'm at a client here in Germany until end of November, can't take off a week. regards, Martin On 10/5/06, Sean Schofield [EMAIL PROTECTED] wrote: Martin: I haven't had time to read this thread yet but I will shortly. Are you going to be at Apache Con this year? If so we can discuss some of your ideas in person as well. Sean On 10/5/06, Martin Marinschek [EMAIL PROTECTED] wrote: Well, it wouldn't be a problem to have an extended version of the tree which implements EditableValueHolder, but not if the model of the tree is configured by setting the value-attribute - then extending won't work. regards, Martin On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: hi Arash, sure your feedback is welcome :) like said before, a generic raw version + aditional tree stuff. During that task we should also take a look at tree / treeTable, IMHO. -M On 10/5/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote: Hello Mattias, I am so new to this list and may be I am not allowed to say this, but I think most developers I have seen use menu related components for only displaying structured data, and most of times data is displayed to user for one of the following purposes: 1) selecting one item 2) selecting multiple item 3) displaying and editing tree structured data (like organization chart, directory services, etc) the first 2 options are currently supported features of tree2, the 3'rd is under debate. May be if we can use same parent for both menu and tree navigation related components and simple tree data structure as said by matias and zubin, for parent of all these components can have following benefits: 1) simplifying development 2) simplifying learning for users 3) making it easier to add more advanced trees later on demand Best regards Arash On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: I think a tree should display structured data and not be an input component. What should the input be? So you are willing register also validators on the tree? maybe that is more specialized use case instead a generic tree use case you are looking at. On 10/5/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Matthias, for the reason that every component that has changing values needs to be an editable value holder. Imagine the case of a tree embedded in a data-table - a data-table, at least the ones of both MyFaces and the RI (I know, Trinidad's data-table does something different) only save whatever is part of the EditableValueHolder interface
Re: Tree2
Martin, What is the big deal about EditableValueHolder? Why should tree2 implement this? The idea is that Tree2 contains a tree of whatever types of JSF components you choose (just like dataTable.) You can use editable value holders right now if you want to. Just add one to your node. I am probably missing something but at the moment I fail to see the problem. Also, your tree intereface has broken some things on my end. TreeWalker now needs to take an instance of Tree instead of UITreeData. This breaks some custom tree implementations that I have done offline so I may need to revert that. Let me see if I can work with what you have. Sean On 10/5/06, Martin Marinschek [EMAIL PROTECTED] wrote: No, it's a pity that not, but I can't. I'm at a client here in Germany until end of November, can't take off a week. regards, Martin On 10/5/06, Sean Schofield [EMAIL PROTECTED] wrote: Martin: I haven't had time to read this thread yet but I will shortly. Are you going to be at Apache Con this year? If so we can discuss some of your ideas in person as well. Sean On 10/5/06, Martin Marinschek [EMAIL PROTECTED] wrote: Well, it wouldn't be a problem to have an extended version of the tree which implements EditableValueHolder, but not if the model of the tree is configured by setting the value-attribute - then extending won't work. regards, Martin On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: hi Arash, sure your feedback is welcome :) like said before, a generic raw version + aditional tree stuff. During that task we should also take a look at tree / treeTable, IMHO. -M On 10/5/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote: Hello Mattias, I am so new to this list and may be I am not allowed to say this, but I think most developers I have seen use menu related components for only displaying structured data, and most of times data is displayed to user for one of the following purposes: 1) selecting one item 2) selecting multiple item 3) displaying and editing tree structured data (like organization chart, directory services, etc) the first 2 options are currently supported features of tree2, the 3'rd is under debate. May be if we can use same parent for both menu and tree navigation related components and simple tree data structure as said by matias and zubin, for parent of all these components can have following benefits: 1) simplifying development 2) simplifying learning for users 3) making it easier to add more advanced trees later on demand Best regards Arash On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: I think a tree should display structured data and not be an input component. What should the input be? So you are willing register also validators on the tree? maybe that is more specialized use case instead a generic tree use case you are looking at. On 10/5/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Matthias, for the reason that every component that has changing values needs to be an editable value holder. Imagine the case of a tree embedded in a data-table - a data-table, at least the ones of both MyFaces and the RI (I know, Trinidad's data-table does something different) only save whatever is part of the EditableValueHolder interface. So the selection model of a tree won't be saved in a dataTable, except it is part of the EditableValueHolder interface. regards, Martin On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: I think a tree is much more about sturctured data instead of input data The UIXCollection is a base clazz for the stamping, that you can say var on those tags. UIComponent | + - UIXComponent | + - UIXComponentBase | + UIXCollection Collection has some subclasses like UIXHierarchy | + UIXTree and UIXIterator | + UIXTable The Trinidad Tree uses a TreeModel which extends CollectionModel (Trin) which extends DataModel (Faces). CollectionModel is also used by the Trin Table. But, I am not really sure, why the table should be EditableValueHolder ? Thanks! -Matthias On 10/5/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi *, yes, I'd also like to do an Ajaxified version, but that's not the first thing I'm looking at. I believe that extending from UIData is not really what we should do - UIData is totally row-based, and a row-index doesn't
Nice job on recent reorg
All of the recent changes to the Shale project look nice. I just tried rebuilding an app with the latest snapshot. Its nice how the MyFaces deps have been cleared up so that they don't end up in your webapp automatically. I'm using the RI to test some facelets stuff and before these recent changes, the MyFaces 1.1.1 distro kept popping up in my app. Nice work everyone! Sean
[offtopic][rollcall] Who's Going To Be At Apache Con?
Can we start a roll call of who is going to be at Apache Con and on what days? I'm posting this to both Shale and MyFaces list since I feel there is a lot of overlap between our two groups. I will be there Tuesday (late afternoon) - Friday (leaving early in the morning) Sean
Re: Build Failure!
There is a special startup script that Bernd wrote. Apparently the standard solaris script wasn't sufficient b/c of the processors used on the zone. /usr/local/continuum/bin/solaris-amd64/run.sh start I have always started it as the mrmaven user but it might be possible to start as yourself. Email me offline for the mrmaven password if you need it. Sean ps. Sorry for the long delay in responding. I've been on vacation and the day we got back we took my kid to the hospital with asthma. (He's fine now.) On 9/20/06, Grant Smith [EMAIL PROTECTED] wrote: OK, The zone is up again. I'm now trying to figure out how to get the continuum service running. Stay tuned :) On 9/19/06, Grant Smith [EMAIL PROTECTED] wrote: https://issues.apache.org/jira/browse/INFRA-954 Hopefully one of us will be given access to boot the zone ourselves... On 9/19/06, Grant Smith [EMAIL PROTECTED] wrote: The zone is hung again. I'm trying to get infra to bounce it in #asfinfra.. On 9/19/06, Grant Smith [EMAIL PROTECTED] wrote: I've been in panicemergencydeadlinecontemplatesuicide-mode for the past 3 months and am ashamed to admit I knew nothing of a continuum problem. I'll have a look tonight and see what I can uncover... The previous time I tried to build with maven, I had to bypass the tests. Today they all appear to be passing. Could this be related ? Sean is the real continuum/zone expert, but he's probably busy. We definitely need more people to understand the workings of the zone and the nightly build process, etc. If I remember correctly, I was about to document it... On 9/19/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 9/19/06, Dennis Byrne [EMAIL PROTECTED] wrote: What is the Continuum situation like these days. That's what I was wondering... though this was a problem in one of the example apps, and not in the Tomahawk jar itself. One of these days, I'd like to see if I can set it up to run the Selenium tests at HostedQA. http://myfaces.apache.org/tomahawk/testing/hostedqa.html -- Wendy -- Grant Smith -- Grant Smith -- Grant Smith -- Grant Smith
Re: [VOTE] Release MyFaces Core 1.1.4
A *huge* thank you to Wendy for taking the lead on the release. sean On 9/15/06, Bernd Bohmann [EMAIL PROTECTED] wrote: Hello Wendy, can we add the Tobago Announcement to the Core Announcement? Regards Bernd Matthias Wessendorf wrote: Wendy thanks for helping out on the release. Go ahead and announce it! On 9/15/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 9/11/06, Wendy Smoak [EMAIL PROTECTED] wrote: The MyFaces Core 1.1.4 build is available for evaluation: http://people.apache.org/builds/myfaces/core-1.1.4/ ... http://wiki.apache.org/myfaces/CoreRelease114 Vote Results: 6 +1 binding votes from PMC members: Dennis Byrne [1], Martin Marinschek, Grant Smith, Bruno Aranda, Matthias Wessendorf, Mike Kienenberger 2 +1 non-binding votes Cagatay Civici, Gerald Müllan (If I've got you in the wrong place, check the myfaces-master pom [2] to make sure your information is correct, and let me know.) I'll get this on the mirrors and the central Maven repository some time this weekend. I've added a draft release announcement to the release plan wiki page. (link above) If you want me to send it out, please adjust as necessary! (It might need a statement about what version of Tomahawk is compatible, and I have no idea.) Alternately, if someone else would like to make the announcement after everything is in place, that's fine with me. Manfred? Martin? [1] Dennis voted +1 when he reported the TCK test results: http://www.nabble.com/Re%3A--MyFaces-Core-1.1.4---STATUS-p6248637.html [2] http://svn.apache.org/repos/asf/myfaces/maven/trunk/master-pom/pom.xml Thanks, -- Wendy Smoak
Re: Tobago and MyFaces
There was a gentleman agreement that there is no commit from Tobagos to MyFaces, after the toboago incubation was done. Bernd and Volker are committers of MyFaces. This was only during the incubation period since the decision was made to host the incubated Tobago at MyFaces. Now that they are out of incubation I agree with Wendy and Craig that there should be no artificial separation here. Sean
Re: Unable to build Tomahawk
There must be something wrong with the shared snapshot in the myfaces repo. I was pulling it down but its clearly outdated. When I deleted all the myfaces artifacts from my local repo and rebuilt everything locally from source (instead of relying on the snapshots from the myfaces repo) it worked fine. That's definitely a problem though. We should be able to build tomahawk by itself. Sean On 9/1/06, Dennis Byrne [EMAIL PROTECTED] wrote: Can't help you. I just did a clean co and build. My guess is that you and I may have a different jar somewhere in our local repos ... or perhaps it has something to do w/ the fact that you are only building tomahawk, not the whole thing. Hope this helps. Dennis Byrne -Original Message- From: Sean Schofield [mailto:[EMAIL PROTECTED] Sent: Thursday, August 31, 2006 10:01 PM To: 'MyFaces Development' Subject: Unable to build Tomahawk I can't seem to do a clean checkout and build of Tomahawk. D:\open-source\myfaces\tomahawk\core\src\main\java\org\apache\myfaces\custom\tre e\renderkit\html\HtmlTreeNodeRenderer.java:[40,16] getHiddenCommandLinkFieldName (java.lang.String) in org.apache.myfaces.shared_tomahawk.renderkit.html.HtmlRend ererUtils cannot be applied to (org.apache.myfaces.shared_tomahawk.renderkit.htm l.util.FormInfo) Any ideas on why this doesn't work for me (but apparently works for others?) Sean
Re: Zone and release questions
Sean, do you have a release diary or notes on the Core 1.1.3 release? I can only find http://wiki.apache.org/myfaces/Release_Procedure but I thought I had seen more detailed notes somewhere. Sorry. We were once again in a rush and I was doing everything myself. I'm aftraid that's it. The mrmaven account only has Core 1.1.2 checked out in the home directory, yet the 1.1.3 release is in /dist/maven-repository on the zone. Where did you execute 'mvn release' from for 1.1.3? I can't remember exactly (I know - documentation would help here.) I recall that I did things differently for 1.1.3. I think I skipped the release:prepare and release stuff since it was such a PITA. For instance, you have to run them both from the same machine. I believe I just ran mvn deploy and deployed it to the local repo. The thinking was that we could copy over to the rsync dir when ready but obviously that turned out to not be such a good plan. I have the core 1.1.4/shared 2.0.3 branches checked out as mrmaven, they build fine. I guess I'm not clear why I need to do this on the zone box. As long as scp works, I think I can build locally and deploy to dist/maven-repository on the zone. Scp doesn't work on my own personal machine (running windows here at home.) So it was easier to do it there. No special reason for this though. Also, can we have a link from /www on the zone to the httpd document root? I don't want scp urls that have the full path from /var down to the Maven repo. Done. I'm almost ready for 1.1.4. Maybe this weekend. :) Great! Thanks! -- Wendy Sean
Unable to build Tomahawk
I can't seem to do a clean checkout and build of Tomahawk. D:\open-source\myfaces\tomahawk\core\src\main\java\org\apache\myfaces\custom\tre e\renderkit\html\HtmlTreeNodeRenderer.java:[40,16] getHiddenCommandLinkFieldName (java.lang.String) in org.apache.myfaces.shared_tomahawk.renderkit.html.HtmlRend ererUtils cannot be applied to (org.apache.myfaces.shared_tomahawk.renderkit.htm l.util.FormInfo) Any ideas on why this doesn't work for me (but apparently works for others?) Sean
Re: Continuum freezed on myfaces.zones.apache.org
I can' t seem to kill the one process (even as root). I've asked INFRA to reboot the zone.[1] Sean [1] http://issues.apache.org/jira/browse/INFRA-925 On 8/25/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: yeah, same here :( anyone listening ? On 8/24/06, Bernd Bohmann [EMAIL PROTECTED] wrote: Hello, can somebody kill the processid 19259 and restart continuum? I think continuum is not running and i can't really stop it. Regards Bernd -- Matthias Wessendorf further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Keeping 1.2 in sync with 1.1 patches?
What about getting this current version of the core trunk released? If we don't get a decent version of the 1.1.x core out there soon we won't have anybody interested in a 1.2.x version. If we manage to get a stable core release done I think we can just leave the trunk alone. There shouldn't be too many more bug fixes - and if there are - we just merge them up to the branch. I haven't been following the branch but I can see a situation where some of the fixes might not merge so cleanly. In these cases we'll have to do a manual merge. Sean On 8/25/06, Dennis Byrne [EMAIL PROTECTED] wrote: I can't really take 'ownership' of this one, but I'll give it a shot. If anything, it would be an excellent way for one of us to stay up to task on all the latest core changes. Dennis Byrne -Original Message- From: Mike Kienenberger [mailto:[EMAIL PROTECTED] Sent: Friday, August 25, 2006 05:24 PM To: 'MyFaces Development' Subject: Re: Keeping 1.2 in sync with 1.1 patches? I'm a novice when it comes to merging, but what about periodically merging changes from 1.1 core to the 1.2 branch? Maybe once a week or something? Is that a possible solution? On 8/25/06, Martin Marinschek [EMAIL PROTECTED] wrote: Afaik, we're supposed to work on both branches, with the hope of merging again sometime down the road. I wonder how this will work though, with all the changes that 1.2 will require with regards to JDK1.5. regards, Martin On 8/25/06, Mike Kienenberger [EMAIL PROTECTED] wrote: This is just a quick question before I forget to ask it again How are those of you who are working on the 1.2 branch keeping the patches to core1.1 in sync? From the commit messages I've seen, the only changes have been to implement 1.2 specific functionality. -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[dialog] Basic button functionality
I think it would be highly desirable to provide some sort of basic button functionality (previous, next, ok and cancel). I'm not saying we render buttons on the dialog for the user, but I am saying that most dialogs have certain things in common that we should just incorporate into the basic functionality. JSF can already give you most of what you need for dialogs without using Shale - lets try and enhance things in a way that would make it worthwhile for our users. On my last job I used dialogs extensively, but as I think about it, the most important functionality was added on top of what was provided. We had several dialogs that involved a series of steps. Some of the steps were common between multiple dialogs but we also had cases where the user could later revisit just a single step. So in some cases the foo screen needed a next button (when used in the multi step dialogs) but in other cases you just want an ok and cancel button (as in the single step dialog case.) The existing dialog functionality was helpful because I could easily examine the transitions but it took a long time to work out some of the more complicated details. I was going to try and sketch out some ideas here in the email but I changed my mind. I'm going to put some very rough code into the sandbox. Instead of using the sandbox for a staging area for near complete code, we could use it to sketch out some rough ideas. Why not? Craig and I both agree it would be nice to have this wrapped up in a few weeks so we can release before Apache Con. David would probably also like to make sure his book isn't out of date so we'll have to move very quickly on this. Sean
Re: [dialog] Basic button functionality
Doh. Wrong list again. On 8/24/06, Sean Schofield [EMAIL PROTECTED] wrote: I think it would be highly desirable to provide some sort of basic button functionality (previous, next, ok and cancel). I'm not saying we render buttons on the dialog for the user, but I am saying that most dialogs have certain things in common that we should just incorporate into the basic functionality. JSF can already give you most of what you need for dialogs without using Shale - lets try and enhance things in a way that would make it worthwhile for our users. On my last job I used dialogs extensively, but as I think about it, the most important functionality was added on top of what was provided. We had several dialogs that involved a series of steps. Some of the steps were common between multiple dialogs but we also had cases where the user could later revisit just a single step. So in some cases the foo screen needed a next button (when used in the multi step dialogs) but in other cases you just want an ok and cancel button (as in the single step dialog case.) The existing dialog functionality was helpful because I could easily examine the transitions but it took a long time to work out some of the more complicated details. I was going to try and sketch out some ideas here in the email but I changed my mind. I'm going to put some very rough code into the sandbox. Instead of using the sandbox for a staging area for near complete code, we could use it to sketch out some rough ideas. Why not? Craig and I both agree it would be nice to have this wrapped up in a few weeks so we can release before Apache Con. David would probably also like to make sure his book isn't out of date so we'll have to move very quickly on this. Sean
Re: [dialog] Basic button functionality
I suspect what Adam is asking about is Shale getting in the business of creating visual components like buttons in order to implement the Next/Previous type of thing. That's an area I have wanted to shy away from, and this kind of thing is a case in point for why. No matter what we do, our navigation buttons are going to stick out like a sore thumb visually, unless the user takes great pains to style them similar to whatever theming or skinning strategy the developer is using on all the other components. That's how I took his meaning and I totally agree with both of you. That being said, the logical concept that a general purpose dialog architecture might want to support explicit mechanisms for wizard-style navigation is well taken. But we should strive to make it possible to incorporate existing button or hyperlink components from your favorite component library, instead of imposing our own. Exactly what I'm suggesting (see my comments on the shale-dev list.) Craig Sean
Re: Re: Getting rid of the wish issue type
Sorry but its been there all along. Sean On 8/20/06, Mike Kienenberger [EMAIL PROTECTED] wrote: Has this stuff been here all along and I somehow missed it when looking for it, or was it added recently (in the last couple of months)? I feel like a fool for not seeing it up to this point. On 8/20/06, Adam Winer [EMAIL PROTECTED] wrote: Even easier than that - there''s a link right off the main Browse Project page... Look under Project Summary at http://issues.apache.org/jira/browse/MYFACES -- Adam On 8/20/06, Sean Schofield [EMAIL PROTECTED] wrote: Is there any way to search for Patch Available issues? I haven't been able to figure this out yet myself. Just create a custom search under Find Issues Be sure to change the project to MyFaces and click the refresh link that they show you. Otherwise you are stuck with options available for all projects and you don't see MyFaces specific stuff. Sean
Re: Getting rid of the wish issue type
+1 for removing wish. Its all a wish - even the bugs. I think the current voting system is a better way for finding what the popular requests are. IMO those take second priority over Patch Available. sean On 8/18/06, Cagatay Civici [EMAIL PROTECTED] wrote: for a wish ? Yes, I do it if only I believe the demand seems important. But no problem for me, I'd not oppose getting rid of wish type issues. On 8/18/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Well, I'm doing that and assign the issues that I find reasonable to myself. for a wish ? I look at open issues (bugs) but not wishes. On 8/17/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: +1 On 8/17/06, Mike Kienenberger [EMAIL PROTECTED] wrote: I think we should get rid of the wish issue type. I don't see that we're likely to have someone surfing the jira issue tracker looking for things to do. If someone wants to wish for something, the user list (or maybe a wiki page) seems like a better place to do it. All this issue type is doing is collecting work that other people are not willing to do themselves. We already have a new feature type that people use when they plan to provide patches to implement their new feature. -- Matthias Wessendorf further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: MyFaces zone account?
Do you have an account yet? If not, I can create one for you. Sean On 8/16/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: see offline email On 8/16/06, Wendy Smoak [EMAIL PROTECTED] wrote: Can I get an account on the MyFaces zone? Recent discussion about the Core 1.1.4 release indicated that we should stage it on the zone. I'd like to be able to get in so I can help Matthias with the release. Thanks, -- Wendy -- Matthias Wessendorf further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Proposal: Mark fixed issues as resolved instead of closed -- close all resolved issues on release
+1 We basically decided on this a long time ago but not everyone is following it. Newer versions of JIRA (in use with Shale but not MyFaces) also allows you to disable email on bulk changes. At some point I will change the JIRA workflow so that you can not directly close a feature (it must be resolved first.) This will help enforce the policy. Sean On 8/18/06, Bruno Aranda [EMAIL PROTECTED] wrote: +1 I thought we were doing that already, Cheers, Bruno On 8/17/06, Cagatay Civici [EMAIL PROTECTED] wrote: I totaly agree. Regards Cagatay On 8/17/06, Mike Kienenberger [EMAIL PROTECTED] wrote: On 8/17/06, Mike Kienenberger [EMAIL PROTECTED] wrote: Now that JIRA supports bulk operations, I'd like to propose that we use the resolve status to identify things that are fixed, but not yet available in a release.As part of the release process, we would change all resolved issues for a snapshot to closed after the release is made. Also, so long as every change is documented as a JIRA issue, these resolved issues can also be used to generate our release notes/change log for the release. So it's equally-important to have a JIRA issue for each change made.
[jira] Created: (MYFACES-1390) Change JIRA workflow so issues must be resolved before they are closed
Change JIRA workflow so issues must be resolved before they are closed -- Key: MYFACES-1390 URL: http://issues.apache.org/jira/browse/MYFACES-1390 Project: MyFaces Core Issue Type: Task Components: General Reporter: sean schofield Assigned To: sean schofield -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Proposal: Mark fixed issues as resolved instead of closed -- close all resolved issues on release
Can you do it so this is only required for Fixed issues? Invalid/Won't Fix issues should be closed directly. Why should these be closed directly? Maybe we would revisit one of these before the release is done. Also, I believe having them resolved (instead of closed) allows the user to appeal and reopen. Just some thoughts ... Sean
Re: Getting rid of the wish issue type
Is there any way to search for Patch Available issues? I haven't been able to figure this out yet myself. Just create a custom search under Find Issues Be sure to change the project to MyFaces and click the refresh link that they show you. Otherwise you are stuck with options available for all projects and you don't see MyFaces specific stuff. Sean
Re: past problems w/ externals ?
The problem with externals is when you start moving and renaming stuff in subversion. When we did a massive reorg everything started to break. The svn externals point to the same location even after you do an svn move. That makes sense since they're not smart enough to know how to change themselves. So it becomes a maintenance nightmare as the number of tagged versions and branches starts to grow. Also, it can introduce even subtler problems if the external still results in code that compiles but its not the expected code. We only have one external now which is current. Current is just for convenience sake and if it breaks, it doesn't prevent you from building the intended code. Sean On 8/10/06, Mike Kienenberger [EMAIL PROTECTED] wrote: While there was a lot of talk about disliking externals, here is the only thing I found that gave any reasons: -- Forwarded message -- From: Sean Schofield [EMAIL PROTECTED] Date: Jan 1, 2006 10:35 PM Subject: Re: Maven Build (Ongoing Work Thread) To: MyFaces Development dev@myfaces.apache.org [...] I wonder if there is an easy way to share website resources in maven? I don't think we should have 10 copies of the stylesheets, etc. per project. We can use externals but I hesitate to do that b/c they are a PITA when you are branching and tagging (the externals don't change automatically - you have to change them all manually.) Sean
Re: myfaces 114
myfaces repo is fine for me +1 This has the extra benefit of being available as a backup if ibiblio is unavailable. We can just leave them there if they pass the TCK. I think myfaces repo is fine, b/c there is no real shared.jar which the users need. Agreed. Matthias Wessendorf Sean
Re: myfaces 114
And how are we going to handle the vote? I think we should tag and build it as 1.1.4, run the TCK, then vote. Other opinions? (The guidelines on the wiki may need to be revised.) So the plan is: 1.) Deploy to the snapshot repo 2.) Vote 3.) Manually copy to the ibiblio sync dirs? And we do this for both shared and core right? And does shared go to ibiblio or do we keep that on our internal repo only? Wendy Sean
Re: tree2 documentation: value, var, varNodeToggler missing
I'm guessing var and value work like any UIData component (and it should be simple to copy those into the tlddocs from dataTable). You guessed correctly. However, varNodeToggler doesn't have any non-code documentation that I could find. I'm guessing it's an object that implements some kind of isExpanded/isCollapsed functionality and acts accordingly when a node's visibility state changes. Yes. I will try to elaborate on that shortly (facing a deadline atm.) Also, the http://www.irian.at/myfaces/tree2NoNav.jsf example seems kinda lame (only one node visible). That doesn't sound right? Did you try expanding it? Again, I will look at it shortly. Sean
Re: tree2 documentation: value, var, varNodeToggler missing
No documentation on what the allowable facets are. No documentation stating that expand and collapse facets need to be UIGraphic components. [Guess I shouldn't have tried replacing these with h:outputTexts] The facets should be named after the node type. I know we need more documentation - I just never got around to it with all of the myfaces release stuff that I was doing. I'm taking a step back from the release stuff for now so I'll try and get back to some tree2 business. Please fell free to start some docs on the site. I'm happy to answer questions. Sean
Re: myfaces 114
I used it a while ago but I think you can bypass it by just using mvn deploy (if the repos in the pom are the production locations). The main thing it does is make sure there are no SNAPSHOT refs. It will also tag your release, etc. but if you mess up, its a real PITA to start over. My suggestion is to do a search for -SNAPSHOT *anywhere* in the POM's. The only ones that should be there are for shared and core. Speaking of shared, are we going to release that one first? In the past we decided not to publicly release it on ibiblio but to make it available on the mayfaces repo on the zone since its needed for compiling from the source. Thoughts? Sean On 8/7/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Ok, so next is getting shared_203 out. Anybody used the release plugin (maven) before? Regards, Matthias On 8/5/06, Dennis Byrne [EMAIL PROTECTED] wrote: New snapshots are available here: http://people.apache.org/builds/myfaces/core-1.1.x/ Pass. Dennis Byrne The revision number in the filename is coming from the last revision on the core branch. This was built against r428968 of the shared branch, after the patch that Matthias mentioned above. Look in the 'logs' directory for the script and build log to double check. http://wiki.apache.org/myfaces/CoreRelease114 -- Wendy -- Matthias Wessendorf further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: MyFaces-1377 Minor 1.1.4 issue - [Was: IMPORTANT: Calling all committers]
+1 On 8/2/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: On 8/2/06, Mike Kienenberger [EMAIL PROTECTED] wrote: I have opened http://issues.apache.org/jira/browse/MYFACES-1377 on this. However, I've marked it priority Minor since it only generates an error message rather than breaking functionality. Since the patch is committed to head, I'm not sure what the process is for backporting it to 1.1.4 or even if it's worth backporting at this point. I am +1 on committing it to the branch as well; the last release was sorta unhappy, so with 1.1.4 we should try to get the user's trust back. What do others think? On 8/2/06, Mike Kienenberger [EMAIL PROTECTED] wrote: On 8/2/06, Mike Kienenberger [EMAIL PROTECTED] wrote: I think this issue might also affect h:dataTable since it's in the shared package: http://issues.apache.org/jira/browse/TOMAHAWK-467 I'll try testing and seeing if this is true. If so, the patch there needs to be applied, and I'll try to get to that tomorrow if no one else takes care of it by then. I've applied the patch for this against 1.1.5. However, this also needs to be applied to the Core 1.1.4 branch, or using a dataScroller with an h:dataTable is going to generate Row is not available errors whenever the dataTable doesn't have as many rows to display as the rows attribute value. 20:31:36.218 ERROR! [SocketListener0-1] org.apache.myfaces.shared_impl.renderkit.html.HtmlTableRendererBase.encodeInnerHtml(HtmlTableRendererBase.java:234) 41 Row is not available. Rowindex = 1 I'll go ahead and open a core issue on this as well and link it to the tomahawk one. -- Matthias Wessendorf further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Facelets Tomahawk
What about adding new MyFaces examples using facelets? We will need it to test tomahawk facelet support. I am currently writing such an example over at Shale (just getting it started.) It uses Shale, MyFaces, Tomahawk, Facelets, Hibernate and Spring. IMO this single example would suffice for both projects. I could use help on the shale-petstore app (in the sandbox) but feel free to create your own here if you don't think that's sufficient. Sean
Re: IMPORTANT: Calling all committers
So is there a new RC we should be testing against? I can update it with the latest branch later today perhaps. Sean On 8/3/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: @Tomahawk_1_1_4 branch: works, when you compile against the *patched* shared-203 On 8/2/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: As for the getScrolling issue, I could've sworn this worked in the latest simple examples *before* I switched in the rc core api jars. Maybe I'm wrong though ... I will try to investigate further. with 1.1.5 yes; the getScrolling is now named org_apache_myfaces_getScrolling that was committed against head (tom., core and shared) so, 1.1.4 + tomahawk 1.1.5 won't work next try is getting the 1.1.4 core (rc) + tomahawk 1.14 snapshot to work. I guess I have to apply some commits there as well -Matthias If someone beats me to the testing on this and concludes its tomahawk, please keep as blocker level severity and move it to the tomahawk project. Its still a major bug that needs to be dealt with. Sean On 8/2/06, Mike Kienenberger [EMAIL PROTECTED] wrote: On 8/2/06, Sean Schofield [EMAIL PROTECTED] wrote: We are majorly bogged down on the Core 1.1.4 release. We need *everyone* to do what they can to help get this release out the door. Please see the wiki[1] and test the release candidate there. A good start is to build the simple examples in the tomahawk HEAD and replace the myfaces core jars with the rc ones. Please file all major bugs you find in JIRA with version to fix as 1.1.4-SNAPSHOT. I've been using it in my primary project and I haven't had any issues. I noticed that you opened the getScrolling issue against core. Is this really a core issue or a tomahawk one? -- Matthias Wessendorf further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: IMPORTANT: Calling all committers
Tell me what revision the check in was so I can revert it. Then just apply to the trunk ok? Sean On 8/3/06, Mike Kienenberger [EMAIL PROTECTED] wrote: On 8/2/06, Sean Schofield [EMAIL PROTECTED] wrote: Why not apply it to 1.1.4 branch and merge it down? Eventually we need to merge everything down. My vote is to fix it once merge it the second time. But I don't know the nature of the fix so maybe I'm way off here. It's already in trunk, and I'm not enough of an svn-expert to know the best way to proceed. One thing I know I can do is reapply the patch to the 1.1.4 branch. Give me some guidance and I'll do what needs to be done.I've got tortoiseSVN and Eclipse SVN to work with.
Re: IMPORTANT: Calling all committers
I agree with Mike here. Matthias, can you explain the problem in more detail? We should fix this problem before releasing (if there's a problem to fix.) Sean On 8/3/06, Mike Kienenberger [EMAIL PROTECTED] wrote: On 8/3/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: As for the getScrolling issue, I could've sworn this worked in the latest simple examples *before* I switched in the rc core api jars. Maybe I'm wrong though ... I will try to investigate further. with 1.1.5 yes; the getScrolling is now named org_apache_myfaces_getScrolling that was committed against head (tom., core and shared) so, 1.1.4 + tomahawk 1.1.5 won't work Hold up here! Unless there's no other way to solve this, we should not be breaking behavior like this.We've been advertising that any post-1.1.3 core works with any post-1.1.3 tomahawk. Furthermore, there shouldn't be any dependencies on the MyFaces implementation from Tomahawk (otherwise it'll also break in the RI).
Re: IMPORTANT: Calling all committers
I patched the 1.1.4 branch; so now 1.1.4 core works with tomahawk 1.1.5-Snap and tomahawk 1.1.4-SNAP (after you compile it against the *patched* shared_203) Great. -Matthias Sean
Re: IMPORTANT: Calling all committers
I'm assuming you mean apply it to the branch. Sorry. That's what I meant. As for the revision, http://issues.apache.org/jira/browse/TOMAHAWK-467?page=com.atlassian.jira.plugin.ext.subversion:subversion-commits-tabpanel states 428204 I'm more than happy to learn how to do this myself rather than making you do it. If you're using windows and tortoise svn its pretty easy. Find out all of the files affected by that revision. Then view the history with tortoise. Then select the revision and say you want to update changes from that revision only. I'm also sure there's even an easier way to do it from the command line - in fact I'm pretty sure I've done it before. RANT MODE However, I think it's a backward approach to be making patches to a branch, and then porting them over at some later time to trunk. Branches should be static except when applying maintenance fixes, and those fixes should be merged over from trunk after being tested, not the other way around. As things stand, you get the worst of both worlds -- you have a branch that doesn't have the latest features combined with a trunk that doesn't have the latest bug fixes. In an ideal world, the timeframe for this would be small enough that maybe it wouldn't be a big deal, but we all know that releases take multiple days and often weeks in practice. /RANT MODE I disagree here. The branch is for code that is about to be released. If a major (and bug ridden) change is introduced after the branch it doesn't slip into the release. On the other hand, if its important to have it fixed on the core as well, you can merge down everything from the branch after you check in the fix. We just need to make a note (in the svn logs) of what revision was merged down so we can start from there when the branch is done (or the next merge is needed.) Ideally we're only sitting on the branch for a couple of weeks. Also ideally, there is no major bug like this that ends up slipping into the branch before it can be detected on the trunk. Sean
Re: IMPORTANT: Calling all committers
I understand why we want to clean up our namespaces, but is this cleanup really important enough to warrant breaking compatibility in the 1.1 releases? No. getScrolling has been used for a long time, and it's not just going to break between 1.1.3 and 1.1.4, it's going to break anyone who's using it in their own javascript. Good point. If we do decide to keep the change, it needs to be well documented in the release notes. -1 for keeping the change
Re: Facelets Tomahawk
It's that unit test vs integration test thing again. Your example will show that facelets works as an integration test, but isn't really as comprehensive as having a facelets example for every component. Yes a facelets example for every component wouldn't hurt. Also, Wendy's work with the Selenium tests on Shale looks promising. Maybe we could automate some tests of our own. Sean
Re: IMPORTANT: Calling all committers
looks like all people here are -1 on keeping (or +1 on putting it to the 1.2 branch) I'll wait until tonight (US time) and do some stuff there; Makes sense? Yes. Thanks for helping (again.) Matthias Wessendorf Sean
Re: [Tests] Tomahawk
This means that we can't release Tomahawk until the dependency is final. Shouldn't be a problem at the rate we're going these days ... Sean On 8/1/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Ok, I asked b/c of the -SNAPSHOT :) On 8/1/06, Grant Smith [EMAIL PROTECTED] wrote: I can't see any reason not to... On 7/31/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Anyone against, that I add Shale-1.0.3-SNAPSHOT to Tomahawk for testing? I just created some classes (not depending on the Jmock stuff); but I'll continue writing the tests. Thx, Matthias -- Matthias Wessendorf further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Grant Smith -- Matthias Wessendorf further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Facelets Tomahawk
Can you give an example of a class that is a problem and how you propose to fix it? I'm not terribly familiar with facelets but I was able to get tree2 working without adding special facelets packages. There were just some differences in properties and how facelets expected to find them. Sean On 8/2/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: On 8/2/06, Thomas Spiegl [EMAIL PROTECTED] wrote: I will add facelets support to MyFaces tomahawk. Here my suggestions: Tomahawk Facelets classes (TagHandlers, etc.) go to folder: tomahawk/core/src/main/java +1 package: org.apache.myfaces.custom.facelets -1 I prefere org.apache.myfaces.tomahawk.facelets Tomahawk Facelets Taglib resides in folder: tomahawk/core/src/main/resources-facelets +1 (that will include it in to META-INF/, right ?) Tomahwak will have a compile time dependency on facelets. +1 Regards Thomas -- Matthias Wessendorf further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Facelets Tomahawk
If we design our MyFaces components right, the only component classes that will need facelets tag handlers are those with method bindings. The method binding method signature for an attribute has be specified in a facelets component tag handler. Well lets make sure we do this part whenever possible. It might take a little time but I'd like to minimize the need to add extra facelets specific stuff. But, when its unavoidable, I agree with Matthias' suggetsion of o.a.t.facelets Lets create improvement issues in JIRA for each of the tomahawk components that don't support facelets out of the box. We can then assign them to ourselves if we have time to work on them. I have one in mind since I need it for a demo app I'm writing (t:popup.) Lets just be sure to check JIRA and assign to ourselves so we don't duplicate effort. Also pure jsp tags (like t:updateActionListener) also have to be rewritten as a facelets tag handlers. Ok good point. Like I said, I don't know much about facelets but what you're saying is making sense here. Sean
Re: Facelets Tomahawk
For most of the remaining problem components, it's simply a matter of taking care of the generic attributes and making them explicit html attributes like you did for tree2. OK so there's not much of a need for this new package directory but we do need it in a few limited cases right? The only component I know to be more complicated than fixing attributes (in MyFaces) or defining method bindings (in facelets tag handlers) is t:tree. The jsp tag and the component don't use the same attributes. Ok. There is the option of not supporting it but it would be nice if we could say 100% of tomahawk is facelets compatible. Sounds good. That's what I was planning on doing once someone else got the maven foundation in place. By the way, I came across the facelets maven location earlier: http://wiki.java.net/bin/view/Projects/FaceletsFAQ#Is_Facelets_in_ibiblio_or_anothe Well it seems to be on ibilio as well. This works for me: dependency groupIdcom.sun.facelets/groupId artifactIdjsf-facelets/artifactId version1.1.11/version /dependency Don't need to do anything for t:popup -- at least the following is working fine for me. tag tag-namepopup/tag-name component component-typeorg.apache.myfaces.HtmlPopup/component-type renderer-typeorg.apache.myfaces.Popup/renderer-type /component /tag Duh! I forgot to map the component in the facelet taglib. If we include this mapping in tomahawk.jar facelets will detect it automatically? I thought I remembered someone starting a config file for this purpose. If this is possible we should create such a config file once we are 100% done with facelets compatability. Sean
Re: Core 1.1.4
Already found at least one major bug (MYFACES-1376). Lets do some decent testing and make sure that at least the simple examples work properly. This was the first example I tried and it failed. I'm sure there are more. Sean On 8/2/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: On 8/1/06, Sean Schofield [EMAIL PROTECTED] wrote: OK I am doing a quick test of the core release candidate using the link from the wiki. In the meantime, should we release the shared dependency? This really needs to come first. Ideally we could release it to the myfaces internal repo for testing and then tag it. Then we can re-release the shared artifact to ibiblio after signing. ok, I just run a build to provide a RC for that. Then I think we do one last build of the core referencing the final shared dep and changing the version to final in the poms. This is just to make sure that we didn't break anything with the pom changes. Then sign and release to ibiblio. think so too From here on out I think we can keep the testing to just a few users on the dev list. I don't think we want premature copies of final aritifacts (that might not really be final) floating around. Does this make sense? If so, we can add the steps to the wiki (wanted to check here first.) Sean On 8/1/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Running with http://people.apache.org/builds/myfaces/core-1.1.x/myfaces-core-1.1.4-SNAPSHOT-bin.zip, I get no error after removing the parameter. So I'd say this problem is only with the 1.1.5 snapshot, and that the 1.1.4 release does not have this snapshot. Ok, let's get 1.1.4 out. I would have checked it earlier, but it sounded like you all knew what you were doing and what was causing it :-) We only knew that Martin committed something regarding that. -- Matthias Wessendorf further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
[jira] Created: (MYFACES-1376) getScrolling is not defined in simple tree2 example
getScrolling is not defined in simple tree2 example --- Key: MYFACES-1376 URL: http://issues.apache.org/jira/browse/MYFACES-1376 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.1.4-SNAPSHOT Reporter: sean schofield Priority: Blocker Fix For: 1.1.4-SNAPSHOT tree2NiceWrap.jsf throws a javascript error when you try to expand the node -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
IMPORTANT: Calling all committers
We are majorly bogged down on the Core 1.1.4 release. We need *everyone* to do what they can to help get this release out the door. Please see the wiki[1] and test the release candidate there. A good start is to build the simple examples in the tomahawk HEAD and replace the myfaces core jars with the rc ones. Please file all major bugs you find in JIRA with version to fix as 1.1.4-SNAPSHOT. I know everyone is busy (myself included) but a few people have been doing most of the heavy lifting for a long time now. We've added a bunch of new committers lately and we have lots of old ones who aren't doing very much to help. Lets step it up. Sean [1] http://wiki.apache.org/myfaces/CoreRelease114
Re: [Tests] Tomahawk
I know and we're nowhere near releasing tomahawk at this rate so we should be fine. On 8/2/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Craig is about to release 1.0.3 On 8/2/06, Sean Schofield [EMAIL PROTECTED] wrote: This means that we can't release Tomahawk until the dependency is final. Shouldn't be a problem at the rate we're going these days ... Sean On 8/1/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Ok, I asked b/c of the -SNAPSHOT :) On 8/1/06, Grant Smith [EMAIL PROTECTED] wrote: I can't see any reason not to... On 7/31/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Anyone against, that I add Shale-1.0.3-SNAPSHOT to Tomahawk for testing? I just created some classes (not depending on the Jmock stuff); but I'll continue writing the tests. Thx, Matthias -- Matthias Wessendorf further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Grant Smith -- Matthias Wessendorf further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
[jira] Commented: (MYFACES-1376) getScrolling is not defined in simple tree2 example
[ http://issues.apache.org/jira/browse/MYFACES-1376?page=comments#action_12425401 ] sean schofield commented on MYFACES-1376: - schedule1.jsf component is also experiencing this problem when you try to advance the calendar getScrolling is not defined in simple tree2 example --- Key: MYFACES-1376 URL: http://issues.apache.org/jira/browse/MYFACES-1376 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.1.4-SNAPSHOT Reporter: sean schofield Priority: Blocker Fix For: 1.1.4-SNAPSHOT tree2NiceWrap.jsf throws a javascript error when you try to expand the node -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MYFACES-1376) getScrolling is not defined in simple tree2 example
[ http://issues.apache.org/jira/browse/MYFACES-1376?page=all ] sean schofield updated MYFACES-1376: Status: Open (was: Patch Available) getScrolling is not defined in simple tree2 example --- Key: MYFACES-1376 URL: http://issues.apache.org/jira/browse/MYFACES-1376 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.1.4-SNAPSHOT Reporter: sean schofield Priority: Blocker Fix For: 1.1.4-SNAPSHOT tree2NiceWrap.jsf throws a javascript error when you try to expand the node -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-1376) getScrolling is not defined in simple tree2 example
[ http://issues.apache.org/jira/browse/MYFACES-1376?page=comments#action_12425406 ] sean schofield commented on MYFACES-1376: - Apparently Michael Hartman marked this as patch available but I don't see one. Changing status back to Open. getScrolling is not defined in simple tree2 example --- Key: MYFACES-1376 URL: http://issues.apache.org/jira/browse/MYFACES-1376 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.1.4-SNAPSHOT Reporter: sean schofield Priority: Blocker Fix For: 1.1.4-SNAPSHOT tree2NiceWrap.jsf throws a javascript error when you try to expand the node -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: IMPORTANT: Calling all committers
Given how the last few releases have been very embarassing we need to thoroughly test this puppy - and more then two or three people need to test it. As for the getScrolling issue, I could've sworn this worked in the latest simple examples *before* I switched in the rc core api jars. Maybe I'm wrong though ... I will try to investigate further. If someone beats me to the testing on this and concludes its tomahawk, please keep as blocker level severity and move it to the tomahawk project. Its still a major bug that needs to be dealt with. Sean On 8/2/06, Mike Kienenberger [EMAIL PROTECTED] wrote: On 8/2/06, Sean Schofield [EMAIL PROTECTED] wrote: We are majorly bogged down on the Core 1.1.4 release. We need *everyone* to do what they can to help get this release out the door. Please see the wiki[1] and test the release candidate there. A good start is to build the simple examples in the tomahawk HEAD and replace the myfaces core jars with the rc ones. Please file all major bugs you find in JIRA with version to fix as 1.1.4-SNAPSHOT. I've been using it in my primary project and I haven't had any issues. I noticed that you opened the getScrolling issue against core. Is this really a core issue or a tomahawk one?
Re: IMPORTANT: Calling all committers
Why not apply it to 1.1.4 branch and merge it down? Eventually we need to merge everything down. My vote is to fix it once merge it the second time. But I don't know the nature of the fix so maybe I'm way off here. Sean On 8/2/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Sounds good Mike! On 8/2/06, Mike Kienenberger [EMAIL PROTECTED] wrote: On 8/2/06, Mike Kienenberger [EMAIL PROTECTED] wrote: I think this issue might also affect h:dataTable since it's in the shared package: http://issues.apache.org/jira/browse/TOMAHAWK-467 I'll try testing and seeing if this is true. If so, the patch there needs to be applied, and I'll try to get to that tomorrow if no one else takes care of it by then. I've applied the patch for this against 1.1.5. However, this also needs to be applied to the Core 1.1.4 branch, or using a dataScroller with an h:dataTable is going to generate Row is not available errors whenever the dataTable doesn't have as many rows to display as the rows attribute value. 20:31:36.218 ERROR! [SocketListener0-1] org.apache.myfaces.shared_impl.renderkit.html.HtmlTableRendererBase.encodeInnerHtml(HtmlTableRendererBase.java:234) 41 Row is not available. Rowindex = 1 I'll go ahead and open a core issue on this as well and link it to the tomahawk one. -- Matthias Wessendorf further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Core 1.1.4
So Dennis, why did you blow the whistle on the RC? Was it from reading about a problem someone else had or was it b/c the TCK failed? I'm assuming you were just reporting a problem that someone else had and thought that it was present in the RC. I do agree we need to slow down and make sure everything works properly. Lets all take a deep breath and figure out what's next. I'm going to start by rereading the release wiki and adding anything I think is missing there. Sean On 8/1/06, Mike Kienenberger [EMAIL PROTECTED] wrote: Ok. That's kind of what my understanding of the behavior was, but it wasn't matching reality :) Thanks for clarifying it -- so it's definitely a bug. On 8/1/06, Dennis Byrne [EMAIL PROTECTED] wrote: I haven't said much because I don't really understand the problem. One thing that is confusing me is that the issue open appeared to be regarding a case-sensitivity issue. A little more on this. The CACHE param is there only for individuals who wish to disable it, meaning the key is not stored in app scope at startup. It will then be created on each request ( major performance hit ). I did this only because there is no guarantee that an encryption provider *must* provide a thread safe version of the key object ( making it unsafe to store in the session or the application). My experience was that a new 'org.apache.myfaces.secret.CACHE' parameter is now required in my web.xml file that was previously not required, and it's unclear to me from the documentation what this does or why it's required. This parameter should never be required by the application developer. Dennis Byrne
Re: Core 1.1.4
OK I am doing a quick test of the core release candidate using the link from the wiki. In the meantime, should we release the shared dependency? This really needs to come first. Ideally we could release it to the myfaces internal repo for testing and then tag it. Then we can re-release the shared artifact to ibiblio after signing. Then I think we do one last build of the core referencing the final shared dep and changing the version to final in the poms. This is just to make sure that we didn't break anything with the pom changes. Then sign and release to ibiblio. From here on out I think we can keep the testing to just a few users on the dev list. I don't think we want premature copies of final aritifacts (that might not really be final) floating around. Does this make sense? If so, we can add the steps to the wiki (wanted to check here first.) Sean On 8/1/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Running with http://people.apache.org/builds/myfaces/core-1.1.x/myfaces-core-1.1.4-SNAPSHOT-bin.zip, I get no error after removing the parameter. So I'd say this problem is only with the 1.1.5 snapshot, and that the 1.1.4 release does not have this snapshot. Ok, let's get 1.1.4 out. I would have checked it earlier, but it sounded like you all knew what you were doing and what was causing it :-) We only knew that Martin committed something regarding that. -- Matthias Wessendorf further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
[jira] Created: (MYFACES-1375) Excessive warnings when using Tomahawk with RI
Excessive warnings when using Tomahawk with RI -- Key: MYFACES-1375 URL: http://issues.apache.org/jira/browse/MYFACES-1375 Project: MyFaces Core Issue Type: Improvement Affects Versions: 1.1.5-SNAPSHOT Environment: JSF 1.2 RI Reporter: sean schofield I'm getting this stack trace: WARNING: phase(RENDER_RESPONSE 6,[EMAIL PROTECTED]) threw exception: java.lang.NoSuchMethodError: org.apache.myfaces.renderkit.html.util.DummyFormUtils.isWriteDummyForm(Ljavax/faces/context/FacesContext;)Z org.apache.myfaces.renderkit.html.util.DummyFormUtils.isWriteDummyForm(Ljavax/faces/context/FacesContext;)Z org.apache.myfaces.renderkit.html.util.ExtensionsPhaseListener.writeCodeBeforeBodyEnd(ExtensionsPhaseListener.java:124) I thought we were getting rid of the DummyForm stuff. Is it back? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Core 1.1.4
What's going on with this? Last I heard there was at least one major bug? Can somebody summarize the status and likely timetable for getting this out? This should be everyone's top MyFaces priority. If you've got other personal stuff to do - fine - but this should be our top priority otherwise. Sean
Re: Core 1.1.4
So if I'm reading things correctly, the bug is MYFACES-1368 and its due to a check-in by Martin way back in early July. Therefore it exists in both the trunk and the branch. If this is the case, by all means lets roll it back and get on with things! Anyone object to this? As for the other bugs marked as fix in 1.1.4-SNAPSHOT, I take it those are just ones where users are suggesting we fix right away? I will change them to 1.1.5-SNAPSHOT unless anyone feels they relate to this upcoming release in a critical way. Sean On 7/31/06, Dennis Byrne [EMAIL PROTECTED] wrote: Hi Sean, You are correct. There is one last bug. My suggestion would be to roll back the bugged commit on the branch. I will be happy to run the TCK suite if were done. As far as trunk goes, perhaps this bug can be fixed in time for 1.1.5 . I strongly recommend adding to the unit test suite for any changes done to MyFaces state management. Dennis Byrne -Original Message- From: Sean Schofield [mailto:[EMAIL PROTECTED] Sent: Monday, July 31, 2006 01:23 PM To: 'MyFaces Development' Subject: Core 1.1.4 What's going on with this? Last I heard there was at least one major bug? Can somebody summarize the status and likely timetable for getting this out? This should be everyone's top MyFaces priority. If you've got other personal stuff to do - fine - but this should be our top priority otherwise. Sean
[jira] Commented: (MYFACES-1368) Fix case sensitivity for context params
[ http://issues.apache.org/jira/browse/MYFACES-1368?page=comments#action_12424595 ] sean schofield commented on MYFACES-1368: - According to the SVN logs these changes were made July 4th which was after the June 21st date where matzew created the branch. Fix case sensitivity for context params --- Key: MYFACES-1368 URL: http://issues.apache.org/jira/browse/MYFACES-1368 Project: MyFaces Core Issue Type: Bug Components: JSR-127 Affects Versions: 1.1.4-SNAPSHOT Environment: 1.1.4 branch, 1.1.5 head Reporter: Dennis Byrne Fix For: 1.1.4-SNAPSHOT http://mail-archives.apache.org/mod_mbox/myfaces-commits/200607.mbox/[EMAIL PROTECTED] Fix should include unit tests. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Core 1.1.4
Ok the classes mentioned in MYFACES-1368 don't seem to be in the 1.1.4 branch. So something is wrong here. Sean On 7/31/06, Dennis Byrne [EMAIL PROTECTED] wrote: you mean Martin's commit? Or what? Yes, obviously it is nicer to have uniform configuration parameters, but I do not feel this should hold up a release. We should have a unit test for each new commit ... during the complete refactoring I am doing on Trinidad, I am *very*! happy to have such a huge amount of test cases. That make my refactoring life very comfortalbe! There was a time when I didn't feel this way. The spec means static requirements, so far less need for testing. But today core is a field of landmines. The relationship between cost and quality is exponential on every project, and we are definetly paying a lot these days in order to squeeze out the last 5% of defects in this piece of software. Four of five fixes result in another bug. Dennis Byrne -Matthias Dennis Byrne -Original Message- From: Sean Schofield [mailto:[EMAIL PROTECTED] Sent: Monday, July 31, 2006 01:23 PM To: 'MyFaces Development' Subject: Core 1.1.4 What's going on with this? Last I heard there was at least one major bug? Can somebody summarize the status and likely timetable for getting this out? This should be everyone's top MyFaces priority. If you've got other personal stuff to do - fine - but this should be our top priority otherwise. Sean -- Matthias Wessendorf further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Core 1.1.4
Ugg. I had a feeling this was the problem. On 7/31/06, Dennis Byrne [EMAIL PROTECTED] wrote: http://svn.apache.org/viewvc/myfaces/core/branches/1_1_4/impl/pom.xml?view=markup It's pointed to the snap shot. groupIdorg.apache.myfaces.shared/groupId artifactIdmyfaces-shared-impl/artifactId version2.0.3-SNAPSHOT/version Dennis Byrne -Original Message- From: Sean Schofield [mailto:[EMAIL PROTECTED] Sent: Monday, July 31, 2006 02:32 PM To: 'MyFaces Development' Subject: Re: Core 1.1.4 Ok the classes mentioned in MYFACES-1368 don't seem to be in the 1.1.4 branch. So something is wrong here. Sean On 7/31/06, Dennis Byrne [EMAIL PROTECTED] wrote: you mean Martin's commit? Or what? Yes, obviously it is nicer to have uniform configuration parameters, but I do not feel this should hold up a release. We should have a unit test for each new commit ... during the complete refactoring I am doing on Trinidad, I am *very*! happy to have such a huge amount of test cases. That make my refactoring life very comfortalbe! There was a time when I didn't feel this way. The spec means static requirements, so far less need for testing. But today core is a field of landmines. The relationship between cost and quality is exponential on every project, and we are definetly paying a lot these days in order to squeeze out the last 5% of defects in this piece of software. Four of five fixes result in another bug. Dennis Byrne -Matthias Dennis Byrne -Original Message- From: Sean Schofield [mailto:[EMAIL PROTECTED] Sent: Monday, July 31, 2006 01:23 PM To: 'MyFaces Development' Subject: Core 1.1.4 What's going on with this? Last I heard there was at least one major bug? Can somebody summarize the status and likely timetable for getting this out? This should be everyone's top MyFaces priority. If you've got other personal stuff to do - fine - but this should be our top priority otherwise. Sean -- Matthias Wessendorf further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Core 1.1.4
I guess there was no branch made for the shared project at the same time that the core branched? If so we need to make a branch now (retroactively) and make sure it does not include the problematic code. Then change the dependency in the core pom. Generaly when we say master pom we mean the artifact produced by myfaces/maven/master-pom. That should be left alone. As for snapshots, they can stay -SNAPSHOT while we do light testing. But then we should change them to final versions once these artifacts are released. Basically we can release the myfaces-shared artifact as soon as we test that this is all working. Sean On 7/31/06, Dennis Byrne [EMAIL PROTECTED] wrote: I think this means the scope of 1368 should be changed to 1.1.5 release, core 1.1.4 branch needs have the poms changed, and core 1.1.4 needs to be retested. Should SNAPSHOT be removed from the master pom ? http://svn.apache.org/viewvc/myfaces/core/branches/1_1_4/pom.xml?view=markup Dennis Byrne -Original Message- From: Dennis Byrne [mailto:[EMAIL PROTECTED] Sent: Monday, July 31, 2006 03:01 PM To: 'MyFaces Development' Subject: Re: Core 1.1.4 http://svn.apache.org/viewvc/myfaces/core/branches/1_1_4/impl/pom.xml?view=markup It's pointed to the snap shot. groupIdorg.apache.myfaces.shared/groupId artifactIdmyfaces-shared-impl/artifactId version2.0.3-SNAPSHOT/version Dennis Byrne -Original Message- From: Sean Schofield [mailto:[EMAIL PROTECTED] Sent: Monday, July 31, 2006 02:32 PM To: 'MyFaces Development' Subject: Re: Core 1.1.4 Ok the classes mentioned in MYFACES-1368 don't seem to be in the 1.1.4 branch. So something is wrong here. Sean On 7/31/06, Dennis Byrne [EMAIL PROTECTED] wrote: you mean Martin's commit? Or what? Yes, obviously it is nicer to have uniform configuration parameters, but I do not feel this should hold up a release. We should have a unit test for each new commit ... during the complete refactoring I am doing on Trinidad, I am *very*! happy to have such a huge amount of test cases. That make my refactoring life very comfortalbe! There was a time when I didn't feel this way. The spec means static requirements, so far less need for testing. But today core is a field of landmines. The relationship between cost and quality is exponential on every project, and we are definetly paying a lot these days in order to squeeze out the last 5% of defects in this piece of software. Four of five fixes result in another bug. Dennis Byrne -Matthias Dennis Byrne -Original Message- From: Sean Schofield [mailto:[EMAIL PROTECTED] Sent: Monday, July 31, 2006 01:23 PM To: 'MyFaces Development' Subject: Core 1.1.4 What's going on with this? Last I heard there was at least one major bug? Can somebody summarize the status and likely timetable for getting this out? This should be everyone's top MyFaces priority. If you've got other personal stuff to do - fine - but this should be our top priority otherwise. Sean -- Matthias Wessendorf further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Core 1.1.4
Sorry. Missed the bit about the shared branch in the wiki. I thought Matthias had told me that he created it. Sean On 7/31/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 7/31/06, Sean Schofield [EMAIL PROTECTED] wrote: I guess there was no branch made for the shared project at the same time that the core branched? If so we need to make a branch now (retroactively) and make sure it does not include the problematic code. Then change the dependency in the core pom. This page is intended to capture information about the release, including what branches were made and when: http://wiki.apache.org/myfaces/CoreRelease114 As Matthias mentioned, he branched shared and core at the same time. But that was on June 21, and the commit mentioned on MYFACES-1368 was on July 4th. It can't be in the branch unless it was merged in. We also have a STATUS document which lists the trunks and active branches: http://svn.apache.org/repos/asf/myfaces/current/STATUS.txt If anything is missing, please add it. -- Wendy
Re: Core 1.1.4
OK I missed this one: myfaces/shared/trunk/core/src/main/java/org/apache/myfaces/shared/util/StateUtils.java If we revert this change do we think this will fix the problem? I can certainly take care of that ... Sean On 7/31/06, Sean Schofield [EMAIL PROTECTED] wrote: Sorry. Missed the bit about the shared branch in the wiki. I thought Matthias had told me that he created it. Sean On 7/31/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 7/31/06, Sean Schofield [EMAIL PROTECTED] wrote: I guess there was no branch made for the shared project at the same time that the core branched? If so we need to make a branch now (retroactively) and make sure it does not include the problematic code. Then change the dependency in the core pom. This page is intended to capture information about the release, including what branches were made and when: http://wiki.apache.org/myfaces/CoreRelease114 As Matthias mentioned, he branched shared and core at the same time. But that was on June 21, and the commit mentioned on MYFACES-1368 was on July 4th. It can't be in the branch unless it was merged in. We also have a STATUS document which lists the trunks and active branches: http://svn.apache.org/repos/asf/myfaces/current/STATUS.txt If anything is missing, please add it. -- Wendy
Re: Core 1.1.4
According to Wendy (and the wiki) the shared version was created explicitly for the 1.1.4 core. You can't just roll back the shared dependency unless you are 100% sure there were no changes to the shared branch that were intended for 1.1.4. Also, as you mentioned, we need a unit test for this to see if whatever we do fixes things. Care to write one? Or maybe you can at least elaborate on the bug description in JIRA so someone else can write one. I just know the revision that you think broke things. I don't know what the problem is. Sean On 7/31/06, Dennis Byrne [EMAIL PROTECTED] wrote: OK I missed this one: Hi Sean - missed this how? myfaces/shared/trunk/core/src/main/java/org/apache/myfaces/shared/util/StateUtils.java If we revert this change do we think this will fix the problem? I can certainly take care of that ... I am fairly sure reverting this will fix 1368, but I do not see how that should only affect anything other than trunk once the pom in the 1.1.4 branch is pointed to the correct shared version. Sean On 7/31/06, Sean Schofield [EMAIL PROTECTED] wrote: Sorry. Missed the bit about the shared branch in the wiki. I thought Matthias had told me that he created it. Sean On 7/31/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 7/31/06, Sean Schofield [EMAIL PROTECTED] wrote: I guess there was no branch made for the shared project at the same time that the core branched? If so we need to make a branch now (retroactively) and make sure it does not include the problematic code. Then change the dependency in the core pom. This page is intended to capture information about the release, including what branches were made and when: http://wiki.apache.org/myfaces/CoreRelease114 As Matthias mentioned, he branched shared and core at the same time. But that was on June 21, and the commit mentioned on MYFACES-1368 was on July 4th. It can't be in the branch unless it was merged in. We also have a STATUS document which lists the trunks and active branches: http://svn.apache.org/repos/asf/myfaces/current/STATUS.txt If anything is missing, please add it. -- Wendy
Re: Can't build Tomahawk. Unit test is failing.
By the way, the test worked this morning so it would seem to be a timezone or daylight savings problem. Test failed at 11:00 ESDT last night. Sean On 7/28/06, Sean Schofield [EMAIL PROTECTED] wrote: I recently tried to rebuild from scratch and I can't build Tomahawk now. The UserDataTest is failing for me. Test set: org.apache.myfaces.custom.date.UserDataTest --- Tests run: 12, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.047 sec FAILURE! testParseGivesCorrectDateWhenValidDataIsEnteredForTypeDate(org.apache.myfaces.custom.date.UserDataTest) Time elapsed: 0 sec FAILURE! junit.framework.ComparisonFailure: expected:20... but was:19... at junit.framework.Assert.assertEquals(Assert.java:81) at junit.framework.Assert.assertEquals(Assert.java:87) at org.apache.myfaces.custom.date.UserDataTest.testParseGivesCorrectDateWhenValidDataIsEnteredForTypeDate(UserDataTest.java:66) I noticed Mario was also having problems with this test and made some changes. @Mario: I will try to rsolve it tomorrow but if you can look at it in the meantime that would be hlepful. Sean
Can't build Tomahawk. Unit test is failing.
I recently tried to rebuild from scratch and I can't build Tomahawk now. The UserDataTest is failing for me. Test set: org.apache.myfaces.custom.date.UserDataTest --- Tests run: 12, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.047 sec FAILURE! testParseGivesCorrectDateWhenValidDataIsEnteredForTypeDate(org.apache.myfaces.custom.date.UserDataTest) Time elapsed: 0 sec FAILURE! junit.framework.ComparisonFailure: expected:20... but was:19... at junit.framework.Assert.assertEquals(Assert.java:81) at junit.framework.Assert.assertEquals(Assert.java:87) at org.apache.myfaces.custom.date.UserDataTest.testParseGivesCorrectDateWhenValidDataIsEnteredForTypeDate(UserDataTest.java:66) I noticed Mario was also having problems with this test and made some changes. @Mario: I will try to rsolve it tomorrow but if you can look at it in the meantime that would be hlepful. Sean
Re: JUnit 4.0
+1 on waiting if that's the case. On 7/21/06, Bruno Aranda [EMAIL PROTECTED] wrote: I have not found a solution for Maven 2 with JUnit4. The adapter does not work. You can run it on IDEs (such as Idea), though. JUnit4 is really nice, but I guess we should wait until it is integrated with Maven or have an alternative solution... Bruno On 7/21/06, Sean Schofield [EMAIL PROTECTED] wrote: I believe I read that there is some kind of adapter for IDE's. Perhaps the same adapter can be used for maven testing? Sean On 7/21/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 7/21/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: since JSAF 1.2 needs Java5 I guess it is good to integrated JUnit 4.0 Any vetos? We already integrated Shale-test-1.0.3 for JMock based testing. As far as I know, Maven 2 (Surefire) does not yet support JUnit 4.0, so we would have to find another way to run the tests. See: http://jira.codehaus.org/browse/SUREFIRE-31 -- Wendy
Re: Next Step ( was Re: Testing for CoreRelease114 )
That doesn't really answer Wendy's question about where is the issue in JIRA ... Sean On 7/21/06, Dennis Byrne [EMAIL PROTECTED] wrote: What is a 'final RC' ? At this point, we've asked both the dev and user lists to test snapshots built from the branch, and Dennis has run the TCK against one. We have to go through a round of fix and retest on the 1.1.4 branch. This week Mike noticed problems in the core; Matt and I voted to postpone the release. Dennis Byrne
Re: Next Step ( was Re: Testing for CoreRelease114 )
There's more to it than that... take a look at the 'release procedure' wiki page. Apparently, Maven will change the version numbers and do the tags. (I'm not entirely sure I trust it against the live repo, but Sean has done it before.) The jars need to be deployed to a staging repo (on the zone?), and the -src and -bin assemblies need to be built. Maven will change the version numbers but you need to do plenty of manual changing as well. One thing that sometimes gets forgotten until you try to release is that the shared stuff also needs to be changed from SNAPSHOT to final. Its hidden in the middle of the POM where you might not see it. We'll need to change JIRA and create some release notes. You definitely want to post a final RC for people to test. Especially since changing the Maven versions might accidentally break something. It wouldn't hurt to do a final TCK against it either but I'm not volunteering. Wendy Sean
Re: Suggested tool for screen shot?
We're generally using PNG but I suppose JPEG or GIF is acceptable. Sean On 7/17/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: gimp ? :) On 7/17/06, Paul Spencer [EMAIL PROTECTED] wrote: The wiki mentions including a screen shot in the documentation, http://wiki.apache.org/myfaces/promotion. Is their a suggest tool to use and format (JPEG/GIF)? Paul Spencer -- Matthias Wessendorf further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: MyFaces zone used for Shale
I said that? Well I'm a little busy at the moment so go ahead. One thing you should note is that the zone is using JDK 1.5 to build right now. We may want to change to JDK 1.4 since both Shale and MyFaces profess to be compatible with that version. This will help prevent last minute JDK 1.5 issues when we go to build the official release. Sean On 7/19/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: any update on that? I can't see the Shale stuff on the MyFaces zone. As mentioned before, I'll do it, but you mailed you are working on it. -Matthias On 7/14/06, Mike Kienenberger [EMAIL PROTECTED] wrote: I'm ok with it. On 7/14/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hey folks, any issue in beeing host for Shale's continuum build? I'd like to add Shale to our zone -- Forwarded message -- From: Sean Schofield [EMAIL PROTECTED] Date: Jul 14, 2006 10:14 AM Subject: Re: shale-test build failure To: dev@shale.apache.org There is no shale zone yet. For now we can use either Struts or MyFaces zone. MyFaces zone might make sense b/c it also has its own repo for newly released artifacts (before they make it to ibiblio?) Should we make inquiries on the myfaces-dev list asking if its ok to piggy back on the MyFaces zone for now? Sean On 7/13/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: fixed btw. where is the continuum zone for shale ? -Matt -- Matthias Wessendorf further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Fwd: New location for Maven repositories on people.apache.org
Probably everyone already saw this but this obviously affects our project. Its interesting that there will one day be an official ASF maven repository. Sean -- Forwarded message -- From: Henri Yandell [EMAIL PROTECTED] Date: Jul 18, 2006 12:14 AM Subject: New location for Maven repositories on people.apache.org To: repository@apache.org Cc: [EMAIL PROTECTED] (Please reply to repository@apache.org and ensure you drop the Cc to [EMAIL PROTECTED]) The maven repositories on people.apache.org can now be found at the following paths: /www/people.apache.org/repo/m1-snapshot-repository /www/people.apache.org/repo/m2-snapshot-repository /www/people.apache.org/repo/m1-ibiblio-rsync-repository /www/people.apache.org/repo/m2-ibiblio-rsync-repository (previous paths were: /www/people.apache.org/repository /www/people.apache.org/maven-snapshot-repository /www/www.apache.org/dist/java-repository /www/www.apache.org/dist/maven-repository ) Apart from fixing up the previously random names, this moves the repositories for syncing to ibiblio (currently a manual task that Carlos Sanchez Gonzalez (carlos) is taking care of) out of the ASF mirror directories. One important change that this leads to is that you NO LONGER NEED TO DELETE from the ibibilio rsync repositories. These will one day be the ASF Maven repository once we've figured out how we can handle hosting that bandwidth wise. For the snapshot repositories, there are currently symlinks in place so that the various CI systems that deploy to them don't fall over. Please update these and let us know at repository@apache.org that you're pointing to the new path. Thanks, Hen
Re: MyFaces zone used for Shale
FYI this is just until Shale gets its own zone. There's a lot of work to do right now with other stuff so we'd rather not set up a new zone on top of that. Sean On 7/14/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: ok, cool :) more time for JSF 1.2 for me ;) -Matt On 7/14/06, Mike Kienenberger [EMAIL PROTECTED] wrote: I'm ok with it. On 7/14/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hey folks, any issue in beeing host for Shale's continuum build? I'd like to add Shale to our zone -- Forwarded message -- From: Sean Schofield [EMAIL PROTECTED] Date: Jul 14, 2006 10:14 AM Subject: Re: shale-test build failure To: dev@shale.apache.org There is no shale zone yet. For now we can use either Struts or MyFaces zone. MyFaces zone might make sense b/c it also has its own repo for newly released artifacts (before they make it to ibiblio?) Should we make inquiries on the myfaces-dev list asking if its ok to piggy back on the MyFaces zone for now? Sean On 7/13/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: fixed btw. where is the continuum zone for shale ? -Matt -- Matthias Wessendorf further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: [VOTE] Move s:form to tomahawk
A component that doesn't work with both implementations is simply broken. Instead of relying on help from a JSF implementation, it should be redesigned to include its own help. I don't think there would be many +1 votes for releasing new components that depend on the MyFaces implementation. I also agree with your earlier point about one or two components that don't work with RI spoils the reputation/perception of the entire component set. Craig Sean
Re: [VOTE] Move s:form to tomahawk
To sum up my point: * Its nothing bad to move now and document its not compatible to RI * But, as soon as possible we should have a look at making form/command* RI compatible So do we have a definitive answer on whether this works with the RI? If not, then I'm -1 for promotion. We have had too many sloppy releases and confusion lately. It can be used in the sandbox just as easily as it can be used in tomahawk. IMO if its not ready to work with the RI then its not ready to leave the sandbox. I don't know the particulars of this component but this is my general feeling about any sandbox component. Mario Sean
Re: [VOTE] Move s:form to tomahawk
Ok reading the end of the thread now it seems this has been addressed? Sean On 7/15/06, Sean Schofield [EMAIL PROTECTED] wrote: To sum up my point: * Its nothing bad to move now and document its not compatible to RI * But, as soon as possible we should have a look at making form/command* RI compatible So do we have a definitive answer on whether this works with the RI? If not, then I'm -1 for promotion. We have had too many sloppy releases and confusion lately. It can be used in the sandbox just as easily as it can be used in tomahawk. IMO if its not ready to work with the RI then its not ready to leave the sandbox. I don't know the particulars of this component but this is my general feeling about any sandbox component. Mario Sean
Re: [VOTE] Move s:form to tomahawk
I agree with Mike on both points. On 7/14/06, Mike Kienenberger [EMAIL PROTECTED] wrote: On 7/14/06, Martin Marinschek [EMAIL PROTECTED] wrote: moving s:form has nothing to do with RI compatibility - we remain as compatible as before. So let me reopen the vote, s:form is well documented (example wouldn't help much), and it should be ok to move it to tomahawk. Has s:form been tested with the RI yet? (It's one of our promotion requirements.) Also, I think an example should still be provided even if it's trivial right now. Future expansion on the s:form tag may not be trivial.
