Leszek Gawron wrote:
Just a few examples of what can be currently achieved only by patching:
- tweaking store janitor
- configuring transient store max objects
- configuring continuations manager
These three things could be configured through properties I guess. So
there shouldn't be a
Carsten Ziegeler wrote:
Leszek Gawron wrote:
Just a few examples of what can be currently achieved only by patching:
- tweaking store janitor
- configuring transient store max objects
- configuring continuations manager
These three things could be configured through properties I guess. So
Another feature request for Carsten. We have already discussed this once:
While testing a development block the properties from
/src/main/resources/META-INF/properties/* are not copied to webapp
directory. In order to load them properly we need include-properties/
also in cocoon.xconf
Leszek Gawron wrote:
Another feature request for Carsten. We have already discussed this once:
While testing a development block the properties from
/src/main/resources/META-INF/properties/* are not copied to webapp
directory. In order to load them properly we need include-properties/
Carsten Ziegeler wrote:
Leszek Gawron wrote:
Another feature request for Carsten. We have already discussed this once:
While testing a development block the properties from
/src/main/resources/META-INF/properties/* are not copied to webapp
directory. In order to load them properly we need
Leszek Gawron wrote
As long as it is configured automatically so the only thing that user
does is:
mvn clean compile cocoon:deploy jetty:run
I'm not that familiar with all aspects of the cocoon:deploy plugin, but
I thought that this one is deploying all files into the necessary locations?
Carsten Ziegeler wrote:
Leszek Gawron wrote
As long as it is configured automatically so the only thing that user
does is:
mvn clean compile cocoon:deploy jetty:run
I'm not that familiar with all aspects of the cocoon:deploy plugin, but
I thought that this one is deploying all files into
[
http://issues.apache.org/jira/browse/COCOON-1898?page=comments#action_12432499
]
Lars Trieloff commented on COCOON-1898:
---
Leszek,
there are some weak points in the XUpdate language, for example the
if-semantics are not yet defined.
Leszek Gawron wrote:
SNIP
The blocks consists of:
- COB-INF resources (covered with mount in sitemap)
- java classes (loaded on sitemap level with reloading classloader, now
gets me thinking it will break if block supplies some core spring beans)
- avalon contexts (covered by include in
[
http://issues.apache.org/jira/browse/COCOON-1898?page=comments#action_12432504
]
Leszek Gawron commented on COCOON-1898:
---
Concerning src/main/xpatch:
We have have agreed some time ago to keep all the specific cocoon resources in
Carsten Ziegeler wrote:
Leszek Gawron wrote:
SNIP
The blocks consists of:
- COB-INF resources (covered with mount in sitemap)
- java classes (loaded on sitemap level with reloading classloader, now
gets me thinking it will break if block supplies some core spring beans)
- avalon contexts
Carsten Ziegeler wrote:
Leszek Gawron wrote:
SNIP
The blocks consists of:
- COB-INF resources (covered with mount in sitemap)
- java classes (loaded on sitemap level with reloading classloader, now
gets me thinking it will break if block supplies some core spring beans)
- avalon contexts
Carsten Ziegeler wrote:
Carsten Ziegeler wrote:
Leszek Gawron wrote:
SNIP
The blocks consists of:
- COB-INF resources (covered with mount in sitemap)
- java classes (loaded on sitemap level with reloading classloader, now
gets me thinking it will break if block supplies some core spring
Leszek Gawron wrote:
Hmmm ... not really. And the system property solution would not also
work. Everything because you may mount more that one development block
directly from source:
plugin
groupIdorg.apache.cocoon/groupId
artifactIdcocoon-deployer-plugin/artifactId
Carsten Ziegeler skrev:
Leszek Gawron wrote:
...
- you won't even be able to define a new cforms widget definition
because they don't use the new service selector that allows to span
components over several files.
While some things are trivial to fix some are not and all definitely
need
FYI, I have created a calendar file at
http://svn.apache.org/repos/asf/cocoon/site/asf-calendar/
for display on http://asylum.zones.apache.org/rdfcal
Great, thanks Bertrand!
-- Arje
Hi Bertrand,
Do (potential) speakers have to register there as well?
Yes, please register on the website, even if you're thinking of doing a talk.
As usual, speakers will get a free pass. Please sign up but wait with the whole
Paypal procedure until you know whether you'll be talking or not.
I got a seat! Even made it through the Paypal forms in Dutch!
Aw.. Really? Is it always in Dutch? It shouldn't do that!
Do others have this as well??
-- Arje
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sun, 3 Sep 2006, Leszek Gawron wrote:
Date: Sun, 03 Sep 2006 20:00:15 +0200
From: Leszek Gawron [EMAIL PROTECTED]
Reply-To: dev@cocoon.apache.org
To: dev@cocoon.apache.org
Subject: Re: XPatch support for maven-cocoon-deployer-plugin
Reinhard
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sun, 3 Sep 2006, Leszek Gawron wrote:
Date: Sun, 03 Sep 2006 20:34:19 +0200
From: Leszek Gawron [EMAIL PROTECTED]
Reply-To: dev@cocoon.apache.org
To: dev@cocoon.apache.org
Subject: Re: XPatch support for maven-cocoon-deployer-plugin
Reinhard
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
No more usage of Avalon's LogEnabled and Contextualizable
Added:
cocoon/trunk/blocks/cocoon-portal/cocoon-portal-impl/src/main/java/org/apache/cocoon/portal/impl/AbstractLogEnabled.java
URL:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 4 Sep 2006, Arje Cahn wrote:
Date: Mon, 4 Sep 2006 19:34:56 +0200
From: Arje Cahn [EMAIL PROTECTED]
Reply-To: dev@cocoon.apache.org
To: dev@cocoon.apache.org
Subject: RE: Re: [GT2006] Registration is open! Cocoon GetTogether 2006 (Oct
Entity resolution in imported XSLT stylesheets does not use catalog
---
Key: COCOON-1907
URL: http://issues.apache.org/jira/browse/COCOON-1907
Project: Cocoon
Issue Type: Bug
23 matches
Mail list logo
