If I am reading this correctly - I'm OK with the snapshot source being
zipped and put into Cocoon's CVS - I can easily download that from the web
interface. Whether there is a readme in Cocoon's distribution or a link is
fine, as long as it is clear how to do it.
Ralph
-Original Message-
Just curious. How do you know some Cocoon user hasn't extended this class?
Ralph
-Original Message-
From: Vadim Gritsenko
To: [EMAIL PROTECTED]
Sent: 2/7/2004 4:52 AM
Subject: Re: cvs commit:
cocoon-2.2/src/java/org/apache/cocoon/transformation/pagination
Paginator.java
Joerg Heinicke
Le Samedi, 7 fév 2004, à 23:44 Europe/Zurich, Geoff Howard a écrit :
[EMAIL PROTECTED] wrote:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26753
Persistent store or cache corruption?
--- Additional Comments From [EMAIL PROTECTED] 2004-02-07
18:34 ---
Afaik, this is a known Jisp
Bertrand Delacretaz dijo:
Le Samedi, 7 fév 2004, à 23:44 Europe/Zurich, Geoff Howard a écrit :
[EMAIL PROTECTED] wrote:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26753
Persistent store or cache corruption?
--- Additional Comments From [EMAIL PROTECTED] 2004-02-07
18:34
On 08.02.2004 09:48, Bertrand Delacretaz wrote:
Afaik, this is a known Jisp bug which should be fixed according to
Scott with Jisp 3.0. We could try to switch to Jisp 3.0 after the
release and see what happens.
Are you saying after the release because Jisp 3.0 would require more
changes in
On 08.02.2004 08:06, Ralph Goers wrote:
Just curious. How do you know some Cocoon user hasn't extended this class?
Of course we can not be sure, for some classes it's just unlikely. So
this class was not in use even in the first version of the restructured
2.0 repositories from more than 2
On 08.02.2004 07:58, Ralph Goers wrote:
If I am reading this correctly - I'm OK with the snapshot source being
zipped and put into Cocoon's CVS - I can easily download that from the web
interface. Whether there is a readme in Cocoon's distribution or a link is
fine, as long as it is clear how to
Joerg Heinicke dijo:
On 08.02.2004 07:58, Ralph Goers wrote:
If I am reading this correctly - I'm OK with the snapshot source being
zipped and put into Cocoon's CVS - I can easily download that from the
web
interface. Whether there is a readme in Cocoon's distribution or a link
is
fine, as
Geoff Howard dijo:
[EMAIL PROTECTED] wrote:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26753
Persistent store or cache corruption?
--- Additional Comments From [EMAIL PROTECTED] 2004-02-07 18:34
---
Afaik, this is a known Jisp bug which should be fixed according to
Le Dimanche, 8 fév 2004, à 10:45 Europe/Zurich, Joerg Heinicke a écrit :
...Do we and how do we want to store the sources of CVS snapshots of
our libraries?
If you do your CVS snapshot against a particular date it is
reproducible, something like
cvs export -D 2003-12-31 12:00 somemodule
Then
Le Dimanche, 8 fév 2004, à 10:23 Europe/Zurich, Joerg Heinicke a écrit :
...Bertrand, can you do your test again with the former version of the
JAR (mid december)? From what I see the bug was already in before and
the patch provided by Charles did not solve it as it does not address
the bug in
On Sun, 2004-02-08 at 11:56, Bertrand Delacretaz wrote:
Le Dimanche, 8 fév 2004, à 10:45 Europe/Zurich, Joerg Heinicke a écrit :
...Do we and how do we want to store the sources of CVS snapshots of
our libraries?
If you do your CVS snapshot against a particular date it is
reproducible,
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26750.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24891.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
On 08.02.2004 11:57, Bertrand Delacretaz wrote:
...Bertrand, can you do your test again with the former version of the
JAR (mid december)? From what I see the bug was already in before and
the patch provided by Charles did not solve it as it does not address
the bug in JISP, but only the usage
On 08.02.2004 12:18, Bruno Dumon wrote:
...Do we and how do we want to store the sources of CVS snapshots of
our libraries?
If you do your CVS snapshot against a particular date it is
reproducible, something like
cvs export -D 2003-12-31 12:00 somemodule
IIUC the Avalon people sometimes do
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26750.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
-Original Message-
From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]
Sent: Sunday, February 08, 2004 1:45 AM
To: [EMAIL PROTECTED]
Subject: Re: cvs commit:
cocoon-2.1/src/blocks/portal/java/org/apache/cocoon/portal/plu
to/om PortletDefinitionRegistryImpl.java
Geoff Howard
+---+
| Bugzilla Bug ID |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned
Joerg Heinicke wrote:
On 08.02.2004 12:18, Bruno Dumon wrote:
...Do we and how do we want to store the sources of CVS snapshots
of our libraries?
If you do your CVS snapshot against a particular date it is
reproducible, something like
cvs export -D 2003-12-31 12:00 somemodule
IIUC the
Antonio Gallardo wrote:
Hi:
The new HTMLArea looks great, a nice new feature for Woody! I have a
problem: All the dialogs (choose color, etc.) are open behind the main
browser window while using HTMLArea.
I am using Mozilla 1.4 on Linux Fedora Core 1.
Best Regards,
Antonio Gallardo.
There is a
Hi,
how can I use a string which can be edited by the HTMLArea widget in an
XML binding?
The problem is, that the XHTML content which should be edited is only
shown with the tags removed.
Any ideas?
Thanks,
Andreas
Yes, I had the same problem.
I solved it by using div instead.
Ugo Cei wrote:
There is a much bigger problem with HTMLArea: if you place an HTMLArea
inside a table, it won't be visible (zero-sized) under Internet
Explorer. I hope these bugs will be fixed when the final version of
HTMLArea is
Hi,
I just had the same problem with my own CMS. The
problem is using xsl:copy-of instead of value-of.
Hope it helps :=)
nicolas
--- Andreas Hochsteger
[EMAIL PROTECTED] a écrit : Hi,
how can I use a string which can be edited by the
HTMLArea widget in an
XML binding?
The problem is,
Hi!
Thanks for your reply.
Do you mean the file woody-field-styling.xsl?
I just had a look at it:
!--
wi:field with @type 'htmlarea'
--
xsl:template match=wi:field[wi:[EMAIL PROTECTED]'htmlarea']]
textarea id=[EMAIL PROTECTED] name=[EMAIL PROTECTED] title={wi:hint}
Have you looked in the archives? I know someone had a
similar problem...
--- Andreas Hochsteger
[EMAIL PROTECTED] a écrit : Hi!
Thanks for your reply.
Do you mean the file woody-field-styling.xsl?
I just had a look at it:
!--
wi:field with @type 'htmlarea'
--
Bertrand Delacretaz wrote:
-Original Message-
From: Bertrand Delacretaz [mailto:[EMAIL PROTECTED]
Sent: Sunday, February 08, 2004 9:49 AM
To: [EMAIL PROTECTED]
Subject: Re: DO NOT REPLY [Bug 26753] - Persistent store or cache
corruption?
Le Samedi, 7 fév 2004, à 23:44
Thanks Geoff for spotting this! I only read the 2.3 version which should be
- as Vadim pointed out - allowed to be included.
Unfortunately, the 2.2 version is not allowed; so I will for a first fix
use the 2.3 version for 2.2 as well.
Thanks!
Carsten
-Original Message-
From: Vadim
Vadim Gritsenko wrote:
Geoff Howard wrote:
We can reproduce...
Vadim - I like you, but not _that_ much.
Couldn't resist,
Geoff
Yes, but without success.
Can you give me some hints or keywords what I should search for?
Thanks.
Nicolas Toper wrote:
Have you looked in the archives? I know someone had a
similar problem...
--- Andreas Hochsteger
[EMAIL PROTECTED] a écrit : Hi!
Thanks for your reply.
Do you mean the file
Carsten Ziegeler wrote:
Bertrand Delacretaz wrote:
-Original Message-
From: Bertrand Delacretaz [mailto:[EMAIL PROTECTED]
Sent: Sunday, February 08, 2004 9:49 AM
To: [EMAIL PROTECTED]
Subject: Re: DO NOT REPLY [Bug 26753] - Persistent store or cache
corruption?
Le Samedi, 7 fév 2004, à
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26748.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Geoff Howard wrote:
I didn't realize this was not a universal problem. The impression I had
was that this was consistently repeatable given the same actions in any
installation.
Oh, ok - this might be, perhaps I'm wrong. I didn't try it, but it looked
for me like a problem we faced
Carsten Ziegeler wrote:
Geoff Howard wrote:
I didn't realize this was not a universal problem. The impression I had
was that this was consistently repeatable given the same actions in any
installation.
Oh, ok - this might be, perhaps I'm wrong. I didn't try it, but it looked
for me like a
Some time ago the call-block-target was added to support building a
single block by itself. I can't find enough info on how to use this in
the archives or wiki. I did find:
build -Dblock.name=jms -Dtarget.name=lib call-block-target
which calls cocoon-block-jms-lib for example. But I can't
Geoff Howard wrote:
Some time ago the call-block-target was added to support building a
single block by itself. I can't find enough info on how to use this in
the archives or wiki. I did find:
build -Dblock.name=jms -Dtarget.name=lib call-block-target
which calls cocoon-block-jms-lib for
On 8 Feb 2004, at 13:19, Geoff Howard wrote:
Vadim Gritsenko wrote:
Geoff Howard wrote:
We can reproduce...
Vadim - I like you, but not _that_ much.
Couldn't resist,
Geoff
LOL
--
Stefano.
I'm not normally bugged by namespace declarations which aren't used,
but boy, something like this just can't go on without me to do
something about it:
br xmlns:dir=http://apache.org/cocoon/directory/2.0;
xmlns:include=http://apache.org/cocoon/include/1.0/
[taken from my blog output]
do you
I don't know if you can configure the xml serializer to drop a namespace
(seems unlikely, because such namespace might not be used until the end of
the document, for all the serializer knows, so it wouldn't be safe without
buffering the entire output document to check).
But typically you should
On 8 Feb 2004, at 21:37, Conal Tuohy wrote:
I don't know if you can configure the xml serializer to drop a
namespace
(seems unlikely, because such namespace might not be used until the
end of
the document, for all the serializer knows, so it wouldn't be safe
without
buffering the entire output
It's true that xsl:copy copies namespace declarations that are in scope. But
how do you have html elements inside the scope of a dir:directory element?
Are you using the XPathDirectoryGenerator? If so, or if you've transformed
the dir:file elements into inclusions, etc, then you might want to
41 matches
Mail list logo
