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
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)
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
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
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
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
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
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
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
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
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
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
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
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
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
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) {
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
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
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
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
Thanks Jörg. I thought Eclipse had already done those updates for us ...
strange ...
--
Reinhard
Hi:
In lib/jars.xml
there is 2 times a references to: scratchpad/lib/ehcache-0.7.jar
Best Regards,
Antonio Gallardo
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?
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
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
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
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) {
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
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
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
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
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
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
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/
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
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)
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
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
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
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
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
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 ;-)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
Stefano Mazzocchi wrote:
We should move XSP in a block anyway.
+1
--
Reinhard
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
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
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
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
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!
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
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
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
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
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
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
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 ;-)
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
We should move XSP in a block anyway.
+1 from Stefano, Antonio, Reinhard
+0.5 (=good idea, won't be able to help)
-Bertrand
Reinhard Pötz wrote:
Stefano Mazzocchi wrote:
We should move XSP in a block anyway.
+1 from Stefano, Antonio, Reinhard
+1
--
Unico
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
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:
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.
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
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
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
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
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
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
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
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
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]
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
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
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
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
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 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.
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
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
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
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
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
On 09.03.2004 16:34, Reinhard Pötz wrote:
We should move XSP in a block anyway.
+1
1 - 100 of 129 matches
Mail list logo
