Re: [Vote] Java 5 as minimum JDK requirement
Peter Hunsberger wrote: On 8/15/06, Ralph Goers [EMAIL PROTECTED] wrote: Peter Hunsberger wrote: Sorry, in my book that's not a valid reason. I think it is inappropriate for you to judge whether his reason is valid or not. If one does not view a veto as valid then one has to challenge it. To do otherwise would not be taking your position as a committer seriously. His veto was challenged. A reason was stated. Now if the reason for the veto was the moon is not in alignment with the stars it would be reasonable to state that the reason isn't valid. But the reason given was nothing of the kind. That doesn't mean you can't try to convince him to change his mind using the two paragraphs that followed. But the implication of the statement is that you don't recognize his -1 as being valid, when in fact it is. You simply don't agree with it. Furthermore, his veto won't be overturned by such a statement. Although I agree with your argument below, I'm also not in favor of questioning someone endlessly about a veto. Ralph, I'm trying to be fair and ensure that Joerg has a real chance to make his concerns known and that I'm not missing something. Joerg did have a chance to make his concerns known and he did so. You disagreed with his opinion. That's fine. I'm simply making a point that you should have left the sentence with that's not a valid reason out. To me, it sounds like a put down and that you won't recognize his veto unless he comes up with a reason more to your liking. Again, I don't happen to agree with his opinion either for much the same reasons you stated. But from what I understand of the rules on vetoing he has met his obligation and doesn't have to respond further if he doesn't choose to. Ralph
Re: [Vote] Java 5 as minimum JDK requirement
Ralph Goers wrote:
But from what I understand of the rules on vetoing
he has met his obligation and doesn't have to respond further if he
doesn't choose to.
I agree, except that he has to provide information *when* he thinks that we can
switch to Java 5 (see Jason's mail). Otherwise we have to discuss this over and
over again.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Vetoing (was [Result] [Vote] Java 5 as minimum JDK requirement)
Daniel Fagerstrom wrote: Now something about vetoing: According to http://www.apache.org/foundation/how-it-works.html#management The rules require that a negative vote includes an alternative proposal or a detailed explanation of the reasons for the negative vote. The community then tries to gather consensus on an alternative proposal that resolves the issue. In the great majority of cases, the concerns leading to the negative vote can be addressed. This process is called consensus gathering and we consider it a very important indication of a healthy community. To me it seem to put a lot of emphasis on reaching a consensus. Right now we have a veto that most of the community don't agree with. That is far away from consensus and is IMO _not_ an acceptable situation from a community health POV. This means that we have to continue to work until we find a solution that we can get a consensus around. In this I absolutely agree. As Reinhard reminded me vetoing is something that is very serious and should be used sparingly. From this standpoint I think we should be even more specific than the first sentence. I would reword it to read The rules require that a negative vote includes a detailed explanation of the reasons for the negative vote and an alternative proposal or a statement defining what would be required for the negative vote to be rescinded Ralph
Re: [Vote] Java 5 as minimum JDK requirement
Reinhard Poetz wrote: Ralph Goers wrote: But from what I understand of the rules on vetoing he has met his obligation and doesn't have to respond further if he doesn't choose to. I agree, except that he has to provide information *when* he thinks that we can switch to Java 5 (see Jason's mail). Otherwise we have to discuss this over and over again. From the consensus building perspective, that would be appropriate. But please read my other email on vetoing. Perhaps in the future we can build this into the process. Ralph
Re: Re: [Vote] Java 5 as minimum JDK requirement
If one does not view a veto as valid then one has to challenge it. To do otherwise would not be taking your position as a committer seriously. His veto was challenged. A reason was stated. Now if the reason for the veto was the moon is not in alignment with the stars it would be reasonable to state that the reason isn't valid. But the reason given was nothing of the kind. That doesn't mean you can't try to convince him to change his mind using the two paragraphs that followed. But the implication of the statement is that you don't recognize his -1 as being valid, when in fact it is. You simply don't agree with it. I think you are simplifying this situation a bit... Let's say I am working for company A. Company A has a policy to only use really stable and proven software. Don't change if you don't have to. Basically they are still using JDK 1.3. I am a PMC member of an OS project the company is using. Now is the non-upgrade policy of that company A a valid reason for the individual PMC member to veto the upgrade of the JDK requirement for the OS project? ...now I am curious cheers -- Torsten
Re: [Vote] Java 5 as minimum JDK requirement
Torsten Curdt wrote: I think you are simplifying this situation a bit... Let's say I am working for company A. Company A has a policy to only use really stable and proven software. Don't change if you don't have to. Basically they are still using JDK 1.3. I am a PMC member of an OS project the company is using. Now is the non-upgrade policy of that company A a valid reason for the individual PMC member to veto the upgrade of the JDK requirement for the OS project? ...now I am curious Well, one implication of where you are going with this is, Is it appropriate to vote according to your employer's needs. My answer to that is, yes. In fact, I'm certain that it happens all the time. If you are a consultant who works for various people at various times you will continually be adding features each of your employer's needs. I see nothing wrong in using your real world experience to influence your votes. What is not OK is for you to be directed by your employer on how to vote on issues. Now, in the scenario you provided it could be (and should be) argued that the PMC member is not acting appropriately as an individual. But you wouldn't necessarily know that depending on how the justification for the veto is made. With the current policy, this PMC member would be required to state their objection. It is implied that they are also supposed to help find an alternative proposal that can be agreed upon. But it may never really be obvious that the driving factor is the employer's policy. However, using a policy that says that to veto an upgrade I have to either a) provide an alternative or b) provide a statement as to what would be required to rescind the veto would put this person in an awkward position. Clearly they can't provide an alternative. So what would their statement be - We can upgrade when my employer says its OK? That, clearly, is a violation of policy. OTOH, what if the statement is It is OK to upgrade when BEA and IBM both have versions that support version nnn of XYZ and those versions have been available for at least a year? I would argue that this moves from the category of voting on code modification to voting on procedure, in which case majority rules and the veto can be ignored if the majority does not agree. Ralph
Re: [Result] [Vote] Java 5 as minimum JDK requirement
Hi, Daniel Fagerstrom wrote: To summarize how I understand the situation: Joerg's main reason for the veto against using Java 5 in Cocoon 2.2 is that we would risk losing some of our user base. I would be happier hearing this argument after a poll of the user list to see how many people: a) require a Java 1.4 version of Cocoon 2.2 b) require a Java 1.5 version of Cocoon 2.2 There's a potential user base we would lose if we don't move forward. Damned if we do, damned if we don't ;-) It's a question of picking which is least damaging to the project as a whole, considering all existing and potential users. Thanks, Andrew. -- Andrew Savory, Managing Director, Luminas Limited Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135 Web: http://www.luminas.co.uk/ Orixo alliance: http://www.orixo.com/
Re: [Result] [Vote] Java 5 as minimum JDK requirement
Andrew Savory skrev: Hi, Daniel Fagerstrom wrote: To summarize how I understand the situation: Joerg's main reason for the veto against using Java 5 in Cocoon 2.2 is that we would risk losing some of our user base. I would be happier hearing this argument after a poll of the user list to see how many people: a) require a Java 1.4 version of Cocoon 2.2 b) require a Java 1.5 version of Cocoon 2.2 There's a potential user base we would lose if we don't move forward. Damned if we do, damned if we don't ;-) It's a question of picking which is least damaging to the project as a whole, considering all existing and potential users. Already done by Reinhard, see http://marc.theaimsgroup.com/?t=11552024823r=1w=2. This far 9 users have answered, all of them support Java 5 in Cocoon 2.2 /Daniel
[jira] Commented: (COCOON-1863) Save form model with empty fields: Binding model to document fails
[ http://issues.apache.org/jira/browse/COCOON-1863?page=comments#action_12428376 ] Feliciano Borrego commented on COCOON-1863: --- Is the same Issue 1687 reopen by Marc Portier: http://issues.apache.org/jira/browse/COCOON-1687 Save form model with empty fields: Binding model to document fails -- Key: COCOON-1863 URL: http://issues.apache.org/jira/browse/COCOON-1863 Project: Cocoon Issue Type: Bug Components: Blocks: Forms Affects Versions: 2.1.9 Reporter: Feliciano Borrego In the Cocoon example samples/blocks/forms/form2xml.flow, when submit the form with the fields IP adress, phone number and all contacts fields empty, in Cocoon 2.1.8 the XML is: data wrapper context info email boolBindingWorks=false[EMAIL PROTECTED]/email number value=3/ choose value=true/ phone cntr= zone/ number/ /phone /info ipaddress changed=true/ birthday1960-04-10/birthday drinks drinkJupiler/drinkdrinkHoegaarden/drink/drinks contacts contact id=1 row-state=original firstname/ lastname/ phone nr=/ email/ /contact contact id=2 row-state=original firstname/ lastname/ phone nr=/ email/ /contact /contacts /context /wrapper /data Therefore in Cocoon 2.1.9 the XML result is: data wrapper context info email boolBindingWorks=false[EMAIL PROTECTED]/email number value=3/ choose value=false/ phone /phone /info birthday1960-04-10/birthday drinks drinkJupiler/drinkdrinkLeffe/drink/drinks contacts contact id=1 row-state=original phone/ /contact contact id=2 row-state=original phone/ /contact /contacts /context /wrapper /data The Simple XML Binding and Bean Binding examples works fine. -- 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] Closed: (COCOON-1863) Save form model with empty fields: Binding model to document fails
[ http://issues.apache.org/jira/browse/COCOON-1863?page=all ] Feliciano Borrego closed COCOON-1863. - Resolution: Duplicate http://issues.apache.org/jira/browse/COCOON-1687 Save form model with empty fields: Binding model to document fails -- Key: COCOON-1863 URL: http://issues.apache.org/jira/browse/COCOON-1863 Project: Cocoon Issue Type: Bug Components: Blocks: Forms Affects Versions: 2.1.9 Reporter: Feliciano Borrego In the Cocoon example samples/blocks/forms/form2xml.flow, when submit the form with the fields IP adress, phone number and all contacts fields empty, in Cocoon 2.1.8 the XML is: data wrapper context info email boolBindingWorks=false[EMAIL PROTECTED]/email number value=3/ choose value=true/ phone cntr= zone/ number/ /phone /info ipaddress changed=true/ birthday1960-04-10/birthday drinks drinkJupiler/drinkdrinkHoegaarden/drink/drinks contacts contact id=1 row-state=original firstname/ lastname/ phone nr=/ email/ /contact contact id=2 row-state=original firstname/ lastname/ phone nr=/ email/ /contact /contacts /context /wrapper /data Therefore in Cocoon 2.1.9 the XML result is: data wrapper context info email boolBindingWorks=false[EMAIL PROTECTED]/email number value=3/ choose value=false/ phone /phone /info birthday1960-04-10/birthday drinks drinkJupiler/drinkdrinkLeffe/drink/drinks contacts contact id=1 row-state=original phone/ /contact contact id=2 row-state=original phone/ /contact /contacts /context /wrapper /data The Simple XML Binding and Bean Binding examples works fine. -- 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: (COCOON-1687) [PATCH] JXPATHBinding : when saving the form, remove xml elements if the value of the widget is null
[ http://issues.apache.org/jira/browse/COCOON-1687?page=comments#action_12428378 ] Feliciano Borrego commented on COCOON-1687: --- I closed the issue 1863: http://issues.apache.org/jira/browse/COCOON-1863 [PATCH] JXPATHBinding : when saving the form, remove xml elements if the value of the widget is null Key: COCOON-1687 URL: http://issues.apache.org/jira/browse/COCOON-1687 Project: Cocoon Issue Type: Bug Components: Blocks: Forms Affects Versions: 2.1.8, 2.2-dev (Current SVN), 2.1.7 Reporter: Philippe Gassmann Attachments: ValueJXPathBinding.java.patch When a form is saved using a JXPathBinding, the xml elements that correspond to null widget values must be removed. Here is our problem : we have a form containing a date widget that is not mandatory, 1. the user wants to set a value to this widget ex 2005/05/09 2. the user save this form 3. the user does not want the date to be set anymore (why ? why not !) 4. the user edit the value removing its content (ie the value of the widget will be null) 5. the user save the form 6. when the user wants to view what's happened, he see : the element containing the value of the date is present, if he loads the form again he found : 1970-01-01 in the date field (the org.w3c.util.DateParser return this value if empty string its given). In general, it has no sense for kind of data (integer, float, date...) to have three state : empty, null and filled with a value ! So here is a patch to correct this : -- 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: (COCOON-1758) Form locale never used in JXMacros
[
http://issues.apache.org/jira/browse/COCOON-1758?page=comments#action_12428388
]
Marc Portier commented on COCOON-1758:
--
Adding the svn-update references to ease tracking:
http://svn.apache.org/viewvc?view=revrevision=427436
http://svn.apache.org/viewvc?view=revrevision=430438
Form locale never used in JXMacros
--
Key: COCOON-1758
URL: http://issues.apache.org/jira/browse/COCOON-1758
Project: Cocoon
Issue Type: Bug
Components: Blocks: Forms
Affects Versions: 2.1.8, 2.2-dev (Current SVN), 2.1.9
Reporter: Philippe Gassmann
Assigned To: Antonio Gallardo
Fix For: 2.2-dev (Current SVN), 2.1.10-dev (current SVN)
Attachments: 20060201-cocoon-forms-1758, patch.txt, patch1.txt
The JXMacroHelper is created with : jx:set var=cformsHelper
value=#{org.apache.cocoon.forms.generation.JXMacrosHelper.createHelper($cocoon/consumer,$cocoon/request,$cocoon/parameters/locale)}/
So the locale is get from sitemap parameters.
the locale attribute of the form is then never used.
I will provide a patch as soon as possible
--
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: no 'char' datatype
Hi Rice, i suppose you're talking about 2.2, since in 2.1 it's working correctly. In fact the addition made to 2.1 were not ported to 2.2, i added configuration for both char datatype and calcualted fields to 2.2 and just committed them. Simone Rice Yeh wrote: Hi, I have a test on cocoon-forms-sample and find this problem. I know it is because 'char' datatype is NOT enlisted in cocoon-forms.xconf but I do not know how to add it in cocoon-froms.xconf. Hope someone can add it. Rice BoundedThreadPool0-1 ERROR access - Internal Cocoon Problem org.apache.cocoon.ProcessingException: Error calling function handleForm at [CascadingException] - file:/C:/tmp/cocoon/myBlock/target/myBlock/blocks/cocoon-forms-sample/forms/form2_model.xml:141:37 at Form - resource://org/apache/cocoon/forms/flow/javascript/Form.js:46:-1 at handleForm - resource://org/apache/cocoon/forms/flow/javascript/Form.js:349:-1 at map:call - file:/C:/tmp/cocoon/myBlock/target/myBlock/blocks/cocoon-forms-sample/sitemap.xmap:283:40 at map:mount - file:/C:/tmp/cocoon/myBlock/target/myBlock/blocks/sitemap.xmap:21:50 at map:mount - file:/C:/tmp/cocoon/myBlock/target/myBlock/sitemap.xmap:43:49 at org.apache.cocoon.ProcessingException.throwLocated (ProcessingException.java:142) at org.apache.cocoon.components.flow.javascript.LocationTrackingDebugger.getException(LocationTrackingDebugger.java:110) at org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.callFunction (FOM_JavaScriptInterpreter.java:606) at org.apache.cocoon.components.treeprocessor.sitemap.CallFunctionNode.invoke(CallFunctionNode.java:113) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes (AbstractParentProcessingNode.java:54) at org.apache.cocoon.components.treeprocessor.sitemap.MatchNode.invoke(MatchNode.java:84) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes (AbstractParentProcessingNode.java:76) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:150) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes (AbstractParentProcessingNode.java:76) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:91) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process (ConcreteTreeProcessor.java:275) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:172) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process (TreeProcessor.java:247) at org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNode.java:113) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java :54) at org.apache.cocoon.components.treeprocessor.sitemap.MatchNode.invoke(MatchNode.java:84) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java :76) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:150) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java :76) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:91) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:275) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:172) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:247) at org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNode.java:113) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:54) at org.apache.cocoon.components.treeprocessor.sitemap.MatchNode.invoke(MatchNode.java:84) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java :76) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:150) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java :76) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:91) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:275) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:172) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:247) at
Re: Re: [Vote] Java 5 as minimum JDK requirement
...now I am curious Well, one implication of where you are going with this is, Is it appropriate to vote according to your employer's needs. My answer to that is, yes. In fact, I'm certain that it happens all the time. Oh boy! ...I probably should better stop participating in this thread then. IMO PMC members should vote in the best interest of the project - not in the best interest of their employers. If you are a consultant who works for various people at various times you will continually be adding features each of your employer's needs. I see nothing wrong in using your real world experience to influence your votes. What is not OK is for you to be directed by your employer on how to vote on issues. There is a difference in adding and blocking stuff. snip/ OTOH, what if the statement is It is OK to upgrade when BEA and IBM both have versions that support version nnn of XYZ and those versions have been available for at least a year? I would argue that this moves from the category of voting on code modification to voting on procedure, in which case majority rules and the veto can be ignored if the majority does not agree. ...interesting! So do I dare to ask: what is the veto statement in our case then? cheers -- Torsten
Re: [Result] [Vote] Java 5 as minimum JDK requirement
Reinhard Poetz escribió: If I interpret our voting rules correctly, the proposal has been rejected because of the -1 vote. Yes, please stop this thread. We can revisit this issue later. Perhaps our next major version will use java 1.5 as the minimal version. After all this is not stopping developers to use java 1.5 for his development needs, it is just cocoon that needs to be 1.4 compatible that's all. ;-) Best Regards, Antonio Gallardo.
Re: ajax and auto-save cocoon 2.1.x
Chris escribió: Hi, I did post this on the users list: http://marc.theaimsgroup.com/?l=xml-cocoon-usersm=115554355602544w=2 I have not heard anything yet. If anybody has thought about or implemented an auto-save feature in a cocoon-forms application I would like to hear about it. This is like the concept of auto-save/backup in MS-Word. The application crashes before a save, but there is a restore file. In a webapp instead of application crash it is browser-crash/close or session timeout. I am thinking ajax in cforms could be part of the solution. This is an appliation where the user can be on one form for 5 to 20 minutes. I would appreciate any ideas, thanks, Hi Chris, A possible solution: 1. Implement ajax saving. It is described somehow in (near the end of the message): http://marc.theaimsgroup.com/?l=xml-cocoon-devm=115518347428078 2. Implement client-side javascript to post the page every x minutes. There are plenty examples of javascript auto post on the web. Best Regards, Antonio Gallardo.
