Ok, it seems that we are all in favour of restructuring our directory
structure for 2.2.
Could someone please write/run a script that does the work? The final
result should be:
META-INF/cocoon/xconf/**
META-INF/cocoon/spring/**
META-INF/cocoon/properties/**
Thanks
Carsten
--
Carsten
introduced two SNAPSHOT dependencies that are in NO repository yet!!! (to
compile you need to compile jci and javaflow trunk ...will try to fix that soon
...or whoever has more time to fix that),
How can we fix that? I guess we need a release of jci and javaflow, right?
Well, that would be
Can someone PLEASE either add these dependencies to a reachable
repository or uncomment the stuff. This blocks everyone trying to do
some development on Cocoon as event cocoon-bootstrap is not compilable.
Thanks
Carsten
Torsten Curdt schrieb:
introduced two SNAPSHOT dependencies that are in NO
Online report :
http://cocoon.zones.apache.org:12000/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/30/buildId/393
Build statistics:
State: Ok
Previous State: Failed
Started at: Thu, 2 Nov 2006 12:08:27 +
Finished at: Thu, 2 Nov 2006 12:08:44 +
Total
[
http://issues.apache.org/jira/browse/COCOON-1939?page=comments#action_12446657
]
Alexander Klimetschek commented on COCOON-1939:
---
Now it behaves like in the beginning, 2-level inheritance does not work. The
polymorphic calls do
Lars Trieloff skrev:
Checking for a class doesn't seem to be a good idea I think we should
check for an interface instead.
Implemented.
Maybe we instead could make the DispatcherServlet less intrusive on
the request object by modifying the getServletPath() and getPathInfo()
on the
Carsten Ziegeler wrote:
b) META-INF/legacy/xconf/** - Block specific avalon config files
c) META-INF/legacy/sitemap-additions/** - Block specific avalon config
files for sitemap components
d) META-INF/spring/** - Block specific spring config files
e)
Reinhard Poetz wrote:
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
do we establish any contracts? I guess the only thing is the includes
in cocoon.xconf, right?
Yes.
let's implement your solution c). If somebody comes up with something
better before we release the final 2.2, we can
Carsten Ziegeler wrote:
Before we start changing directory structures, I think it makes sense to
vote.
The proposal is to use the following directory structure inside a block jar:
COB-INF - resources
META-INF/cocoon/xconf/**
META-INF/cocoon/spring/**
META-INF/cocoon/properties/**
Please cast
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
Joerg Heinicke wrote:
IMHO this is too fast. We did not receive any feedback on the 2.2 stuff
from any non-committer (only people working with committers). We should
run through some release candidates first, which gives the users the
Vadim Gritsenko skrev:
Daniel Fagerstrom wrote:
Alexander Klimetschek skrev:
the ResourceReader must throw any IOException caught in generate()
(line 349). This is currently not done because it looks like there
are cases, where a failed generate should be silently ignored. The
debug message
Torsten Curdt wrote:
No ...that requires a vote from the jakarta PMC the only thing we
could do is get a snaphot out into a repository ...or get some people
help over in jakarta land (hint!) ;-)
I installed a snapshot version of both jci and javaflow trunk to
m2-snapshot-repository,
On Thu, 2 Nov 2006, Leszek Gawron wrote:
Date: Thu, 02 Nov 2006 22:14:32 +0100
From: Leszek Gawron [EMAIL PROTECTED]
Reply-To: dev@cocoon.apache.org
To: dev@cocoon.apache.org
Subject: Re: Release roadmap
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
Joerg Heinicke wrote:
IMHO this is
Alexander Klimetschek skrev:
Hi Daniel,
we are noticing that the blocks protocol is currently quite slow. We did
not yet got a proper profiling setup, so I am asking if you know what
the bottlenecks might be and how to resolve them.
While I have not optimized the code there is no obvious
Leszek Gawron wrote:
My intention for i) was the ability for the block to contribute to
web.xml. You can create yourself a OpenSessionInViewBlock.jar which,
during deployment, will automatically enable the proper filter in
web.xml. As my web.xmls in different projects stay very alike I
2 weeks ago, Arje posted a long list of things that need to be improved with our
website and documentation. I can't say that all the things are resolved but
Helma and I have made good progress:
- Following the split up of Cocoon (the code) we also split up the
documentation into much
16 matches
Mail list logo
