Re: Supersonic block has landed (Power Trio tutorial/example app)

Upayavira wrote: > ...My immediate > response is 'why the name supersonic'. It obfuscates the contents of the > block. Why not just have a tutorial block, or a tutorials block if there > are more than one in there? That way it is completely obvious to someone > looking at Cocoon what is in ther

RE: [QVote] Release 2.1.5 on May 14th

Carsten Ziegeler wrote: > Bertrand Delacretaz wrote: > > Sylvain Wallez a écrit : > > > ...There are still many little things to solidify in the CForms API > > > until it can be marked stable, and therefore Cocoon 2.1.5 will not > > > contain a stable CForms > > > > +1, let's not forget to r

Re: Moving to subversion - volunteers?

On 9 May 2004, at 22:15, Carsten Ziegeler wrote: Nicola Ken Barozzi wrote: Carsten Ziegeler wrote: We agreed that we move to subversion as soon as possible. Next friday we will (hopefully) release 2.1.5, so we should move right after the release. Any volunteers for doing this? Err... what should

Re: Cocoon after 2.1.5

On 9 May 2004, at 22:14, Carsten Ziegeler wrote: Considering all our version discussions, we want the next Cocoon version to be a minor version change, so this will be 2.2. We will put new features into it that were planned for 2.2 anyway, perhaps except blocks. Pier suggested that we follow the L

RE: Cocoon after 2.1.5

I like this, but this has some implications on support. If this is done "just like Linux" there will continue to be maintenance releases of 2.1 while 2.3 is underway. When 2.4 is released there will be maintenance releases of it while 2.5 is being developed. This seems to be a little different th

RE: Moving to subversion - volunteers?

Nicola Ken Barozzi wrote: > > Carsten Ziegeler wrote: > > We agreed that we move to subversion as soon as possible. > > Next friday we will (hopefully) release 2.1.5, so we should > move right > > after the release. > > > > Any volunteers for doing this? > > Err... what should we actually do?

Cocoon after 2.1.5

Considering all our version discussions, we want the next Cocoon version to be a minor version change, so this will be 2.2. We will put new features into it that were planned for 2.2 anyway, perhaps except blocks. Pier suggested that we follow the Linux versioning, so the version numbers .0, .2, e

[VOTE] RE: LogKitLoggerManager

Yes, this change is backward compatible with 2.1.4, but not with the version Carsten checked in last week. I'd appreciate a vote to have this patch applied. Ralph -Original Message- From: Joerg Heinicke [mailto:[EMAIL PROTECTED] Sent: Sunday, May 09, 2004 1:52 PM To: [EMAIL PROTECTED] S

Re: LogKitLoggerManager

On 09.05.2004 19:25, Ralph Goers wrote: I've submitted patch 28860. I realize this is after the code freeze, but I'd prefer to see this patch instead of the current code. If 2.1.5 goes out with the current code we would have to maintain the current behavior of logger-type. I guess it's completely

Re: [GUMP@lsd]: cocoon-2.1/cocoon failed

Adam R. B. Jack wrote: So, we have three choices: (1) Accept that Gump just will not work until we fix this. Not really acceptable (2) Remove the CocoonBeanTestCase (3) Someone more versed in Avalon initialisation have a look into getting the test case working on a full Cocoon. Don't know if

RE: LogKitLoggerManager

I've submitted patch 28860. I realize this is after the code freeze, but I'd prefer to see this patch instead of the current code. If 2.1.5 goes out with the current code we would have to maintain the current behavior of logger-type. Ralph -Original Message- From: Carsten Ziegeler [mailto

Re: [GUMP@lsd]: cocoon-2.1/cocoon failed

> So, we have three choices: > (1) Accept that Gump just will not work until we fix this. Not really > acceptable > (2) Remove the CocoonBeanTestCase > (3) Someone more versed in Avalon initialisation have a look into > getting the test case working on a full Cocoon. Don't know if a 4th interests

DO NOT REPLY [Bug 28860] - [Patch] Allow any LoggerManager to be used

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 28860] - [Patch] Allow any LoggerManager to be used

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 28860] New: - Allow any LoggerManager to be used

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

