I'm sorry if I broke something in trunk with the move to Spring or the
refactoring; I'm currently not aware of a problem as trunk is working
for me here on my machine. So if someone can come up with a bug
description or stack trace I can try to fix that (if time permits).
Apart from that, I'll
Jean-Baptiste Quenot schrieb:
Hello,
I'm trying to compile the JCR block and followed the instructions
in src/blocks/jcr/readme.txt. However, build fails complaining
that it cannot find JCR classes. So I moved lib/local/jcr-1.0.jar
to lib/core and it works... until the «
Guys,
I've read the threads and I think the observation that something (not
pointing fingers here) is blocking the move forward, is correct. I'm
sure all of you agree.
In the past there have been several discussions about roadmaps and
visions, but AFAICT none of them ended in a clear and
Reinhard Poetz wrote:
Daniel Fagerstrom wrote:
snip/
scr:component name=myApp
scr:implementation
class=org.apache.cocoon.blocks.osgi.BlockServlet/
scr:service
scr:provide interface=javax.servlet.Servlet/
/scr:service
scr:property name=path value=/test2/
Daniel Fagerstrom wrote:
Ralph Goers skrev:
Andrew Savory wrote:
Hi,
Ralph Goers wrote:
1. I'm pretty sure all the blocks have not been mavenized.
Is there a list of blocks to mavenise anywhere, with instructions of
how to do it? I don't mind helping with this.
The easy way to tell I
Andreas Hochsteger wrote:
Daniel Fagerstrom wrote:
Ralph Goers skrev:
Andrew Savory wrote:
Hi,
Ralph Goers wrote:
1. I'm pretty sure all the blocks have not been mavenized.
Is there a list of blocks to mavenise anywhere, with instructions of
how to do it? I don't mind helping with
* Carsten Ziegeler:
Jean-Baptiste Quenot schrieb:
I'm trying to compile the JCR block and followed the instructions
in src/blocks/jcr/readme.txt. However, build fails complaining
that it cannot find JCR classes.
Should be fixed now - the problem was that only jars in
Upayavira schrieb:
Andreas Hochsteger wrote:
Daniel Fagerstrom wrote:
Ralph Goers skrev:
Andrew Savory wrote:
Hi,
Ralph Goers wrote:
1. I'm pretty sure all the blocks have not been mavenized.
Is there a list of blocks to mavenise anywhere, with instructions of
how to do it? I don't mind
Andreas Hochsteger wrote:
Upayavira schrieb:
Andreas Hochsteger wrote:
Daniel Fagerstrom wrote:
Ralph Goers skrev:
Andrew Savory wrote:
Hi,
Ralph Goers wrote:
1. I'm pretty sure all the blocks have not been mavenized.
Is there a list of blocks to mavenise anywhere, with
Reinhard Poetz schrieb:
Andreas Hochsteger wrote:
I mocked-up a shell script which converts the directories from the
old blocks to the structure used by the new mavenized ones.
Don't expect too much, since there is still some more manual work to
do, but at least some easy parts can be
Carsten Ziegeler wrote:
Reinhard Poetz schrieb:
If a testcase gets broken *locally* by a developer, the developer should discuss
the change on [EMAIL PROTECTED] and then people can decide together how to proceed.
That should be the standard procedure in every development project, may it be
Andreas Hochsteger wrote:
Reinhard Poetz schrieb:
Andreas Hochsteger wrote:
I mocked-up a shell script which converts the directories from the
old blocks to the structure used by the new mavenized ones.
Don't expect too much, since there is still some more manual work to
do, but at least
Vadim Gritsenko wrote:
http://marc.theaimsgroup.com/?l=xml-cocoon-devw=2r=1s=Cocoon-2.1.X+Tests+Failureq=b
Nice statistics :) I was talking about the tests in trunk.
Carsten
Carsten Ziegeler wrote:
Vadim Gritsenko wrote:
http://marc.theaimsgroup.com/?l=xml-cocoon-devw=2r=1s=Cocoon-2.1.X+Tests+Failureq=b
Nice statistics :) I was talking about the tests in trunk.
Well if tests are/were ignored in stable branch, why trunk would be any better?
Vadim
I have a Java object I am using to generate links. It would make my
life easier if I could use it directly in my XSLT--even though it is
created outside of the XSLT system. Is it as easy as passing it in as a
parameter? Or is there some extra leg work necessary?
Berin Loritsch wrote:
I have a Java object I am using to generate links. It would make my
life easier if I could use it directly in my XSLT--even though it is
created outside of the XSLT system. Is it as easy as passing it in as a
parameter? Or is there some extra leg work necessary?
It's
Reinhard Poetz schrieb:
Andreas Hochsteger wrote:
Reinhard Poetz schrieb:
Andreas Hochsteger wrote:
I mocked-up a shell script which converts the directories from the
old blocks to the structure used by the new mavenized ones.
Don't expect too much, since there is still some more manual
Andreas Hochsteger schrieb:
Reinhard Poetz schrieb:
Andreas Hochsteger wrote:
Reinhard Poetz schrieb:
Andreas Hochsteger wrote:
I mocked-up a shell script which converts the directories from the
old blocks to the structure used by the new mavenized ones.
Don't expect too much, since
Andreas Hochsteger wrote:
Reinhard Poetz schrieb:
Andreas Hochsteger wrote:
Reinhard Poetz schrieb:
Andreas Hochsteger wrote:
I mocked-up a shell script which converts the directories from the
old blocks to the structure used by the new mavenized ones.
Don't expect too much, since
Andreas Hochsteger wrote:
After analyzing the old blocks in more details I found the following
common directories.
It would be great, if you (or someone else involved in developing the
new blocks) can finish the mapping below ...
ok, forget my last response. I'll change it in some points:
Reinhard Poetz schrieb:
Andreas Hochsteger wrote:
After analyzing the old blocks in more details I found the following
common directories.
It would be great, if you (or someone else involved in developing the
new blocks) can finish the mapping below ...
ok, forget my last response. I'll
Hi all,
in cocoon forms is actually not so easy to implement dynamic change of
widget state. It happens quite often to have a customer ask for things
like Phone number is required if they ask to be contacted by us, they
don't provide an email address and they are from Italy, while email is
[
http://issues.apache.org/jira/browse/COCOON-1207?page=comments#action_12370879
]
Simone Gianni commented on COCOON-1207:
---
Yep, IBM jdk/jre has a problem with enums pattern, but there is no possible
direct solution. See COCOON-1793 for a possible
I successfully built cocoon-linkrewriter using 'mvn package' with the
converted directory structure using the conversion script and 2 new and
one adopted pom file.
I wanted to attach them, but for some reasons my SMTP server rejected
them as SPAM. :-(
I used the following conventions for the
Andreas Hochsteger wrote:
I successfully built cocoon-linkrewriter using 'mvn package' with the
converted directory structure using the conversion script and 2 new and
one adopted pom file.
I wanted to attach them, but for some reasons my SMTP server rejected
them as SPAM. :-(
I used the
Automated build for cocoon-docs FAILED
Log attached.
--
Forrestbot run ended at 18 March 12:22 AM
Using Forrest 0.8-dev
Forrestbot administrator: ForrestBot
--
[echo]
... Forrest render START 2006-03-18 12:02:18
... Rendering docs in
[PATCH] Repeater events
---
Key: COCOON-1801
URL: http://issues.apache.org/jira/browse/COCOON-1801
Project: Cocoon
Type: New Feature
Components: Blocks: Forms
Versions: 2.1.9-dev (current SVN)
Reporter: Simone Gianni
Attachments:
Reinhard Poetz wrote:
I want to add some thoughts to Daniel's idea of writing some Ant script
for the build: trunk has been mavenized and split up into many modules.
The missing thing is some tool that will create a web application out of
a number of blocks. In a world of real blocks that's
28 matches
Mail list logo
