Reinhard P?tz wrote:
>
> Currently the proposed artifacts can only be tested either with latest
> trunk or Corona.
Actual testing is beyond me.
> You can find the staged files for all modules (sources, binaries,
> javadocs, checksums, gpg signatures) at
I verified all checksums for *.tar.gz a
Please cast your votes.
+1
Felix
Error in comment causes confusing documentation to be generated
---
Key: COCOON-2232
URL: https://issues.apache.org/jira/browse/COCOON-2232
Project: Cocoon
Issue Type: Bug
Grzegorz Kossakowski wrote:
>
> Please cast your votes:
+1
-David
Reinhard P?tz wrote:
> Grzegorz Kossakowski wrote:
> >
> >I believe that this dependency was stored on our snapshots repository,
> >but now it seems to be empty, see:
> >http://people.apache.org/repo/m2-snapshot-repository/org/apache/commons/javaflow/
> >
> >
> >More interesting thing is that, it
Ralph Goers wrote:
Carsten Ziegeler wrote:
Ralph Goers wrote:
Carsten Ziegeler wrote:
Ralph Goers wrote:
It uses the relative path so you will need the parent also.
Hmm, I'm not sure if this is a good idea :) as it permits building
a module standalone.
For Cocoon we have the dream (tm)
On Aug 7, 2008, at 10:29 AM, Mark Lundquist wrote:
All right then — well, how would I make a Cocoon webapp that can
serve the samples blocks, and which uses the reloading classloader?
Don't answer that, I'm gonna try to figure it out on my own. I'll ask
again if I get stuck :-)
cheers,
On Aug 7, 2008, at 10:13 AM, Reinhard Pötz wrote:
Mark Lundquist wrote:
The subject says it all :-)
Thx-in-advance,
—ml—
The reloading classloader is only integrated with the prepare goal
of the Cocoon Maven plugin. And the prepare goal creates a simple
wrapper web application for a bloc
Mark Lundquist wrote:
The subject says it all :-)
Thx-in-advance,
—ml—
The reloading classloader is only integrated with the prepare goal of
the Cocoon Maven plugin. And the prepare goal creates a simple wrapper
web application for a block.
In regard of your question this means that there
The subject says it all :-)
Thx-in-advance,
—ml—
smime.p7s
Description: S/MIME cryptographic signature
On Mon, Aug 4, 2008 at 1:46 PM, Grzegorz Kossakowski <[EMAIL PROTECTED]> wrote:
> ...I would like to propose David Legg as a new Cocoon committer and PMC
> Member
+1
-Bertrand
Carsten Ziegeler wrote:
Ralph Goers wrote:
Carsten Ziegeler wrote:
Ralph Goers wrote:
It uses the relative path so you will need the parent also.
Hmm, I'm not sure if this is a good idea :) as it permits building a
module standalone.
For Cocoon we have the dream (tm) to have separate
bu
On Aug 6, 2008, at 5:17 AM, Reinhard Pötz wrote:
Reinhard Pötz wrote:
I agree with you that we shouldn't support such stuff but what
features do we want to see in a new LinkRewriteTransformer? (...
hence my suggestion that we start with a
ServletLinkRewriteTransformer because we know that
On Aug 6, 2008, at 7:19 AM, Reinhard Pötz wrote:
Following the result of our recent discussion about the future of
Corona, I propose Corona to become Cocoon 3.
This means that any reference on Corona in source files, package
names, artifact ids, group ids or anywhere else will be dropped a
On Aug 5, 2008, at 9:07 AM, Grzegorz Kossakowski wrote:
As discussed in thread "Cocoon-jms-sample requires Java >= 1.5"[1]
there are more and more problems with keeping Java 1.4 compatibility
in trunk.
After a while it turned out that everybody agrees on the need for
dropping Java 1.4 com
Ralph Goers wrote:
Carsten Ziegeler wrote:
Ralph Goers wrote:
It uses the relative path so you will need the parent also.
Hmm, I'm not sure if this is a good idea :) as it permits building a
module standalone.
For Cocoon we have the dream (tm) to have separate
buildable/deployable modules
Carsten Ziegeler wrote:
Ralph Goers wrote:
It uses the relative path so you will need the parent also.
Hmm, I'm not sure if this is a good idea :) as it permits building a
module standalone.
For Cocoon we have the dream (tm) to have separate
buildable/deployable modules one day.
Carsten
17 matches
Mail list logo