Bug report for Cocoon 2 [2004/05/09]

+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned

Re: [CForms]FormattingDateConvertor can't convert blank to date in current cvs version.

On 09.05.2004 14:20, Upayavira wrote: I made a little error in my change, it simply needs an "else value = null" added. I'll fix it after the code freeze. Why after? Surely the code freeze is intended to be a time for fixing bugs +1 That's what the code freeze is about. Otherwise we wouldn't need

Re: [CForms]FormattingDateConvertor can't convert blank to date in current cvs version.

Bruno Dumon wrote: On Sun, 2004-05-09 at 12:07, roy huang wrote: Hi All: If I user xml as data to binding cocoon forms,I must using DateConvertor to convert string to date like: -MM-dd the data may looks like: 1971-05-06 But if the data is it will error lik

Re: [CForms]FormattingDateConvertor can't convert blank to date in current cvs version.

On Sun, 2004-05-09 at 12:07, roy huang wrote: > Hi All: > If I user xml as data to binding cocoon forms,I must using DateConvertor to > convert string to date like: >path="date" > > > > -MM-dd > > > > > the data may looks like: > 1971-05-06

[CForms]FormattingDateConvertor can't convert blank to date in current cvs version.

Hi All: If I user xml as data to binding cocoon forms,I must using DateConvertor to convert string to date like: -MM-dd the data may looks like: 1971-05-06 But if the data is it will error like: org.apache.avalon.framework.CascadingRuntimeException:

Re: [GUMP@lsd]: cocoon-2.1/cocoon failed

On 09.05.2004 06:47, Gump wrote: The current state is 'Failed', for reason 'Build Failed' Full details are available at: http://lsd.student.utwente.nl/gump/cocoon-2.1/cocoon/index.html At the above address another error than the one I have at my local system is written: java.io.FileNotFound

Re: Moving to subversion - volunteers?

On 09.05.2004 09:35, Upayavira wrote: Personally, I would leave 2.0 as is, and then: /cocoon/ /trunk/ <- current trunk /tags/new-kernel/ <- current 2.2 code I would do it this way as, if we are to follow our new versioning scheme, we cannot identify the new kernel with the version 2.2, so we s

Re: [GUMP@lsd]: cocoon-2.1/cocoon failed

Joerg Heinicke wrote: On 08.05.2004 15:29, Adam R. B. Jack wrote: If you could add : Applied it. Thanks. I can also reproduce the failure on my local system. When I tried to do all tests some days ago (NetUtils.normalize()) it still worked. Hmm. Now there's an interesting consequence of t

[GUMP@lsd]: cocoon-2.1/cocoon failed

-deprecated] - Info - Dependency on avalon-framework exists, no need to add for property avalonapi.jar. - Info - Made directory [/data3/gump/cocoon-2.1/build/cocoon-20040509/test] - Info - Enable "verbose" output, due to 3 previous error(s). - Info - Failed with reason build failed - Inf

Re: Moving to subversion - volunteers?

Nicola Ken Barozzi wrote: Carsten Ziegeler wrote: We agreed that we move to subversion as soon as possible. Next friday we will (hopefully) release 2.1.5, so we should move right after the release. Any volunteers for doing this? Err... what should we actually do? I mean, let's say that we have

Re: Some CalendarGenerator code

Hi ,Ugo: I never thought the pipeline can do things this way .I will study 1) and find out would this solve my problem. Thanks a lot. Roy Huang - Original Message - From: "Ugo Cei" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, May 09, 2004 3:03 PM Subject: Re: Some Calend

RE: LogKitLoggerManager

Carsten, I just downloaded the most recent source and noticed you modified this section of code just last week to add support for log4j. Do I need to maintain compatibility with logger-type or can I just take that out? The problem is the code assumes that if logger-type is not "logkit" that it mus

Re: Some CalendarGenerator code

Il giorno 09/mag/04, alle 05:04, roy huang ha scritto: 2.Use current generator user must extend it and using java .I believe many cocoon users don't know java much but just now xml.Using transformer user can just use xml to define data. OK, I'll try to say it again, please read carefully and try