Carsten Ziegeler wrote:
Nice,
to avoid all legal problems - what would it take to use this version in
2.1.x?
a vote ;-)
IIRC Rhino 1.6 is binary compatible to the version we use in 2.1
I know that this might introduce some incompatibilities, but
perhaps we can live with them?
not sure,
Reinhard Poetz wrote:
Carsten Ziegeler wrote:
Nice,
to avoid all legal problems - what would it take to use this version in
2.1.x?
a vote ;-)
Ah, right, thanks :)
IIRC Rhino 1.6 is binary compatible to the version we use in 2.1
Hmm, I'm not sure - I think we had to change some parts in
Carsten Ziegeler wrote:
Yes, and that's exactly the question, if we want go this road. Now if
people are upgrading to 2.2 in the future they have to live with these
changes anyway.
Right, but there is a difference between doing an upgrade from one patch release
to another or to a new minor
Reinhard Poetz wrote:
Carsten Ziegeler wrote:
Nice,
to avoid all legal problems - what would it take to use this version in
2.1.x?
a vote ;-)
IIRC Rhino 1.6 is binary compatible to the version we use in 2.1
Not totally. The exception and stacktrace handling code is a bit
different, but
John Krofcheck wrote:
Can anyone point me to a snapshot of 2.2 that compiles successfully?
(I'm thinking that would be the best place to get started with 2.2, then
contribute to the documentation and eventually maybe the code, as I work
my way through).
Currently no dev snapshots are
Sylvain Wallez wrote:
AFAIK these features were never explicitely mentioned in our docs, so
not official, and thus certainly not widely used. It may be worth it to
be legally clean at the price of very few compatibility problems.
Yepp, I think being legally clean is more important here.
If
On 11/16/06, Sylvain Wallez [EMAIL PROTECTED] wrote:
...It may be worth it to
be legally clean at the price of very few compatibility problems...
+1
-Bertrand
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
AFAIK these features were never explicitely mentioned in our docs, so
not official, and thus certainly not widely used. It may be worth it to
be legally clean at the price of very few compatibility problems.
Yepp, I think being legally
Hi,
I see this far too often whenever I try working with c2.2:
-Dmaven.test.skip=true
I mean, really why do we have tests if we tell everyone to build
Cocoon 2.2 without them?
So, suggestions:
- we set the build to by default skip tests
- we do not do a release until all
Andrew Savory wrote:
Hi,
I see this far too often whenever I try working with c2.2:
-Dmaven.test.skip=true
I mean, really why do we have tests if we tell everyone to build
Cocoon 2.2 without them?
So, suggestions:
- we set the build to by default skip tests
- we do
Carsten Ziegeler schrieb:
Anyways, I think we should try to fix all tests before a release. If we
turn them off by default we could also just remove them as noone will
care. (Though the tough question is of course if someone cares today)
As we use Cocoon as mission critical part of our
Alexander Klimetschek wrote:
Carsten Ziegeler schrieb:
Anyways, I think we should try to fix all tests before a release. If we
turn them off by default we could also just remove them as noone will
care. (Though the tough question is of course if someone cares today)
As we use Cocoon as
Ok, it seems we should vote on this topic. As you all know,
including the version of rhino in 2.1.x has legal problems
and we have to do something about it.
Fortunately, the latest version of Rhino is licenced under an acceptable
term, so we could include that version in 2.1.x. Unfortunately this
Carsten Ziegeler wrote:
Ok, it seems we should vote on this topic. As you all know,
including the version of rhino in 2.1.x has legal problems
and we have to do something about it.
Fortunately, the latest version of Rhino is licenced under an acceptable
term, so we could include that
On 11/16/06, Carsten Ziegeler [EMAIL PROTECTED] wrote:
...Please cast your votes for using latest rhino in 2.1.x...
+1
-Bertrand
On 16 Nov 2006, at 12:22, Bertrand Delacretaz wrote:
On 11/16/06, Carsten Ziegeler [EMAIL PROTECTED] wrote:
...Please cast your votes for using latest rhino in 2.1.x...
ditto, my +1
regards Jeremy
smime.p7s
Description: S/MIME cryptographic signature
Leszek Gawron wrote:
Carsten Ziegeler wrote:
Ok, it seems we should vote on this topic. As you all know,
including the version of rhino in 2.1.x has legal problems
and we have to do something about it.
Fortunately, the latest version of Rhino is licenced under an acceptable
term, so we
Please cast your votes for using latest rhino in 2.1.x.
+1
Carsten
--
Carsten Ziegeler - Chief Architect
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Leszek Gawron wrote:
Carsten Ziegeler wrote:
Ok, it seems we should vote on this topic. As you all know,
including the version of rhino in 2.1.x has legal problems
and we have to do something about it.
Fortunately, the latest version of Rhino is licenced under an acceptable
term, so we
Carsten Ziegeler wrote:
Please cast your votes for using latest rhino in 2.1.x.
+1
Sylvain
--
Sylvain Wallez - http://bluxte.net
Carsten Ziegeler wrote:
Ok, it seems we should vote on this topic. As you all know,
including the version of rhino in 2.1.x has legal problems
and we have to do something about it.
Fortunately, the latest version of Rhino is licenced under an acceptable
term, so we could include that
Sylvain Wallez wrote:
Leszek Gawron wrote:
Carsten Ziegeler wrote:
Ok, it seems we should vote on this topic. As you all know,
including the version of rhino in 2.1.x has legal problems
and we have to do something about it.
Fortunately, the latest version of Rhino is licenced under an
Carsten Ziegeler wrote:
Ok, it seems we should vote on this topic. As you all know,
including the version of rhino in 2.1.x has legal problems
and we have to do something about it.
Fortunately, the latest version of Rhino is licenced under an acceptable
term, so we could include that version in
On Thu, 2006-11-16 at 13:11 +0100, Carsten Ziegeler wrote:
Ok, it seems we should vote on this topic. As you all know,
including the version of rhino in 2.1.x has legal problems
and we have to do something about it.
Fortunately, the latest version of Rhino is licenced under an acceptable
Carsten Ziegeler wrote:
Please cast your votes for using latest rhino in 2.1.x.
+1
Vadim
Jorg Heymans wrote:
John Krofcheck wrote:
jorg:~/src/cocoon-trunk $ cd core/cocoon-webapp/
Or 'cd dists/cocoon-dist-samples' if you want to see anything beside 'welcome'
page.
Vadim
jorg:~/src/cocoon-trunk/core/cocoon-webapp $ mvn jetty:run
.
Carsten Ziegeler wrote:
Ok, it seems we should vote on this topic. As you all know,
including the version of rhino in 2.1.x has legal problems
and we have to do something about it.
Fortunately, the latest version of Rhino is licenced under an acceptable
term, so we could include that version in
On 11/16/06, Carsten Ziegeler [EMAIL PROTECTED] wrote:
Please cast your votes for using latest rhino in 2.1.x.
+1 - we're pretty dependant on the current implementation of flow but
I can't imagine that anythign will break that we can't easily fix.
--
Peter Hunsberger
+1
Carsten Ziegeler wrote:
Ok, it seems we should vote on this topic. As you all know,
including the version of rhino in 2.1.x has legal problems
and we have to do something about it.
Fortunately, the latest version of Rhino is licenced under an acceptable
term, so we could include that
[EMAIL PROTECTED] wrote:
Author: ltrieloff
Date: Wed Nov 15 14:36:29 2006
New Revision: 475471
URL: http://svn.apache.org/viewvc?view=revrev=475471
Log:
update to correct excalibur-sourceresolve dependency
Modified:
cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/pom.xml
Modified:
Hi All
I am close to finishing an UploadProgressBar Dojo Widget for CForms
and am trying to implement i18n status messages.
I have a FlowScript that reads the upload status and sends this as
JSON to the UploadProgressBar.
I was trying to avoid using JXTemplate for the serialization,
Daniel Fagerstrom schrieb:
blockcontext:/blockname/ - resolves to a file source that contain the
COB-INF directory of the block.
What is the blockname? I tried the name of the directory (like
previously in /blocks/my-block/ = my-block), a name=my-block in the
bean and the id of the bean as
Alexander Klimetschek wrote:
Daniel Fagerstrom schrieb:
blockcontext:/blockname/ - resolves to a file source that contain the
COB-INF directory of the block.
What is the blockname? I tried the name of the directory (like
previously in /blocks/my-block/ = my-block), a name=my-block in the
Reinhard Poetz schrieb:
Alexander Klimetschek wrote:
Daniel Fagerstrom schrieb:
blockcontext:/blockname/ - resolves to a file source that contain the
COB-INF directory of the block.
What is the blockname? I tried the name of the directory (like
previously in /blocks/my-block/ = my-block), a
Carsten Ziegeler wrote:
Ok, it seems we should vote on this topic. As you all know,
including the version of rhino in 2.1.x has legal problems
and we have to do something about it.
Fortunately, the latest version of Rhino is licenced under an acceptable
term, so we could include that version in
Looks like my webapp configuration does not fit with the new deploying
mechanism. I just copied the new cocoon.xconf in my WEB-INF/cocoon/ dir,
thinking that the source factory config was not loaded correctly, but
this did not help either.
So what else is needed to use the new configuration
Jeremy Quinn wrote:
Hi All
I am close to finishing an UploadProgressBar Dojo Widget for CForms and
am trying to implement i18n status messages.
I have a FlowScript that reads the upload status and sends this as JSON
to the UploadProgressBar.
I was trying to avoid using JXTemplate for the
On 16 Nov 2006, at 16:55, Vadim Gritsenko wrote:
Jeremy Quinn wrote:
Hi All
I am close to finishing an UploadProgressBar Dojo Widget for
CForms and am trying to implement i18n status messages.
I have a FlowScript that reads the upload status and sends this as
JSON to the
Hi all!!
I want to generate a PDF with a digital signature. I have found a Java
example that do the work:
http://itextpdf.sourceforge.net/howtosign.html#howtosign
How can i integrate this with Cocoon?
I have worked with custom generators, but never with serializers ...
Thanks in advance
--
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Carsten Ziegeler wrote:
Please cast your votes for using latest rhino in 2.1.x.
+1
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-BEGIN PGP SIGNATURE-
Version:
Rice Yeh skrev:
Hi,
In studying the document
http://wiki.apache.org/cocoon-data/attachments/GT2006Notes/attachments/12-CocoonBlocks.pdf
http://wiki.apache.org/cocoon-data/attachments/GT2006Notes/attachments/12-CocoonBlocks.pdf,
I like to have a real feeling of it. So I try the
Carsten Ziegeler skrev:
...
Please cast your votes for using latest rhino in 2.1.x.
+1
/Daniel
Alexander Klimetschek skrev:
Daniel Fagerstrom schrieb:
blockcontext:/blockname/ - resolves to a file source that contain the
COB-INF directory of the block.
What is the blockname? I tried the name of the directory (like
previously in /blocks/my-block/ = my-block), a name=my-block in the
A not very nice, but workable method is:
- create a buffering output stream at setOutputStream(out) and pass that to the
super, while saving a reference to the output stream that is passed as
parameter for later.
- close and read the buffered output at endDocument(), passing it to your
signing
On 16.11.2006 13:11, Carsten Ziegeler wrote:
Please cast your votes for using latest rhino in 2.1.x.
+1
Jörg
Andrew Savory wrote:
I see this far too often whenever I try working with c2.2:
-Dmaven.test.skip=true
I mean, really why do we have tests if we tell everyone to build
Cocoon 2.2 without them?
To give them the same user experience as the 2.1 build ? :-)
...
We aren't providing
Hi,
On 16 Nov 2006, at 12:11, Carsten Ziegeler wrote:
Please cast your votes for using latest rhino in 2.1.x.
+1
Thanks,
Andrew.
--
Andrew Savory, Managing Director, Luminas Limited
Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135
Web: http://www.luminas.co.uk/
Sourcesense:
Yes, while debugging I found out that without setting the manifest entry
Cocoon-Block-Name is the name of the jar without the suffix .jar, so
I got my-block-0.0.1-SNAPSHOT.
Apart from that my webapp/WEB-INF directory now contains my specific
web.xml, the applicationContext.xml from
Hi Daniel,
while updating to the latest Cocoon I stepped into the problem that you
cannot see the exceptions thrown in a BlockServlet called by another
one, since the new refactored RequestProcessor swallows all exceptions.
The generated error page is fed into the response output stream which
[Patch] RequestProcessor swallows exceptions in blocks case
---
Key: COCOON-1954
URL: http://issues.apache.org/jira/browse/COCOON-1954
Project: Cocoon
Issue Type: Bug
[ http://issues.apache.org/jira/browse/COCOON-1954?page=all ]
Alexander Klimetschek updated COCOON-1954:
--
Attachment: cocoon-request-processor-swallows-exceptions-for-blocks.patch
To be attached in the root of cocoon trunk. Affects the
Jorg Heymans wrote:
We aren't providing snapshot builds and people want to try out the new
features. This currently means they have to compile themselves. Failing
unit tests are a hurdle that might stop their attempt to explore
completely - the huge 'BUILD FAILED' banner at the end doesn't
Thank you. The Eclipse-Maven plugin removes comments and xml schema
references when adding dependencies using the GUI.
Am 16.11.2006 um 15:51 schrieb Vadim Gritsenko:
[EMAIL PROTECTED] wrote:
Author: ltrieloff
Date: Wed Nov 15 14:36:29 2006
New Revision: 475471
URL:
53 matches
Mail list logo
