RE: [cocoon 2.2] JStyle
Ups, yes I thought it wasn't used and interestingly it did compile for me (even build clean did work). Now, I tested it again, and it doesn't compile anymore - which is obviously the correct thing. Strange! I don't know anything about JStyleFormatter. I will have a look and eventually readd jstyle.jar again. Thanks! Carsten -Original Message- From: Joerg Heinicke [mailto:[EMAIL PROTECTED] Sent: Monday, March 08, 2004 8:41 PM To: [EMAIL PROTECTED] Subject: [cocoon 2.2] JStyle Hello Carsten, you removed jstyle.jar some days ago during updating the licenses. Was the removal by intention? Cocoon 2.2 does no longer compile (JStyleFormatter.java). Has this styling ever been in use? Joerg
Re: [CVS-problem] pre-commit check failed
Reinhard Pötz wrote: As you may saw I wanted to commit the results of renaming Woody to CocoonForms but when I commit a file I get the error message pre-commit check failed. Any ideas what's going on here? (I've already checked whether the license is okay, if I use Unix-style line feeds) Problem solved (didn't use /home/cvs as CVS root directory) - thanks Antonio ;-) -- Reinhard
RE: Cocoon 2.1.5 (was: DO NOT REPLY [Bug 26456] - First Xindice DB is created in current directory (instead of WEB-INF?))
Joerg Heinicke wrote: When Cocoon 2.1.5 is due? I think we should make xindice 1.1b4 before Cocoon 2.1.5 Let's ask Carsten. The way to Cocoon Forms must of course be finished before the release and we should make sure the correct licenses or is the license issue completely finished (besides Woody JS)? I hope to get a release out by the end of this month. We have several things to fix before the release as you mentioned. Currently these are: - the store problem - relicensing - finish renaming to Cocoon Forms - Ensure that we have proper licenses for all libs Carsten
RE: [cocoon 2.2] JStyle
Ok, actually the JStyleFormatter is not used, here is the part from the xconf: !-- Specifies which formatter to use to format source code. This parameter is optional. It is commented out because of bug #5689: Java code-formatter incorrectly formats double values -- !--parameter name=code-formatter value=org.apache.cocoon.components.language.programming.java.JstyleFormatte r/-- Is anyone against removing this completly (at least from 2.2) and deprecating it in 2.1.x? Carsten -Original Message- From: Carsten Ziegeler [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 09, 2004 9:04 AM To: [EMAIL PROTECTED] Subject: RE: [cocoon 2.2] JStyle Ups, yes I thought it wasn't used and interestingly it did compile for me (even build clean did work). Now, I tested it again, and it doesn't compile anymore - which is obviously the correct thing. Strange! I don't know anything about JStyleFormatter. I will have a look and eventually readd jstyle.jar again. Thanks! Carsten -Original Message- From: Joerg Heinicke [mailto:[EMAIL PROTECTED] Sent: Monday, March 08, 2004 8:41 PM To: [EMAIL PROTECTED] Subject: [cocoon 2.2] JStyle Hello Carsten, you removed jstyle.jar some days ago during updating the licenses. Was the removal by intention? Cocoon 2.2 does no longer compile (JStyleFormatter.java). Has this styling ever been in use? Joerg
Re: [CVS-problem] pre-commit check failed
Reinhard Pötz dijo: Reinhard Pötz wrote: As you may saw I wanted to commit the results of renaming Woody to CocoonForms but when I commit a file I get the error message pre-commit check failed. Any ideas what's going on here? (I've already checked whether the license is okay, if I use Unix-style line feeds) Problem solved (didn't use /home/cvs as CVS root directory) - thanks Antonio ;-) :-D Best Regards, Antonio Gallardo
Re: [CVS-problem] pre-commit check failed
Antonio Gallardo wrote: Reinhard Pötz dijo: Reinhard Pötz wrote: As you may saw I wanted to commit the results of renaming Woody to CocoonForms but when I commit a file I get the error message pre-commit check failed. Any ideas what's going on here? (I've already checked whether the license is okay, if I use Unix-style line feeds) Problem solved (didn't use /home/cvs as CVS root directory) - thanks Antonio ;-) :-D A few days ago you told me to take care for the CVS root directory in another context but this was again the solution for my problem ;-) -- Reinhard
Re: Experience with workflow at Hippo Webworks
On Mon, 08 Mar 2004 19:58:32 +0100, Guido Casper [EMAIL PROTECTED] wrote: Johan Stuyts wrote: Using the GoF State pattern works great for simple state machines and I use it a lot. But the pattern does not talk about nested and/or parallel states, which become incomprehensible when coded in Java; the state machine logic gets intermixed with the document logic. Johan, can you give me an example of parallel states? I currently can't even imagine what that might look like on a drawing (hope my business user can ;-) Also I'm not convinced about the need for nested states, although I could think of ways the state pattern might account for that (a state object might use the state pattern itself). What would be a possible alternative implementation? The example I gave about newsletters is an example about parallel states. See the attached diagram. You have the usual edit/review/publish cycle for the web part of the document. And in addition you have a test/send cycle for the email part. The email part prevents the sending of the newsletter twice. The two parts are completely parallel and the total number of possible states of an object is the Cartesian product of all the parallel parts of its state machine. For this example (using four states for the edit/review/publish part) that results in eight possible states. As for the newsletter problem I'll have to solve that one as well :-) But I can think of ways to solve that without introducing a whole bunch of new concepts or terminology just to solve that single use case. If you tell me I'm mixing concerns that may be true. I'm fine with mixing concerns and bending the framework a little for complex cases if it's still easy to grasp. But if the technology doesn't allow me to solve simple problems easily (there might be people claiming the same to be true for Cocoon (in case not being familiar with it) and I think this may be a reason Cocoon not being adopted _much_ wider. I don't mean that as a criticism in any way (it would be one to myself), it's just a fact, AFAICS), I loose interest. If somebody comes up with a full featured workflow engine still simple to use from Cocoon for simple use cases, I would immediately use that. A state machine implementation must ofcourse be comprehensible for simple state machines too. To achieve this the implementation must have the following properties: - easy overview of the whole state machine; you don't have to locate multiple files, or have to jump up and down in a file to understand how things are related; - be terse; details (with defaults) which are not relevant should not be shown. I think it is possible to have both these properties. Guido -- Johan Stuytsattachment: NewsLetterStateMachine.png
Re: [cocoon 2.2] JStyle
On 09.03.2004 09:17, Carsten Ziegeler wrote: Ok, actually the JStyleFormatter is not used, here is the part from the xconf: !-- Specifies which formatter to use to format source code. This parameter is optional. It is commented out because of bug #5689: Java code-formatter incorrectly formats double values -- !--parameter name=code-formatter value=org.apache.cocoon.components.language.programming.java.JstyleFormatte r/-- That was the reason for asking if it has been in use. Is anyone against removing this completly (at least from 2.2) and deprecating it in 2.1.x? +1 especially as there is no place to get more recent versions of jstyle. IIRC this thing has been renamed to astyle and ended completely at the end. After Jalopy was added I tried to write also a JalopyFormatter. But they need something File-based (don't know what exactly, it was not the file-to-be-formatted) and so I stopped it - I didn't want to patch Jalopy first. Furthermore there is the issue of the forking of a commercial version by the main developer Marco Hunsicker. Maybe it's better to wait for a community development, not that they overtake jstyle's fate ... Joerg -Original Message- From: Carsten Ziegeler [mailto:[EMAIL PROTECTED] Ups, yes I thought it wasn't used and interestingly it did compile for me (even build clean did work). Now, I tested it again, and it doesn't compile anymore - which is obviously the correct thing. Strange! I don't know anything about JStyleFormatter. I will have a look and eventually readd jstyle.jar again. Thanks! Carsten -Original Message- From: Joerg Heinicke [mailto:[EMAIL PROTECTED] Hello Carsten, you removed jstyle.jar some days ago during updating the licenses. Was the removal by intention? Cocoon 2.2 does no longer compile (JStyleFormatter.java). Has this styling ever been in use? Joerg
Re: Experience with workflow at Hippo Webworks
On Sun, 07 Mar 2004 18:06:17 -0500, Stefano Mazzocchi [EMAIL PROTECTED] wrote: Sylvain Wallez wrote: Stefano Mazzocchi wrote: Guido Casper wrote: Stefano Mazzocchi wrote: If FSM work bad for flow, why would they work any better for workflow? After thinking again about ways to use continuations with workflow I came to the conclusion this might well be possible. But it looks awkward to me. Each document attached to workflow would need a workflow instance as long as the document lives (from creation to deletion). This would mean the continuation stack of every document needs to be persisted to - well - to a database if you don't want to limit your clustering options. The document has a property holding the continuation ID. You have a point here, Guido. It is true that continuations in a distributed environment would need to be made custer-friendly and replicated. This would probably impact the overall performance... but keep in mind that continuations are just another way to save state. That kind of state transformation (think REST) will have to be done anyway. I thought about this too and think that the current workflow should be accessible without the user holding a special token. If I have a tree of documents I should be able to invoke any active command on a document in that tree. The lifetime of a workflow instance also makes a big difference regarding business process changes. I experienced in a previous job in a large company some workflows (e.g. purchase orders) who changed several times a year, depending on structural changes in the company's organization. And already running instances had to adapt to the new worflow from the state they were in at the date of workflow change. This makes continuations technically not suitable for this, as once a continuation has been created, it's tied to the program's structure where it was created, and it cannot be rerouted to a location in another version of the same program. This won't be easy in state machines either, but I think it is possible if you store state paths. When the workflow instance is read by a new workflow definition, the definition matches the paths to his states. Furthermore, there exists what is called ad-hoc worklows, where a user, depending on its rights, can modify the workflow for a particular instance. An example of this is when a document has to be published that contains highly technical material. The editor may want to add an additional step in the workflow for the document to be validated by a technical expert, which doesn't happen in normal cases. In that situation, asking a user to write a new version of a program for that specific need doesn't seem a good solution to me ;-) Wait a second: to you think that guy would be more confortable in writing a FSM code? I think the option to request review by a technical expert should be programmed explicitly by the developers too. Instead of just 'publish' and 'disapprove', the editor can also invoke 'request technical review'. Let's compare apples to apples here: we are not discussing how the workflows should be edited, but how they are going to impact our system and how we are going to build them. there are several solution on the table and at least two architecturally orthogonal questions: 1) should the workflow engine have direct data control? For me the data should reside in the document/object to which the workflow instance :) is attached. The only information stored in a workflow instance is (possibly) an identifier which can be used to locate the document/object. The actual implementation of the conditions and the actions that get executed on certain events should not be in the workflow definition, but should be separate. The workflow definition only references these separate implementations. The implementations get passed the identifier of the document/object when invoked, so they can retrieve the document/object to do their work. 2) should the workflow engine deal with procedural scripts or finite state machines directly? State machine junkie talking: state machines. I see state machines as a different way of programming than procedural, and think that coding them using procedural code will be more difficult. The conditions and actions which connect the workflow instance to the environment it is running in are procedural, and that's why I program these in Java (in our demo). my take would be 1) no, it should be saparate, sort of a process knowledge base that the flow logic interrogates when it need to 2) procedural scripts: they are always easier to program but, there are valid and solid arguments to make me change my mind on 2) so I think it's better to explore whatever solution makes more sense right now and expand for that, instead of spending too much time on the whiteboard without getting anything out of the door. -- Johan Stuyts
[CocoonForms] END of code freeze
Reinhard Pötz wrote: In the next few days I'm going to rename Woody to Cocoon Forms. So please don't commit into the Woody block any more as it will be removed afterwards. Expect results by the end of next week (and not before Monday afternoon). Here are the new names (latest status summing up the recent discussion): Block Title: Cocoon Forms Block Name: forms Package: org.apache.cocoon.forms Namespace: http://apache.org/cocoon/forms/1.0#definition http://apache.org/cocoon/forms/1.0#definition NS Prefix: fd Reinhard The new forms block is in CVS and Woody removed. Open tasks: - update Unit tests by somebody who is familiar with them - update Wiki pages (maybe we can do this automatically in some parts with moving Wiki to Apache infrastructure) - test the new 'forms' block and the Petstore whether everything works well - test the Ant task that updates Woody projects -- Reinhard
Re: [CocoonForms] END of code freeze
On 09 Mar 2004, at 12:10, Reinhard Pötz wrote: The new forms block is in CVS and Woody removed. ^^ Ouch - are you sure this was needed *immediately after* the renaming? I know this eventually needed to be done, but I would have given the old block a grace period of at least two weeks. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Doc about important changes
It seems that we need a place where we can put important changes for 2.1.5. This is currently the renaming of woody to cocoon forms and the incompatible excalibur-logger change that might cause problems with existing installations. Apart from putting it on the Wiki has someone a good idea where to place such things so that they are visible for people downloading or extracting the distribution? Perhaps a Readme.1st etc. Carsten Carsten Ziegeler Open Source Group, SN AG http://www.osoco.net/weblogs/rael/
Re: Doc about important changes
Le Mardi, 9 mars 2004, à 12:23 Europe/Zurich, Carsten Ziegeler a écrit : ...Apart from putting it on the Wiki has someone a good idea where to place such things so that they are visible for people downloading or extracting the distribution? Perhaps a Readme.1st etc. How about a WARNING.TXT which points to important release info on the web site? In this case it could point to http://cocoon.apache.org/2.1/changes.html - but it would be good to have a way to highlight important changes there, dunno if this requires changes to the status.xml processing. -Bertrand
Re: cvs commit: cocoon-2.1 status.xml
On 09.03.2004 11:57, [EMAIL PROTECTED] wrote: + action dev=RP type=update + Renaming Woody to CocoonForms + - The Woody block (src/blocks/woody) has moved into the new Cocoon Forms +block (src/blocks/forms). + - new namespaces: + * from xmlns:wd=http://apache.org/cocoon/woody/definition/1.0; + to xmlns:fd=http://apache.org/cocoon/forms/1.0#definition; + * from xmlns:wb=http://apache.org/cocoon/woody/binding/1.0; + to xmlns:fb=http://apache.org/cocoon/forms/1.0#binding; + * from xmlns:wi=http://apache.org/cocoon/woody/instance/1.0; + to xmlns:fi=http://apache.org/cocoon/forms/1.0#instance; + * from xmlns:wt=http://apache.org/cocoon/woody/template/1.0; + to xmlns:ft=http://apache.org/cocoon/forms/1.0#template; + - Java packages moved from org.apache.cocoon.woody to +org.apache.cocoon.forms + - Petstore and Apples examples have been renamed + /action The spaces won't be preserved, so the final HTML will look ugly. I guess ul/li will work as this document is transformed to XDocs, isn't it? Joerg
Re: Experience with workflow at Hippo Webworks
On Mon, 8 Mar 2004 15:49:31 -0600, Hunsberger, Peter [EMAIL PROTECTED] wrote: snip I think it would be a good idea to talk about these two -a user-oriented workflow tool with a modeling UI and a well defined limited context -and a more flexible development tool as separate implementations sharing the same interface. I don't see any reason to limit the user oriented tool? Start from a flexible underlying model, be aware that it should be possible to generate the model form some GUI Workflow modeling is very complex by the user is very complex. The user is programming (creating objects, defining conditions, etc.) but must not be aware of it. Its usefulness lies with designing/implementing regularly-changing business processes. When starting this thread my focus was on workflow for a single object, which is much simpler. Also we at Hippo have no requirements for users modifying the workflow. We expect a limited number of workflow definitions and few changes. As a developer I still want to express state machines as tersely as possible. A graphical tool would be great (anyone for writing XSLT to transform XMI documents?), but a well-structured XML document will do fine. -- Johan Stuyts
Re: cvs commit: cocoon-2.1 status.xml
On 09.03.2004 02:39, Vadim Gritsenko wrote:
public void characters(char[] ch, int start, int length) {
if (ch.length 0 start = 0 length 1) {
-String text = new String(ch, start, length);
if (elementStack.size() 0) {
IndexHelperField tos = (IndexHelperField)
elementStack.peek();
-tos.appendText(text);
+tos.appendText(ch, start, length);
}
-bodyText.append(text);
+bodyText.append(' ');
+bodyText.append(ch, start, length);
}
}
What will happen when keyword text is streamed as two characters
events, key and word? I think it will become key word, and
indexing will break.
IIUC, idea was to add a space in between tags, i.e. so
psome/pptext/p is not indexed as sometext. If that's
correct, then better fix would be to add space only if boolean flag
had_start_or_end_element_in_between_char_events set.
Joerg?
Your mail was neither ignored nor accidently deleted - I just didn't
know what really to write, but marked it as important in nice red color
in Mozilla :)
Yes, I see your objection - and asked for them already in the bug
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25934 ;)
So what are the practical use cases this might occure? Maybe it's only a
theoretical problem depending on the thing the index is created from?
On which SAX stream the LuceneIndexHandler operates?
I also don't get your implications for
had_start_or_end_element_in_between_char_events. But I had a look on
the endElement(). It gets the elements from a stack and already tests
for text:
if (text != null text.length() 0) {
Would it make sense to add the space in endElement, if the element
contains text, i.e. the above is true?
Joerg
Re: [CocoonForms] END of code freeze
On 09.03.2004 12:10, Reinhard Pötz wrote: The new forms block is in CVS and Woody removed. Open tasks: - update Unit tests by somebody who is familiar with them - update Wiki pages (maybe we can do this automatically in some parts with moving Wiki to Apache infrastructure) - test the new 'forms' block and the Petstore whether everything works well - test the Ant task that updates Woody projects Though there is a bit of work needed for the stylesheets, JS, and CSS (e.g. 'woody-submit-id') thanks you very much for your massive effort. Joerg
Re: Doc about important changes
Carsten Ziegeler dijo: It seems that we need a place where we can put important changes for 2.1.5. This is currently the renaming of woody to cocoon forms and the incompatible excalibur-logger change that might cause problems with existing installations. Apart from putting it on the Wiki has someone a good idea where to place such things so that they are visible for people downloading or extracting the distribution? Perhaps a Readme.1st etc. What about the RELEASE NOTE? Best Regards, Antonio Gallardo
Re: [CocoonForms] END of code freeze
Joerg Heinicke wrote: On 09.03.2004 12:10, Reinhard Pötz wrote: The new forms block is in CVS and Woody removed. Open tasks: - update Unit tests by somebody who is familiar with them - update Wiki pages (maybe we can do this automatically in some parts with moving Wiki to Apache infrastructure) - test the new 'forms' block and the Petstore whether everything works well - test the Ant task that updates Woody projects Though there is a bit of work needed for the stylesheets, JS, and CSS (e.g. 'woody-submit-id') thanks you very much for your massive effort. Joerg Yes sorry, forget to mention those things. I wanted to unfreeze Cocoon Forms ASAP. -- Reinhard
Re: [CocoonForms] END of code freeze
Steven Noels wrote: On 09 Mar 2004, at 12:10, Reinhard Pötz wrote: The new forms block is in CVS and Woody removed. ^^ Ouch - are you sure this was needed *immediately after* the renaming? I know this eventually needed to be done, but I would have given the old block a grace period of at least two weeks. /Steven Sorry for this. I thought there was no need for the old block but if somebody needs it we can revert the removal. -- Reinhard
Re: cvs commit: cocoon-2.1/src/blocks/forms/java/org/apache/cocoon/forms/datatype/validationruleimpl ValueCountValidationRule.java
Thanks Jörg. I thought Eclipse had already done those updates for us ... strange ... -- Reinhard
Build broken: Duplicate entry for file scratchpad/lib/ehcache-0.7.jar
Hi: In lib/jars.xml there is 2 times a references to: scratchpad/lib/ehcache-0.7.jar Best Regards, Antonio Gallardo
Re: [CocoonForms] END of code freeze
Reinhard Pötz wrote:
Steven Noels wrote:
On 09 Mar 2004, at 12:10, Reinhard Pötz wrote:
The new forms block is in CVS and Woody removed.
*AAARGH*
^^
Ouch - are you sure this was needed *immediately after* the renaming?
I know this eventually needed to be done, but I would have given the
old block a grace period of at least two weeks.
/Steven
Sorry for this. I thought there was no need for the old block but if
somebody needs it we can revert the removal.
Oh yes, *please*, *please*, because this instantly breaks all
applications that use woody and the latest CVS
And I guess many people are in this situation. At least I am.
What would be better, IMO, is to leave the woody block as is, but mark
it as deprecated and clearly indicate the migration in samples.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [CocoonForms] END of code freeze
Le Mardi, 9 mars 2004, à 13:57 Europe/Zurich, Sylvain Wallez a écrit : Reinhard Pötz wrote: ...Sorry for this. I thought there was no need for the old block but if somebody needs it we can revert the removal. ...What would be better, IMO, is to leave the woody block as is, but mark it as deprecated and clearly indicate the migration in samples. Fine, but we must then watch CVS commit messages to make sure the woody block does not diverge from the forms block while both are present. -Bertrand
Re: [cocoon 2.2] JStyle
Carsten Ziegeler wrote: Ok, actually the JStyleFormatter is not used, here is the part from the xconf: !-- Specifies which formatter to use to format source code. This parameter is optional. It is commented out because of bug #5689: Java code-formatter incorrectly formats double values -- !--parameter name=code-formatter value=org.apache.cocoon.components.language.programming.java.JstyleFormatte r/-- Is anyone against removing this completly (at least from 2.2) and deprecating it in 2.1.x? Reminder: formatter was used to pretty-print generated XSP sources. I think it can be removed. Vadim
Re: [CocoonForms] END of code freeze
Steven Noels wrote: On 09 Mar 2004, at 12:10, Reinhard Pötz wrote: The new forms block is in CVS and Woody removed. ^^ Ouch - are you sure this was needed *immediately after* the renaming? I know this eventually needed to be done, but I would have given the old block a grace period of at least two weeks. Why? We have cvs -D yesterday :-) Vadim
Re: cvs commit: cocoon-2.1 status.xml
Joerg Heinicke wrote:
On 09.03.2004 02:39, Vadim Gritsenko wrote:
public void characters(char[] ch, int start, int length) {
if (ch.length 0 start = 0 length 1) {
-String text = new String(ch, start, length);
if (elementStack.size() 0) {
IndexHelperField tos = (IndexHelperField)
elementStack.peek();
-tos.appendText(text);
+tos.appendText(ch, start, length);
}
-bodyText.append(text);
+bodyText.append(' ');
+bodyText.append(ch, start, length);
}
}
What will happen when keyword text is streamed as two characters
events, key and word? I think it will become key word, and
indexing will break.
IIUC, idea was to add a space in between tags, i.e. so
psome/pptext/p is not indexed as sometext. If that's
correct, then better fix would be to add space only if boolean flag
had_start_or_end_element_in_between_char_events set.
Joerg?
Your mail was neither ignored nor accidently deleted - I just didn't
know what really to write, but marked it as important in nice red
color in Mozilla :)
:-)
Yes, I see your objection - and asked for them already in the bug
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25934 ;)
So what are the practical use cases this might occure? Maybe it's only
a theoretical problem depending on the thing the index is created
from? On which SAX stream the LuceneIndexHandler operates?
I remember there were issues already in other components with text being
splitted up onto multiple character events. So, think of this as of
preventive maintenance.
I also don't get your implications for
had_start_or_end_element_in_between_char_events. But I had a look on
the endElement(). It gets the elements from a stack and already tests
for text:
if (text != null text.length() 0) {
Would it make sense to add the space in endElement, if the element
contains text, i.e. the above is true?
This was my first though... But then, multiple closing tags will cause
multiple spaces... So, I thought, this should work:
startElement:
flag = true;
endElement:
flag = true;
characters:
if (flag)
x.append(' ');
flag = false;
Does it solves the problem?
Vadim
Re: Doc about important changes
Carsten Ziegeler wrote: It seems that we need a place where we can put important changes for 2.1.5. This is currently the renaming of woody to cocoon forms and the incompatible excalibur-logger change that might cause problems with existing installations. Apart from putting it on the Wiki has someone a good idea where to place such things so that they are visible for people downloading or extracting the distribution? Perhaps a Readme.1st etc. Why not updating.xml ? It could be reorganized onto several sections, i.e. 2.0 - 2.1, 2.1.4 - 2.1.5, etc Vadim
[Vote] new importance attribute on in status.xml (was: Re: Doc about important changes)
Carsten Ziegeler wrote:
It seems that we need a place where we can put important changes for 2.1.5.
This is currently the renaming of woody to cocoon forms and the incompatible excalibur-logger change that might cause problems with existing installations.
Apart from putting it on the Wiki has someone a good idea where to place such things so that they are visible for people downloading or extracting the distribution? Perhaps a Readme.1st etc.
Once again the need arises to categorize changes ;-)
Let's finally introduce this importance attribute on action
elements, that will allow to clearly distinguish changes. It can be used
to organize the release notes page (important changes come first) and
also to filter the announcement email (only important changes are
relevant here).
I also propose that each block has its own status.xml file. The main
status.xml will be used for changes to the core, and also change of
block status (creation, deprecation, etc).
So let's finally vote on this.
- do you want to add an importance=high|low|medium attribute on
action in changes.xml?
- do you want each block to have it's own status.xml file?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [CocoonForms] END of code freeze
Sylvain Wallez wrote: Reinhard Pötz wrote: ... Sorry for this. I thought there was no need for the old block but if somebody needs it we can revert the removal. Oh yes, *please*, *please*, because this instantly breaks all applications that use woody and the latest CVS I'm missing something... Don't use the latest CVS then, stick to yesterday's version? But, either way this ends up, I'm -1 on keeping both blocks in the release. This means the block must be removed before end of month. Vadim
Re: [Vote] new importance attribute on in status.xml
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
It seems that we need a place where we can put important changes
for 2.1.5.
This is currently the renaming of woody to cocoon forms and the
incompatible excalibur-logger change that might cause problems with
existing installations.
Apart from putting it on the Wiki has someone a good idea where to
place such things so that they are visible for people downloading or
extracting the distribution? Perhaps a Readme.1st etc.
Once again the need arises to categorize changes ;-)
Let's finally introduce this importance attribute on action
elements, that will allow to clearly distinguish changes. It can be
used to organize the release notes page (important changes come first)
and also to filter the announcement email (only important changes are
relevant here).
I also propose that each block has its own status.xml file. The main
status.xml will be used for changes to the core, and also change of
block status (creation, deprecation, etc).
So let's finally vote on this.
- do you want to add an importance=high|low|medium attribute on
action in changes.xml?
+1
- do you want each block to have it's own status.xml file?
+1
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [CocoonForms] END of code freeze
Bertrand Delacretaz wrote:
Le Mardi, 9 mars 2004, à 13:57 Europe/Zurich, Sylvain Wallez a écrit :
Reinhard Pötz wrote:
...Sorry for this. I thought there was no need for the old block but
if somebody needs it we can revert the removal.
...What would be better, IMO, is to leave the woody block as is, but
mark it as deprecated and clearly indicate the migration in samples.
Fine, but we must then watch CVS commit messages to make sure the
woody block does not diverge from the forms block while both are present.
Uh? The blocks _will_ diverge as woody is stopped whereas cforms starts
its life!
A solution to enforce this is to lock the woody directory, either
through CVS lock or by removing write permissions on the repository
directory.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [Vote] new importance attribute on in status.xml
Sylvain Wallez wrote: So let's finally vote on this. - do you want to add an importance=high|low|medium attribute on action in changes.xml? +0.5. How importance is defined - what is important and what is not? - do you want each block to have it's own status.xml file? -0, reduces visibility. Let's do instead: * Do you want to add a block=name attribute on action in changes.xml? +1 Vadim
[cfoms] ValidationError is deprecated
The org.apache.cocoon.forms.datatype.ValidationError is deprecated. Can we remove it completly? Imho it's not good to have deprecated source in a new block :) Carsten Carsten Ziegeler Open Source Group, SN AG http://www.osoco.net/weblogs/rael/
Re: [CocoonForms] END of code freeze
Le Mardi, 9 mars 2004, à 14:17 Europe/Zurich, Sylvain Wallez a écrit : ...Uh? The blocks _will_ diverge as woody is stopped whereas cforms starts its life! Sorry I wasn't clear. I meant what you understood below ;-) A solution to enforce this is to lock the woody directory, either through CVS lock or by removing write permissions on the repository directory. +1, effectively freezing the woody block, that's what I meant -Bertrand
Re: [Vote] new importance attribute on in status.xml (was: Re: Doc about important changes)
Le Mardi, 9 mars 2004, à 14:14 Europe/Zurich, Sylvain Wallez a écrit : - do you want to add an importance=high|low|medium attribute on action in changes.xml? +1 - do you want each block to have it's own status.xml file? +0.5 (trying to be more precise in votes: I'm for it but cannot help ATM) -Bertrand
Re: [cfoms] ValidationError is deprecated
Carsten Ziegeler wrote:
The org.apache.cocoon.forms.datatype.ValidationError is deprecated.
Can we remove it completly? Imho it's not good to have deprecated source in
a new block :)
Sure. We'll have some cleanup to do in the new block: this class was
still there in woody as legacy compatibility support.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [CocoonForms] END of code freeze
Vadim Gritsenko wrote: Sylvain Wallez wrote: Reinhard Pötz wrote: ... Sorry for this. I thought there was no need for the old block but if somebody needs it we can revert the removal. Oh yes, *please*, *please*, because this instantly breaks all applications that use woody and the latest CVS I'm missing something... Don't use the latest CVS then, stick to yesterday's version? But, either way this ends up, I'm -1 on keeping both blocks in the release. This means the block must be removed before end of month. Vadim, I (kindly :-) ask you to revert your -1. I have a project using Woody running on 2.1.4 (not CVS head) and that would force me to upgrade to 2.1.5 AND CForms at the same time while I would prefer doing it seperately. +1 to remove it in 2.1.6 Guido
Re: [Vote] new importance attribute on in status.xml
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
So let's finally vote on this.
- do you want to add an importance=high|low|medium attribute on
action in changes.xml?
+0.5. How importance is defined - what is important and what is not?
Really subjective, I admit. The one that makes the change will initially
decide for the importance, and this can be later discussed if other
don't agree, although I don't think this will happen often.
- do you want each block to have it's own status.xml file?
-0, reduces visibility.
Having a separate file doesn't mean it doesn't appear on a different
page in the docs. Cocoon has some nice features for aggregation ;-)
Let's do instead:
* Do you want to add a block=name attribute on action in
changes.xml?
+1
Good. The important point is to have a per-block classification, even if
I personally prefer a per-block file.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [Vote] new importance attribute on in status.xml
Vadim Gritsenko wrote: Sylvain Wallez wrote: So let's finally vote on this. - do you want to add an importance=high|low|medium attribute on action in changes.xml? +.5 - do you want each block to have it's own status.xml file? -0, reduces visibility. Let's do instead: * Do you want to add a block=name attribute on action in changes.xml? +1 +.5 to either, but I like the attribute better. Geoff
Re: [CocoonForms] END of code freeze
Guido Casper wrote: Vadim Gritsenko wrote: But, either way this ends up, I'm -1 on keeping both blocks in the release. This means the block must be removed before end of month. Vadim, I (kindly :-) ask you to revert your -1. I have a project using Woody running on 2.1.4 (not CVS head) and that would force me to upgrade to 2.1.5 AND CForms at the same time while I would prefer doing it seperately. +1 to remove it in 2.1.6 Ummm... If I'm alone in this, I can change to -0 :-) WDOT? Vadim
Re: [Vote] new importance attribute on in status.xml
Sylvain Wallez wrote: Vadim Gritsenko wrote: Sylvain Wallez wrote: ... - do you want each block to have it's own status.xml file? -0, reduces visibility. Having a separate file doesn't mean it doesn't appear on a different page in the docs. Cocoon has some nice features for aggregation ;-) It is easier to peek into one file, especially if it resides in module root ;-) instead of ferreting through all blocks - and I'm thinking about developers (including me) here :-) Let's do instead: * Do you want to add a block=name attribute on action in changes.xml? +1 Good. The important point is to have a per-block classification, even if I personally prefer a per-block file. Let's do an attribute, please :-) Vadim
Re: [Vote] new importance attribute on in status.xml
Sylvain, I remember looking on this issue on the forrest list a while ago. What about impact instead of importance? Cheers, Cheche Sylvain Wallez wrote: So let's finally vote on this. - do you want to add an importance=high|low|medium attribute on action in changes.xml? - do you want each block to have it's own status.xml file? Sylvain
Re: [CocoonForms] END of code freeze
Le Mardi, 9 mars 2004, à 14:53 Europe/Zurich, Steven Noels a écrit : ...Thanks for your brave effort! Yes, let's not forget this: big THANKS Reinhard for your work! -Bertrand
Re: [CocoonForms] END of code freeze
Deprecating before removing seems the best option if you care about the installed userbase... Just keep both of them for one more release so people can assess the work involved in migrating. It's the more gentle approach :-) Jorg Vadim Gritsenko wrote: Guido Casper wrote: Vadim Gritsenko wrote: But, either way this ends up, I'm -1 on keeping both blocks in the release. This means the block must be removed before end of month. Vadim, I (kindly :-) ask you to revert your -1. I have a project using Woody running on 2.1.4 (not CVS head) and that would force me to upgrade to 2.1.5 AND CForms at the same time while I would prefer doing it seperately. +1 to remove it in 2.1.6 Ummm... If I'm alone in this, I can change to -0 :-) WDOT? Vadim
Re: [Vote] new importance attribute on in status.xml
Juan Jose Pablos wrote:
Sylvain,
I remember looking on this issue on the forrest list a while ago.
What about impact instead of importance?
Mmmh... impact has the underlying meaning that it will have some
negative effects on some existing applications, which is not the case
for 99% of changes (we are careful about back compatibility).
Has something be define in Forrest's DTDs in this area?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [CocoonForms] END of code freeze
Bertrand Delacretaz wrote:
Le Mardi, 9 mars 2004, à 14:53 Europe/Zurich, Steven Noels a écrit :
...Thanks for your brave effort!
Yes, let's not forget this: big THANKS Reinhard for your work!
Sure: THANKS Reinhard!
Sylvain, wondering how long the thanks thread will be ;-)
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [Vote] new importance attribute on in status.xml
Sylvain Wallez wrote: snip/ So let's finally vote on this. - do you want to add an importance=high|low|medium attribute on action in changes.xml? +1 - do you want each block to have it's own status.xml file? +1 /Daniel
Re: [CocoonForms] END of code freeze
Please guys try my Ant tasks, it should do most of the work for you. If not, report back or fix it pls! Oh ...you already created an ant task for it?! Great! Woody-in-production-user, do guys still need a grace period then? cheers -- Torsten
Re: [Vote] new importance attribute on in status.xml
On Tue, Mar 09, 2004 at 03:37:11PM +0100, Reinhard P?tz wrote: Sylvain Wallez wrote: Carsten Ziegeler wrote: So let's finally vote on this. - do you want to add an importance=high|low|medium attribute on action in changes.xml? I think high|low|medium should me more meaningful or in other words self-explaining. What about newFeature, incompatibleChange, minorChange? This would change importance to something like changeType, right? +1 with self-explaining names (even if I am not good at choosing them :) - do you want each block to have it's own status.xml file? As long as we dont have RCB (real Cocoon blocks) I'm in favour of Vadims proposal. +1 to block attribute --Tim Larson
Re: [Vote] new importance attribute on in status.xml
Reinhard Pötz wrote:
Sylvain Wallez wrote:
snip/
- do you want to add an importance=high|low|medium attribute on
action in changes.xml?
I think high|low|medium should me more meaningful or in other words
self-explaining. What about newFeature, incompatibleChange,
minorChange?
These words are too specific, or indicate a different classification.
For example, the new forms block is a newFeature, just as is the
ability to set the output encoding on JSPReader. But the first one is
really important (should appear in announcement) whereas the second is not.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [cfoms] ValidationError is deprecated
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
The org.apache.cocoon.forms.datatype.ValidationError is deprecated.
Can we remove it completly? Imho it's not good to have deprecated
source in a new block :)
Sure. We'll have some cleanup to do in the new block: this
class was still there in woody as legacy compatibility support.
What's the replacement for the above class?
The one it inherits from: o.a.c.forms.validation.ValidationError.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [cfoms] ValidationError is deprecated
Carsten Ziegeler cziegeler at s-und-n.de writes: The org.apache.cocoon.forms.datatype.ValidationError is deprecated. What's the replacement for the above class? org.apache.cocoon.forms.validation.ValidationError Joerg
Re: [CocoonForms] END of code freeze
Torsten Curdt wrote: Shouldn't one be able to keep the old block and use 2.1.5-dev? ...as an interim solution? Yes, I can live with that. But I think it's not a good sign for our users. A user should have a chance to migrate while using a released version. Guido
Re: [Vote] new importance attribute on in status.xml
Reinhard Pötz wrote: I think high|low|medium should me more meaningful or in other words self-explaining. What about newFeature, incompatibleChange, minorChange? Well if the output of that is going to be just more visibility to some actions, then this will increase complexity adding poor value. The idea (at least the one in my head) is that in your can sort/select actions base on the importance (or impact... or gavity). So you can create a status just only for important actions. Given that, why do not use the already priority attribue that has been used on actions, but instead of the actions elements, move it to the child element action? Cheers, Cheche
form framework clean up
Since we are currently in the middle of cleaning up and focussing on *the* one form framework I like to propose and get rid of precept. *snief* I guess it's more or less dead code now and it's an unecessary choice we should get rid of IMO. I doubt anyone is using it so we won't need a grace period. So here is my +1 on removing precept -- Torsten
Re: [cocoon 2.2] JStyle
Carsten Ziegeler wrote: Ups, yes I thought it wasn't used and interestingly it did compile for me (even build clean did work). Now, I tested it again, and it doesn't compile anymore - which is obviously the correct thing. Strange! I don't know anything about JStyleFormatter. I will have a look and eventually readd jstyle.jar again. It's used by XSP to prettify the generated source code. I think it's a leftover from the past anyway. We should move XSP in a block anyway. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: form framework clean up
Le Mardi, 9 mars 2004, à 16:05 Europe/Zurich, Torsten Curdt a écrit : Since we are currently in the middle of cleaning up and focussing on *the* one form framework I like to propose and get rid of precept +1, with thanks for your work on it! -Bertrand
Re: [CocoonForms] END of code freeze
On 09 Mar 2004, at 15:59, Guido Casper wrote: Torsten Curdt wrote: Shouldn't one be able to keep the old block and use 2.1.5-dev? ...as an interim solution? Yes, I can live with that. But I think it's not a good sign for our users. A user should have a chance to migrate while using a released version. +1 - and I think most of us who have production users will agree with that. I don't want to slow down the process, but also don't want to lose users by force-feeding them migration work they haven't catered for. This is just a temporary solution, and in due time new features will emerge from the official cforms branch that will make them do the switch at their own pace. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: Cocoon's Rhino+continuations fork
On 08 Mar 2004, at 23:55, Steven Noels wrote: (partly in reply to http://thread.gmane.org/gmane.comp.mozilla.devel.jseng/3038) Dear all, more specifically Rhino devs, the issue with Cocoon's Rhino fork seems to be appearing with increasing rate on both the Rhino and Cocoon mailing lists. While the discussion underneath remains strictly theoretical unless someone kicks in and starts fixing things, I'd like to iterate over a couple of thoughts and scenarios, if only as a means to start some common thread, maybe even consensus, and to better understand where we stand at ATM. I work with the ASF Cocoon project (ASF = Apache Software Foundation). fyi: I'm talking off-list with some Mozilla folks. So our message was heard. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: [cocoon 2.2] JStyle
Stefano Mazzocchi wrote: We should move XSP in a block anyway. +1 -- Reinhard
Re: Experience with workflow at Hippo Webworks
Johan Stuyts wrote: On Sun, 07 Mar 2004 18:06:17 -0500, Stefano Mazzocchi [EMAIL PROTECTED] wrote: Sylvain Wallez wrote: Stefano Mazzocchi wrote: Guido Casper wrote: Stefano Mazzocchi wrote: If FSM work bad for flow, why would they work any better for workflow? After thinking again about ways to use continuations with workflow I came to the conclusion this might well be possible. But it looks awkward to me. Each document attached to workflow would need a workflow instance as long as the document lives (from creation to deletion). This would mean the continuation stack of every document needs to be persisted to - well - to a database if you don't want to limit your clustering options. The document has a property holding the continuation ID. You have a point here, Guido. It is true that continuations in a distributed environment would need to be made custer-friendly and replicated. This would probably impact the overall performance... but keep in mind that continuations are just another way to save state. That kind of state transformation (think REST) will have to be done anyway. I thought about this too and think that the current workflow should be accessible without the user holding a special token. If I have a tree of documents I should be able to invoke any active command on a document in that tree. with no token, there is no state, therefore no authentication. I think that what you are asking is either impossible or I wouldn't call it workflow but simply accessing a web resource. The lifetime of a workflow instance also makes a big difference regarding business process changes. I experienced in a previous job in a large company some workflows (e.g. purchase orders) who changed several times a year, depending on structural changes in the company's organization. And already running instances had to adapt to the new worflow from the state they were in at the date of workflow change. This makes continuations technically not suitable for this, as once a continuation has been created, it's tied to the program's structure where it was created, and it cannot be rerouted to a location in another version of the same program. This won't be easy in state machines either, but I think it is possible if you store state paths. When the workflow instance is read by a new workflow definition, the definition matches the paths to his states. You can call it whatever you want but a state in a FSM and a continuation in a script are exactly the same thing, they need to contain the same amount of data to be able to resort the execution. The problems in replicating one across containers will be the same problems in replicating the other. Furthermore, there exists what is called ad-hoc worklows, where a user, depending on its rights, can modify the workflow for a particular instance. An example of this is when a document has to be published that contains highly technical material. The editor may want to add an additional step in the workflow for the document to be validated by a technical expert, which doesn't happen in normal cases. In that situation, asking a user to write a new version of a program for that specific need doesn't seem a good solution to me ;-) Wait a second: to you think that guy would be more confortable in writing a FSM code? I think the option to request review by a technical expert should be programmed explicitly by the developers too. Instead of just 'publish' and 'disapprove', the editor can also invoke 'request technical review'. No matter what, an editor is not going to write neither FSM or script code. And even if you throw something like Oracle Workflow at him, he will hire somebody else to do it. Let's compare apples to apples here: we are not discussing how the workflows should be edited, but how they are going to impact our system and how we are going to build them. there are several solution on the table and at least two architecturally orthogonal questions: 1) should the workflow engine have direct data control? For me the data should reside in the document/object to which the workflow instance :) is attached. The only information stored in a workflow instance is (possibly) an identifier which can be used to locate the document/object. The actual implementation of the conditions and the actions that get executed on certain events should not be in the workflow definition, but should be separate. The workflow definition only references these separate implementations. The implementations get passed the identifier of the document/object when invoked, so they can retrieve the document/object to do their work. 2) should the workflow engine deal with procedural scripts or finite state machines directly? State machine junkie talking: state machines. I see state machines as a different way of programming than procedural, and think that coding them using procedural code will be more difficult. The conditions and actions which connect the
Re: [CocoonForms] END of code freeze
Torsten Curdt wrote: RT Maybe somehting we should indroduce anyway. An upgrade script! Would be cool do have it associated with the changes file. /RT Yes, I've already started it. See ./tools/targets/upgrade-build.xml. Currently only the Woody2CocoonForms upgarde script is in but I hope more follows soon. As we're an XML-framework we should have many possiblities to support our users with those scripts ;-) -- Reinhard
[CocoonForms] Woody available again
Sylvain Wallez wrote: Bertrand Delacretaz wrote: Le Mardi, 9 mars 2004, à 14:53 Europe/Zurich, Steven Noels a écrit : ...Thanks for your brave effort! Yes, let's not forget this: big THANKS Reinhard for your work! Sure: THANKS Reinhard! You're welcome :-) Sylvain, wondering how long the thanks thread will be ;-) Can be long enough ;-) --- Woody is in CVS again. -- Reinhard
Re: Experience with workflow at Hippo Webworks
Johan Stuyts wrote: On Mon, 8 Mar 2004 15:49:31 -0600, Hunsberger, Peter [EMAIL PROTECTED] wrote: snip I think it would be a good idea to talk about these two -a user-oriented workflow tool with a modeling UI and a well defined limited context -and a more flexible development tool as separate implementations sharing the same interface. I don't see any reason to limit the user oriented tool? Start from a flexible underlying model, be aware that it should be possible to generate the model form some GUI Workflow modeling is very complex by the user is very complex. The user is programming (creating objects, defining conditions, etc.) but must not be aware of it. Its usefulness lies with designing/implementing regularly-changing business processes. When starting this thread my focus was on workflow for a single object, which is much simpler. Also we at Hippo have no requirements for users modifying the workflow. We expect a limited number of workflow definitions and few changes. As a developer I still want to express state machines as tersely as possible. A graphical tool would be great (anyone for writing XSLT to transform XMI documents?), but a well-structured XML document will do fine. Has anybody ever tried JavaStudio? It was supposed to replace IDEs using visual javabeans. Sort of LabView-style. It was a miserable failure: maintance costs grew exponentially with the number of javabeans involved. It was sooo cool and appealing, but it was all eye-candy. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
[Vote] Removing Woody
As you may saw I've reverted the removal of Woody. IMO just for now and it should be removed ASAP. So let's vote on this: variant A: remove Woody after 2.1.5 release variant B: remove Woody after 2.1.6 release variant C: leave Woody where it is and mark it as won't change Your votes please! -- Reinhard
Re: [CocoonForms] END of code freeze
Steven Noels wrote: On 09 Mar 2004, at 12:10, Reinhard Pötz wrote: The new forms block is in CVS and Woody removed. ^^ Ouch - are you sure this was needed *immediately after* the renaming? I know this eventually needed to be done, but I would have given the old block a grace period of at least two weeks. or more! we are changing this for community dynamics, but we DO NOT want to screw our users since we did already release this (even if an alpha block). As long as everybody understands that that block is going to go away, it's safe to leave it there for a few more releases, IMHO. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: [Vote] Removing Woody
Reinhard Pötz wrote: As you may saw I've reverted the removal of Woody. IMO just for now and it should be removed ASAP. So let's vote on this: variant A: remove Woody after 2.1.5 release variant B: remove Woody after 2.1.6 release variant C: leave Woody where it is and mark it as won't change Your votes please! I'm +1 on A, +0.5 on B and -1 on C (there is an upgrade script available which has of course to be tested but sooner or later it will do the upgrade for our users!) -- Reinhard
RE: [Vote] Removing Woody
As you may saw I've reverted the removal of Woody. IMO just for now and Thanks for all your work Reinhard! variant A: remove Woody after 2.1.5 release +1 And post blinking signs everywhere that this will happen :-) Matthew
Re: [CocoonForms] END of code freeze
Bertrand Delacretaz wrote: Le Mardi, 9 mars 2004, à 13:57 Europe/Zurich, Sylvain Wallez a écrit : Reinhard Pötz wrote: ...Sorry for this. I thought there was no need for the old block but if somebody needs it we can revert the removal. ...What would be better, IMO, is to leave the woody block as is, but mark it as deprecated and clearly indicate the migration in samples. Fine, but we must then watch CVS commit messages to make sure the woody block does not diverge from the forms block while both are present. we can make it read only ;-) -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: [Vote] Removing Woody
Le Mardi, 9 mars 2004, à 16:21 Europe/Zurich, Reinhard Pötz a écrit : variant A: remove Woody after 2.1.5 release +1 -Bertrand
Re: [Vote] Removing Woody
On 09 Mar 2004, at 16:21, Reinhard Pötz wrote: As you may saw I've reverted the removal of Woody. IMO just for now and it should be removed ASAP. So let's vote on this: variant A: remove Woody after 2.1.5 release variant B: remove Woody after 2.1.6 release I'm all for removing Woody when the cforms block reaches 1.0 status + one or two releases after that. No need to push ourselves too hard for that - I'm sure it will happen in due time. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
[Vote] Moving XSP into its own block
Stefano Mazzocchi wrote: We should move XSP in a block anyway. +1 from Stefano, Antonio, Reinhard -- Reinhard, giving this thread an appropriate subject but doesn't mean he will do the move ;-)
Re: [Proposal] Document development/maintenance practices
Le Mardi, 9 mars 2004, à 16:27 Europe/Zurich, Tim Larson a écrit : ...I propose we create a document detailing the practices and policies we follow to minimize this risk to users of Cocoon. Sounds good. ... Maintaining a change log to help with upgrades And our CVS has all the details Strongly avoiding breaking interfaces And indicating what's more stable or more subject to change Conducting open, public discussion of design and development Querying userbase to determine impact of potential changes Responding to the userbase, even reverting changes when necessary Voting on major additions, changes, deprecations, and removals Deprecating interfaces instead of immediately dropping support Only allowing code that has a community to support it What do others think about developing a document like this to document our guidelines and improve our marketability? I like the idea, maybe you can start something on the wiki? Do we already have a document like this somewhere? I don't think so. -Bertrand
Re: [Vote] Moving XSP into its own block
We should move XSP in a block anyway. +1 from Stefano, Antonio, Reinhard +0.5 (=good idea, won't be able to help) -Bertrand
Re: [Vote] Moving XSP into its own block
Reinhard Pötz wrote: Stefano Mazzocchi wrote: We should move XSP in a block anyway. +1 from Stefano, Antonio, Reinhard +1 -- Unico
Re: [CocoonForms] END of code freeze
Reinhard Pötz wrote: ... The new forms block is in CVS and Woody removed. Open tasks: ... - update Wiki pages (maybe we can do this automatically in some parts with moving Wiki to Apache infrastructure) I can rename the pages on the new Wiki to be FormBinding instead of WoodyBinding. This would be trivial for me as a part of the conversion. I won't change the content of the pages though. That would be quite a bit more complicated. Agree? Regards, Upayavira
Re: [Vote] Removing Woody
On Tue, Mar 09, 2004 at 04:21:09PM +0100, Reinhard P?tz wrote: As you may saw I've reverted the removal of Woody. IMO just for now and it should be removed ASAP. So let's vote on this: variant A: remove Woody after 2.1.5 release variant B: remove Woody after 2.1.6 release variant C: leave Woody where it is and mark it as won't change Your votes please! -- Reinhard +1 to freeze the Woody directory via permissions or CVS right now. +1 to keep it at least for the 2.1.5 release. +1 to query the users ml after the 2.1.5 release to see if there is any reason to keep it for one more release (2.1.6). We have to remember that even though we state that Woody is alpha, there is a pretty large installed userbase already. We have to be nice to them to keep them with us during transitions like this. Please see my email about documenting practices and policies if you wonder why I care so much about this. --Tim Larson
Re: [Vote] Moving XSP into its own block
Am Di, den 09.03.2004 schrieb Unico Hommes um 16:39: Reinhard Pötz wrote: Stefano Mazzocchi wrote: We should move XSP in a block anyway. +1 from Stefano, Antonio, Reinhard +1 Big +1 Stephan Michels.
Re: [Vote] Removing Woody
Reinhard Pötz dijo: As you may saw I've reverted the removal of Woody. IMO just for now and it should be removed ASAP. So let's vote on this: variant A: remove Woody after 2.1.5 release +1 Woody never reached a stable status was at alpha stages from the beginning. A sooner remove means less pain in the future. Best Regards, Antonio Gallardo
Re: form framework clean up
Torsten Curdt wrote: Since we are currently in the middle of cleaning up and focussing on *the* one form framework I like to propose and get rid of precept. *snief* I guess it's more or less dead code now and it's an unecessary choice we should get rid of IMO. I doubt anyone is using it so we won't need a grace period. So here is my +1 on removing precept +1 -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: form framework clean up
Torsten Curdt wrote: Since we are currently in the middle of cleaning up and focussing on *the* one form framework I like to propose and get rid of precept. *snief* I guess it's more or less dead code now and it's an unecessary choice we should get rid of IMO. I doubt anyone is using it so we won't need a grace period. So here is my +1 on removing precept +1 -- Reinhard
RE: [VOTE] Rename Rhino-with-continuations packages
Maybe it's just me, but when I tried to use the ParanoidCocoonServlet with Weblogic 8.1 I could not get it to work. That was with one of the milestone releases of 2.1 though and was so long ago I don't remember what the symptoms were. Ralph -Original Message- From: Sylvain Wallez [mailto:[EMAIL PROTECTED] Sent: Monday, March 08, 2004 11:33 PM To: [EMAIL PROTECTED] Subject:Re: [VOTE] Rename Rhino-with-continuations packages Just curious: what is Rhino used for in WL and WS? Is it used in the application space, or in the container space. In other words, can using the ParanoidCocoonServlet solve the problem? Sylvain
Re: [Vote] Removing Woody
Tim Larson wrote:
On Tue, Mar 09, 2004 at 04:21:09PM +0100, Reinhard P?tz wrote:
As you may saw I've reverted the removal of Woody. IMO just for now and
it should be removed ASAP. So let's vote on this:
variant A: remove Woody after 2.1.5 release
variant B: remove Woody after 2.1.6 release
variant C: leave Woody where it is and mark it as won't change
Your votes please!
+1 to freeze the Woody directory via permissions or CVS right now.
+1 to keep it at least for the 2.1.5 release.
+1 to query the users ml after the 2.1.5 release to see if
there is any reason to keep it for one more release (2.1.6).
We have to remember that even though we state that Woody is alpha,
there is a pretty large installed userbase already. We have to be
nice to them to keep them with us during transitions like this.
I totally second that:
+1 to freeze,
+1 to keep in 2.1.5,
+1 to poll users after 2.1.5.
And thanks a lot (again), Reinhard for this work.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [Proposal] Document development/maintenance practices
Tim Larson wrote:
At my workplace they are worried that pairing their slow upgrade
cycle with the fast pace of open source projects could cause
maintenance problems for their custom code. They are concerned
that a delayed upgrade may be as painful as switching to another
project. I propose we create a document detailing the practices
and policies we follow to minimize this risk to users of Cocoon.
To start the discussion, here is a seed list of practices that
I have noticed we try to be known for following:
[Disclaimer: We are under no contract and offer no warranty
concerning these practices (see our license for details.)]
Continuing to support older releases
Maintaining a change log to help with upgrades
Strongly avoiding breaking interfaces
Conducting open, public discussion of design and development
Querying userbase to determine impact of potential changes
Responding to the userbase, even reverting changes when necessary
Voting on major additions, changes, deprecations, and removals
Deprecating interfaces instead of immediately dropping support
Only allowing code that has a community to support it
What do others think about developing a document like this
to document our guidelines and improve our marketability?
Do we already have a document like this somewhere?
Sounds very good, and a useful addition to our documentation.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [Proposal] Document development/maintenance practices
Tim Larson dijo: At my workplace they are worried that pairing their slow upgrade cycle with the fast pace of open source projects could cause maintenance problems for their custom code. They are concerned that a delayed upgrade may be as painful as switching to another project. I propose we create a document detailing the practices and policies we follow to minimize this risk to users of Cocoon. To start the discussion, here is a seed list of practices that I have noticed we try to be known for following: [Disclaimer: We are under no contract and offer no warranty concerning these practices (see our license for details.)] Continuing to support older releases Maintaining a change log to help with upgrades Strongly avoiding breaking interfaces Conducting open, public discussion of design and development Querying userbase to determine impact of potential changes Responding to the userbase, even reverting changes when necessary Voting on major additions, changes, deprecations, and removals Deprecating interfaces instead of immediately dropping support Only allowing code that has a community to support it What do others think about developing a document like this to document our guidelines and improve our marketability? Do we already have a document like this somewhere? +1. Good idea, it can be stated as official project practices. It wil help to reduce the FUD. Best Regards, Antonio Gallardo
Re: [Vote] Moving XSP into its own block
Bertrand Delacretaz wrote: We should move XSP in a block anyway. +1 from Stefano, Antonio, Reinhard +0.5 (=good idea, won't be able to help) same here, Geoff
RE: [Vote] Removing Woody
If Woody is being completely frozen couldn't the block be made available as a source download separate from 2.1.5? Ralph -Original Message- From: Antonio Gallardo [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 09, 2004 7:46 AM To: [EMAIL PROTECTED] Subject:Re: [Vote] Removing Woody Reinhard Pötz dijo: As you may saw I've reverted the removal of Woody. IMO just for now and it should be removed ASAP. So let's vote on this: variant A: remove Woody after 2.1.5 release +1 Woody never reached a stable status was at alpha stages from the beginning. A sooner remove means less pain in the future. Best Regards, Antonio Gallardo
Re: [Vote] Removing Woody
On Tue, Mar 09, 2004 at 03:47:30PM +, Tim Larson wrote: On Tue, Mar 09, 2004 at 04:21:09PM +0100, Reinhard P?tz wrote: As you may saw I've reverted the removal of Woody. IMO just for now and it should be removed ASAP. So let's vote on this: variant A: remove Woody after 2.1.5 release variant B: remove Woody after 2.1.6 release variant C: leave Woody where it is and mark it as won't change Your votes please! -- Reinhard +1 to freeze the Woody directory via permissions or CVS right now. +1 to keep it at least for the 2.1.5 release. +1 to query the users ml after the 2.1.5 release to see if there is any reason to keep it for one more release (2.1.6). We have to remember that even though we state that Woody is alpha, there is a pretty large installed userbase already. We have to be nice to them to keep them with us during transitions like this. Please see my email about documenting practices and policies if you wonder why I care so much about this. --Tim Larson A few more points: +1 to keep the Woody* wiki pages and any other Woody documentation for as long as we keep the Woody block. +0 Freeze the Woody documentation. I only rate this +0 because even though the code is frozen, the documentation may still need clarifications and fixes. +1 to let bug fixes (not new features) into the Woody block. --Tim Larson
Re: [Vote] Moving XSP into its own block
On Tue, Mar 09, 2004 at 11:20:46AM -0500, Geoff Howard wrote: Bertrand Delacretaz wrote: We should move XSP in a block anyway. +1 from Stefano, Antonio, Reinhard +0.5 (=good idea, won't be able to help) same here, Geoff and same reasoning here, +0.5 --Tim Larson
Re: [CocoonForms] END of code freeze
Bertrand Delacretaz wrote: Le Mardi, 9 mars 2004, à 16:39 Europe/Zurich, Upayavira a écrit : Reinhard Pötz wrote: ... The new forms block is in CVS and Woody removed. Open tasks: ... - update Wiki pages (maybe we can do this automatically in some parts with moving Wiki to Apache infrastructure) I can rename the pages on the new Wiki to be FormBinding instead of WoodyBinding. This would be trivial for me as a part of the conversion. I won't change the content of the pages though. That would be quite a bit more complicated. Did you store intermediate pages as text files? If so, it would be fairly easy to replace woody words by forms words with a few sed pipelines. Much less work than doing it manually later on the wiki IMHO. I can help with the sed stuff if needed (but not before Thursday). It's all done in Perl. So if someone supplies me with s/Woody/Forms/g; statements, I'll happily add them! Regards, Upayavira
Re: [Vote] Removing Woody
Reinhard Pötz wrote: As you may saw I've reverted the removal of Woody. IMO just for now and it should be removed ASAP. So let's vote on this: variant A: remove Woody after 2.1.5 release +1 variant B: remove Woody after 2.1.6 release +0 variant C: leave Woody where it is and mark it as won't change -0 /Daniel
Re: [Vote] Moving XSP into its own block
Reinhard Pötz wrote: Stefano Mazzocchi wrote: We should move XSP in a block anyway. +1 from Stefano, Antonio, Reinhard +1 /Daniel
DO NOT REPLY [Bug 27301] - FilterTransformer: Generates not matching block tags
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27301. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27301 FilterTransformer: Generates not matching block tags [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED --- Additional Comments From [EMAIL PROTECTED] 2004-03-09 16:48 --- it works now, a namespace of its own for the block element will be better, but I can work with this version Cheers, Fredy
Re: [Vote] Removing Woody
Reinhard Pötz wrote: As you may saw I've reverted the removal of Woody. IMO just for now and it should be removed ASAP. So let's vote on this: variant B: remove Woody after 2.1.6 release +1 Ugo
Re: cvs commit: cocoon-2.1/src/blocks/forms/java/org/apache/cocoon/forms/datatype/validationruleimpl ValueCountValidationRule.java
On 09.03.2004 13:28, Reinhard Pötz wrote: Thanks Jörg. I thought Eclipse had already done those updates for us ... strange ... If you used the refactor thing, you have to set a switch in javadoc IIRC. Jörg
Re: form framework clean up
On 09.03.2004 16:05, Torsten Curdt wrote: Since we are currently in the middle of cleaning up and focussing on *the* one form framework I like to propose and get rid of precept. *snief* I guess it's more or less dead code now and it's an unecessary choice we should get rid of IMO. I doubt anyone is using it so we won't need a grace period. So here is my +1 on removing precept +1 Joerg
Re: [Vote] new importance attribute on in status.xml
On 09.03.2004 15:27, Juan Jose Pablos wrote: Mmmh... impact has the underlying meaning that it will have some negative effects on some existing applications, which is not the case for 99% of changes (we are careful about back compatibility). I was looking for a name, and I found weight as well as a good choice. I have check the weight definition, and I found Gravity as another choice. Please not more abstract than necessary :) @importance or @impact is a better choice IMO. Joerg
Re: [Vote] new importance attribute on in status.xml
On 09.03.2004 14:14, Sylvain Wallez wrote: - do you want to add an importance=high|low|medium attribute on action in changes.xml? +1 @importance or @impact - do you want each block to have it's own status.xml file? +0 Vadim wrote: * Do you want to add a block=name attribute on action in changes.xml? +0.5 I prefer this about the above one. Reinhard wrote: I think high|low|medium should me more meaningful or in other words self-explaining. What about newFeature, incompatibleChange, minorChange? -0.5 to special IMO. Cheche wrote: Given that, why do not use the already priority attribue that has been used on actions, but instead of the actions elements, move it to the child element action? +0.5 also a good alternative, but @priority give a bit another attitude than @impact/@importance. Hope I did not miss any suggestion :) Joerg
Re: [Vote] Moving XSP into its own block
On 09.03.2004 16:34, Reinhard Pötz wrote: We should move XSP in a block anyway. +1
