Antonio Gallardo wrote:
Do you think we need a new vote again? :-)
2.2 is under develoment (alpha!) and should not be used in production. IMO we
are free to use 1.4 for now. When we reach a consolidated state of Cocoon core
2.2 we can try to compile with 1.3 and see what is needed to enable the
Antonio Gallardo wrote:
On Mie, 8 de Diciembre de 2004, 15:17, Conal Tuohy dijo:
Leszek Gawron wrote:
Though I would suggest jx:call-macro name=fooBar/ which would make it
clear that the attribute is the NAME of the macro to be invoked, rather
than the macro itself.
+1 here.
But please keep in
Bertrand Delacretaz wrote:
Le 9 déc. 04, à 01:03, Leszek Gawron a écrit :
...
+?xml version=1.0 encoding=UTF-8?
...
This is BOM (byte ordering mark). It is being written by some of xml
editors to the beginning of the multibyte encoded (i.e. utf-8) xml
file. The file I commited is a valid xml.
Il giorno 09/dic/04, alle 09:04, Reinhard Poetz ha scritto:
2.2 is under develoment (alpha!) and should not be used in production.
IMO we are free to use 1.4 for now. When we reach a consolidated state
of Cocoon core 2.2 we can try to compile with 1.3 and see what is
needed to enable the
On Jue, 9 de Diciembre de 2004, 2:21, Leszek Gawron dijo:
By the way: it is a little bit different on win32. Some tools detect utf
encoding by checking for BOM. If there is none - ANSI encoding is assumed.
then switch to Linux! ;-)
Best Regards,
Antonio Gallardo
Leszek Gawron wrote:
snip/
That's good. If noone objects I will start tomorrow and hopefully commit
tomorrow.
I have not had time to evalute your proposal in detail, but from a first
look it seem good, so please go ahead.
The syntax you proposed for invocation:
jx:invoke
Le 9 déc. 04, à 09:21, Leszek Gawron a écrit :
...By the way: it is a little bit different on win32. Some tools
detect utf encoding by checking for BOM. If there is none - ANSI
encoding is assumed...
AFAIU this is ok for 16-bit based encodings, not for UTF-8.
-Bertrand
smime.p7s
Description:
Daniel Fagerstrom wrote:
Leszek Gawron wrote:
snip/
That's good. If noone objects I will start tomorrow and hopefully
commit tomorrow.
I have not had time to evalute your proposal in detail, but from a first
look it seem good, so please go ahead.
The syntax you proposed for invocation:
Bertrand Delacretaz wrote:
Le 9 déc. 04, à 09:21, Leszek Gawron a écrit :
...By the way: it is a little bit different on win32. Some tools
detect utf encoding by checking for BOM. If there is none - ANSI
encoding is assumed...
AFAIU this is ok for 16-bit based encodings, not for UTF-8.
On Jue, 9 de Diciembre de 2004, 2:49, Leszek Gawron dijo:
Bertrand Delacretaz wrote:
Le 9 déc. 04, à 09:21, Leszek Gawron a écrit :
...By the way: it is a little bit different on win32. Some tools
detect utf encoding by checking for BOM. If there is none - ANSI
encoding is assumed...
/~lgawron/jxtg-20041209.zip
Wasn't that hard with eclipse. Still took 4 hours so I'd appreciate if
you looked at it :)
--
Leszek Gawron [EMAIL PROTECTED]
Project ManagerMobileBox sp. z o.o.
+48 (61) 855 06 67
On Jue, 9 de Diciembre de 2004, 3:01, Leszek Gawron dijo:
If you already have something I should not commit - maybe I would send
you the source via email so you could use it if you wanted?
http://www.apache.org/~lgawron/jxtg-20041209.zip
Wasn't that hard with eclipse. Still took 4 hours so
Antonio Gallardo wrote:
On Jue, 9 de Diciembre de 2004, 3:01, Leszek Gawron dijo:
If you already have something I should not commit - maybe I would send
you the source via email so you could use it if you wanted?
http://www.apache.org/~lgawron/jxtg-20041209.zip
Wasn't that hard with eclipse. Still
Le 9 déc. 04, à 09:49, Leszek Gawron a écrit :
... Because Microsoft did it, and there is so much Notepad data out
there, the UTF-8 BOM became a de facto standard and then a de jure
standard. (Although the BOM is optional.)..
hmm...not sure if notepad is the kind of reference that we want to use
Bertrand Delacretaz wrote:
Le 9 déc. 04, à 09:49, Leszek Gawron a écrit :
... Because Microsoft did it, and there is so much Notepad data out
there, the UTF-8 BOM became a de facto standard and then a de jure
standard. (Although the BOM is optional.)..
hmm...not sure if notepad is the kind of
Automated Cocoon Unit tests failed!
Full log file if this unit test run is available here:
http://nagoya.apache.org/~vadim/cocoon-test-log-20041209.log
Last messages from the log file:
==
[foreach] reader-mime-type.xml:39
The commons HttpClient library does not automatically do redirects (see
http://jakarta.apache.org/commons/httpclient/redirects.html). So, when
the WebServiceProxyGenerator receives a redirect response, which has no
body, it chokes on it. In my case I was trying to proxy a JSPWiki
instance - the
should not commit - maybe I would send
you the source via email so you could use it if you wanted?
http://www.apache.org/~lgawron/jxtg-20041209.zip
Wasn't that hard with eclipse. Still took 4 hours so I'd appreciate if
you looked at it :)
I think you can commit the changes, if it is working
To whom it may satisfy...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon-block-xsp *no longer* has an issue.
The current state of this project is
To whom it may satisfy...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon-block-session-fw *no longer* has an issue.
The current state of this
To whom it may satisfy...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon-block-batik *no longer* has an issue.
The current state of this project
To whom it may satisfy...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon-block-chaperon *no longer* has an issue.
The current state of this
To whom it may satisfy...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon-block-databases *no longer* has an issue.
The current state of this
To whom it may satisfy...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon-block-hsqldb *no longer* has an issue.
The current state of this project
To whom it may satisfy...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon-block-taglib *no longer* has an issue.
The current state of this project
To whom it may satisfy...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon-block-html *no longer* has an issue.
The current state of this project
To whom it may satisfy...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon-block-itext *no longer* has an issue.
The current state of this project
To whom it may satisfy...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon-block-jfor *no longer* has an issue.
The current state of this project
To whom it may satisfy...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon-block-linkrewriter *no longer* has an issue.
The current state of this
To whom it may satisfy...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon-block-velocity *no longer* has an issue.
The current state of this
To whom it may satisfy...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon-block-midi *no longer* has an issue.
The current state of this project
To whom it may satisfy...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon-block-paranoid *no longer* has an issue.
The current state of this
To whom it may satisfy...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon-block-poi *no longer* has an issue.
The current state of this project is
To whom it may satisfy...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon-block-profiler *no longer* has an issue.
The current state of this
Leszek Gawron wrote:
Daniel Fagerstrom wrote:
snip/
syntax instead. So that it can work together with common XML tools, if
people want to use such.
That would be good but looks like a bigger change while current macro
call is done via
macroName param1=value param2=value/
so I would reuse
To whom it may satisfy...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon-block-python *no longer* has an issue.
The current state of this project
To whom it may satisfy...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon-block-serializers *no longer* has an issue.
The current state of this
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon-block-template has an issue affecting its community integration.
This
To whom it may satisfy...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon-block-web3 *no longer* has an issue.
The current state of this project
To whom it may satisfy...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon-block-woody *no longer* has an issue.
The current state of this project
To whom it may satisfy...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon-block-forms *no longer* has an issue.
The current state of this project
To whom it may satisfy...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon-block-authentication-fw *no longer* has an issue.
The current state of
To whom it may satisfy...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon-block-bsf *no longer* has an issue.
The current state of this project is
To whom it may satisfy...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon-block-deli *no longer* has an issue.
The current state of this project
To whom it may satisfy...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon-block-jms *no longer* has an issue.
The current state of this project is
To whom it may satisfy...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon-block-portal *no longer* has an issue.
The current state of this project
To whom it may satisfy...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon-block-linotype *no longer* has an issue.
The current state of this
To whom it may satisfy...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon-block-naming *no longer* has an issue.
The current state of this project
To whom it may satisfy...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon-block-portal-fw *no longer* has an issue.
The current state of this
To whom it may satisfy...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon-block-qdox *no longer* has an issue.
The current state of this project
To whom it may satisfy...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon-block-stx *no longer* has an issue.
The current state of this project is
Daniel Fagerstrom wrote:
Leszek and I have started refactoring JXTG, by breaking it up in its
subclasses. Later we will work on creating more detailed interfaces
between the different parts and all the other stuff that has been
discussed on the list.
Now the question is: where should this work
To whom it may satisfy...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon-block-xmldb *no longer* has an issue.
The current state of this project
To whom it may satisfy...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon-block-asciiart *no longer* has an issue.
The current state of this
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon-block-cron has an issue affecting its community integration.
This issue
To whom it may satisfy...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon-block-faces *no longer* has an issue.
The current state of this project
To whom it may satisfy...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon-block-lucene *no longer* has an issue.
The current state of this project
To whom it may satisfy...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon-block-petstore *no longer* has an issue.
The current state of this
To whom it may satisfy...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon-block-querybean *no longer* has an issue.
The current state of this
To whom it may satisfy...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon-block-axis *no longer* has an issue.
The current state of this project
To whom it may satisfy...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon-block-fop *no longer* has an issue.
The current state of this project is
To whom it may satisfy...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon-block-proxy *no longer* has an issue.
The current state of this project
To whom it may satisfy...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon-block-tour *no longer* has an issue.
The current state of this project
To whom it may satisfy...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon-block-apples *no longer* has an issue.
The current state of this project
To whom it may satisfy...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon-block-jsp *no longer* has an issue.
The current state of this project is
To whom it may satisfy...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon-block-eventcache *no longer* has an issue.
The current state of this
To whom it may satisfy...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon-block-repository *no longer* has an issue.
The current state of this
To whom it may satisfy...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon-block-webdav *no longer* has an issue.
The current state of this project
To whom it may satisfy...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon-block-slide *no longer* has an issue.
The current state of this project
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=31718.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Daniel Fagerstrom wrote:
Leszek and I have started refactoring JXTG, by breaking it up in its
subclasses. Later we will work on creating more detailed interfaces
between the different parts and all the other stuff that has been
discussed on the list.
Now the question is: where should this work
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=32541.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Leszek Gawron wrote:
snip/
I have commited an initial JXTemplateGenerator to
o.a.c.template.jxtg.JXTemplateGenerator and moved Jonas' templating
proposal to o.a.c.template.v2 package.
Please review.
Nice!
Don't have time to review in any detail right now. I added some basic
test cases. Two of
Daniel Fagerstrom wrote:
Leszek Gawron wrote:
snip/
I have commited an initial JXTemplateGenerator to
o.a.c.template.jxtg.JXTemplateGenerator and moved Jonas' templating
proposal to o.a.c.template.v2 package.
Please review.
Nice!
I am totally busy right now. I'll try to look into your test
Daniel Fagerstrom wrote:
snip/
For further refactoring I think that we should ...
Even more important is of course to add lots of test cases, so that we
ensure high quality. For those who have corrected more or less subtle
bugs in JXTG, consider adding a test case for it so that we can avoid
I'd just use eclipse to find every class that implements the right
interface(s). Would that work?
Geoff
On Thu, 09 Dec 2004 10:46:36 +1100, David Crossley [EMAIL PROTECTED] wrote:
I am trying to create a list of all sitemap
components in the Cocoon core and blocks.
So far i have tried to
Geoff Howard wrote:
I'd just use eclipse to find every class that implements the right
interface(s). Would that work?
Or, what we need is a tool that lists all the interfaces that a class
implements. Hmm. Javadoc. For the CastorTransformer, you get a line saying:
*All Implemented
[EMAIL PROTECTED] wrote:
Author: lgawron
Added:
cocoon/trunk/src/blocks/template/java/org/apache/cocoon/template/jxtg/JXTemplateGenerator.java
Url:
http://svn.apache.org/viewcvs/cocoon/trunk/src/blocks/template/java/org/apache/cocoon/template/jxtg/JXTemplateGenerator.java?view=autorev=111375
Le 9 déc. 04, à 00:46, David Crossley a écrit :
I am trying to create a list of all sitemap
components in the Cocoon core and blocks...
Doesn't qdox list the interfaces that a class implements?
If it's the case, it should be possible to create a pipeline (using the
qdox block) or use the qdox ant
Bertrand Delacretaz wrote:
Le 9 déc. 04, à 00:46, David Crossley a écrit :
I am trying to create a list of all sitemap
components in the Cocoon core and blocks...
Doesn't qdox list the interfaces that a class implements?
If it's the case, it should be possible to create a pipeline (using
the
Dear All
I just migrated our projects to 2.1.6 and found that they were severely
affected by this new behaviour as all our generated XHTML has escaped
tabs, quotes etc. Thus I'd (I think we all do) appreciate clarity on
what the correct (and expected) behaviour of the serialisation is.
In the
Le 9 déc. 04, à 16:56, Upayavira a écrit :
...cd build/cocoon-2.1.7-dev/javadocs/
grep -rl SitemapModelComponent *
Good one! Here's the pretty listing then:
for i in $(grep -rl SitemapModelComponent * | grep org/apache)
do
echo $i | sed 's/\//\./g' | sed 's/\.html$//'
done
There's still a bit of
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon-block-template has an issue affecting its community integration.
This
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon-block-cron has an issue affecting its community integration.
This issue
I have some quite-large tables that i use for lookups (categories,
mostly, and prices). They fit pretty nicely in a DOM in memory, no
problem, and they almost never change.
Now, I want to access those from XSLT as a variable.
Normally, I would aggregate the source, and pass it in the input to
Pier Fumagalli wrote:
I have some quite-large tables that i use for lookups (categories,
mostly, and prices). They fit pretty nicely in a DOM in memory, no
problem, and they almost never change.
Now, I want to access those from XSLT as a variable.
Normally, I would aggregate the source, and
Geoff Howard wrote:
I'd just use eclipse to find every class that implements the right
interface(s). Would that work?
Thanks Geoff. However, command-line tools only
because i need to script it. Sorry, i forgot
to specify that.
--David
I could be way off, but...
Have you tried including the data in the stylesheet itself and using
document() to self-reference?
.micah
Pier Fumagalli wrote:
I have some quite-large tables that i use for lookups (categories,
mostly, and prices). They fit pretty nicely in a DOM in memory, no
Hello,
my application heavily relies on stream that I use through cinclude post.
I saw there was a problem when I test the 2.1.6, as reported in bug
32491. I saw the explanation about the bug but I didn't understand
anything...
Just a question. When I have a chance to see this bug solved ?
Pier Fumagalli wrote:
I have some quite-large tables that i use for lookups (categories,
mostly, and prices). They fit pretty nicely in a DOM in memory, no
problem, and they almost never change.
Now, I want to access those from XSLT as a variable.
Normally, I would aggregate the source, and
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=32620.
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://issues.apache.org/bugzilla/show_bug.cgi?id=32620.
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://issues.apache.org/bugzilla/show_bug.cgi?id=32620.
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://issues.apache.org/bugzilla/show_bug.cgi?id=32620.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Vadim Gritsenko said:
Pier Fumagalli wrote:
Is there something like that in Cocoon (allow to pass a full DOM as a
parameter to the XSLT processor) or shall I start coding?
Probably that's what you want:
http://issues.apache.org/bugzilla/show_bug.cgi?id=9916
And no, it's not here yet.
Bertrand Delacretaz wrote:
Upayavira a écrit :
...cd build/cocoon-2.1.7-dev/javadocs/
grep -rl SitemapModelComponent *
Good one! Here's the pretty listing then:
for i in $(grep -rl SitemapModelComponent * | grep org/apache)
do
echo $i | sed 's/\//\./g' | sed 's/\.html$//'
done
There's still a
(at least those which have problems ;-)
http://www.google.ch/search?
q=%22internal%20server%20error%22%20org.apache.cocoon
-Bertrand
smime.p7s
Description: S/MIME cryptographic signature
97 matches
Mail list logo
