http://blogs.maven.org/jvanzyl/2006/10/05/1160062688005.html
Jorg
[
http://issues.apache.org/jira/browse/COCOON-831?page=comments#action_12440371 ]
Léon Tebbens commented on COCOON-831:
-
We found out that in our case the bug is caused bij Xalan issue 1640
Joerg Heinicke skrev:
On 06.10.2006 00:57, Antonio Gallardo wrote:
Why actually? What has unwrap to do with pipeline processing? If it
is because it is only used there then it makes only sense to move it
there if you also make it private. Otherwise it is a public method
and it should be seen
Yesterday I updated Cocoon 2.2 to Spring 2.0 final - and the big plus is
that the maven repository contains correct poms for this version :)
Apart from that the new property override configuration mechanism is now
in place as well. This means by default the spring application context
we add a
Carsten Ziegeler wrote:
Yesterday I updated Cocoon 2.2 to Spring 2.0 final - and the big plus is
that the maven repository contains correct poms for this version :)
Apart from that the new property override configuration mechanism is now
in place as well. This means by default the spring
Reinhard Poetz wrote:
hmm, why do we have another mechanism for setting properties now?. can't we
put
in all properties into WEB-INF/cocoon/properties?
This was actually my first implementation, but I think there is a
difference between properties which you might want to use for anything
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Carsten Ziegeler schrieb:
Reinhard Poetz wrote:
hmm, why do we have another mechanism for setting properties
now?. can't we put in all properties into
WEB-INF/cocoon/properties?
This was actually my first implementation, but I think there is a
Carsten Ziegeler schrieb:
Reinhard Poetz wrote:
hmm, why do we have another mechanism for setting properties now?. can't we
put
in all properties into WEB-INF/cocoon/properties?
This was actually my first implementation, but I think there is a
difference between properties which you might
Felix Knecht wrote:
How about the different environments (prod/dev/test) for spring bean
configuration? WIll they go to ../cocoon/properties directory or do we
need a ../cocoon/spring/properties directory as well?
It's not implemented yet, but I thought about reading them from
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
hmm, why do we have another mechanism for setting properties now?. can't we put
in all properties into WEB-INF/cocoon/properties?
This was actually my first implementation, but I think there is a
difference between properties which you might want
my +1
Welcome Lars !!
regards Jeremy
On 3 Oct 2006, at 15:01, Jean-Baptiste Quenot wrote:
Dear Community,
I think time has come for Lars Trieloff to become a Cocoon
committer, so he'll be able to commit his numerous patches
himself, including the last hair-pulling
Reinhard Poetz wrote:
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
hmm, why do we have another mechanism for setting properties now?. can't we
put
in all properties into WEB-INF/cocoon/properties?
This was actually my first implementation, but I think there is a
difference between
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
hmm, why do we have another mechanism for setting properties now?. can't we put
in all properties into WEB-INF/cocoon/properties?
This was actually my first implementation, but I think there is a
Leszek Gawron wrote:
[EMAIL PROTECTED] wrote:
Author: cziegeler
Date: Fri Oct 6 02:06:31 2006
New Revision: 453534
URL: http://svn.apache.org/viewvc?view=revrev=453534
Log:
Deployer plugin will run automatically
Modified:
Leszek Gawron wrote:
can we make a block out of cocoon's way of doing property handling so
one could use it in non cocoon projects?
Hmm, yes this should be possible. Currently it's tied to some Cocoon
stuff, but it should
be possible to separate this.
Carsten
--
Carsten Ziegeler - Open
Leszek Gawron wrote:
my bad .. I had cocoon:deploy plugin defined at parent pom so it ran
twice (still seems like a maven bug to me).
other problems still apply
Hmm, that's bad - I don't see a solution for this now. But we discussed
at the GT an alternative handling of our blocks which
Carsten Ziegeler wrote:
Leszek Gawron wrote:
my bad .. I had cocoon:deploy plugin defined at parent pom so it ran
twice (still seems like a maven bug to me).
other problems still apply
Hmm, that's bad - I don't see a solution for this now. But we discussed
at the GT an alternative handling
Leszek Gawron wrote:
Hmm, that's bad - I don't see a solution for this now. But we discussed
at the GT an alternative handling of our blocks which would make the
cocoon:deploy plugin obsolete.
which is ?
:)
Currently the deployer extracts the files from COB-INF and META-INF into
the file
We have done a lot of changes since M1 - we have a new Spring bridge,
updated to Spring 2.0 final, the dispatcher servlet etc. I think it
makes sense to release this stuff as M2.
WDYT?
Carsten
--
Carsten Ziegeler - Open Source Group, SN AG
http://www.s-und-n.de
On Fri, Oct 06, 2006 at 11:44:46AM +0200, Carsten Ziegeler wrote:
Yesterday I updated Cocoon 2.2 to Spring 2.0 final - and the big plus is
that the maven repository contains correct poms for this version :)
Hello Carsten,
Today I updated the sources from svn and tried a rebuild. Now I'm
Fred Vos wrote:
On Fri, Oct 06, 2006 at 11:44:46AM +0200, Carsten Ziegeler wrote:
Yesterday I updated Cocoon 2.2 to Spring 2.0 final - and the big plus is
that the maven repository contains correct poms for this version :)
Hello Carsten,
Today I updated the sources from svn and tried a
Hi All
We had an informal group discussion on Tuesday at the Hackathon about
CForms.
The purpose of the discussion was to find a consensus on the
direction to take CForms, so that everybody who would like to work on
it is hopefully going to take it in the same general direction.
These
[
http://issues.apache.org/jira/browse/COCOON-831?page=comments#action_12440484 ]
Henry Zongaro commented on COCOON-831:
--
Looking at the code in org.apache.cocoon.generation.ProfilerGenerator.generate,
which appears in Nils's traceback, I
On 06 Oct 2006, at 16:02, Fred Vos wrote:
Today I updated the sources from svn and tried a rebuild. Now I'm
getting this
error, which seems related to this update to Spring 2.0 final.
Here's the
output:
Are you using a settings.xml with a different mirror perhaps? I know
for a fact
Carsten Ziegeler wrote:
We have done a lot of changes since M1 - we have a new Spring bridge,
updated to Spring 2.0 final, the dispatcher servlet etc. I think it
makes sense to release this stuff as M2.
+1 I am using this cocoon in production quite long now.
--
Leszek Gawron
[EMAIL PROTECTED]
Carsten Ziegeler wrote:
Leszek Gawron wrote:
Hmm, that's bad - I don't see a solution for this now. But we discussed
at the GT an alternative handling of our blocks which would make the
cocoon:deploy plugin obsolete.
which is ?
:)
Currently the deployer extracts the files from COB-INF and
Jeremy Quinn said the following on 6/10/06 16:42:
Hi All
We had an informal group discussion on Tuesday at the Hackathon about
CForms.
The purpose of the discussion was to find a consensus on the direction
to take CForms, so that everybody who would like to work on it is
hopefully going to
Hi Jeremy,
I see the following ways to solve this:
- create a DojoReader that will dynamically compress and aggregate
Javascript on the fly.
- create a Maven Mojo that does the same job as Dojo's ant task, but
this needs to be configured at build time.
The first option needs no build time
[PATCH] Reloading classloader in Cocoon 2.2
---
Key: COCOON-1929
URL: http://issues.apache.org/jira/browse/COCOON-1929
Project: Cocoon
Issue Type: Task
Components: * Cocoon Core
Affects
[ http://issues.apache.org/jira/browse/COCOON-1929?page=all ]
Maurizio Pillitu updated COCOON-1929:
-
Attachment: cocoon.diff
Apply to cocoon 2.2 trunk folder
[PATCH] Reloading classloader in Cocoon 2.2
---
On 10/6/06, Carsten Ziegeler [EMAIL PROTECTED] wrote:
...I think it
makes sense to release this stuff as M2...
+0.9 (meaning I cannot help but go for it)
-Bertrand
Hi Lars
On 6 Oct 2006, at 18:49, Lars Trieloff wrote:
Hi Jeremy,
I see the following ways to solve this:
- create a DojoReader that will dynamically compress and aggregate
Javascript on the fly.
Amazing idea !! :)
- create a Maven Mojo that does the same job as Dojo's ant task,
but
[ http://issues.apache.org/jira/browse/COCOON-1706?page=all ]
Jean-Baptiste Quenot closed COCOON-1706.
Fix Version/s: 2.2-dev (Current SVN)
Resolution: Fixed
Committed revision 453749 with some modifications. Thanks for your nice
Hello Jeremy,
This is a nice CForms roadmap indeed. See my comment below:
* Jeremy Quinn:
3. We have two templating systems, there are incompatibilities
between them and different capabilities, can we deprecate one?
Conclusion: the JXMacro generation technique seems to be more
Hi,
The root pom is currently declaring modulesite/cocoon-maven-site-
skin/module directly. This is giving problems in continuum:
Cannot build maven project from /home/maven/continuum-1.0.3/temp/
continuum/repos/asf/cocoon/trunk/site/cocoon-maven-site-skin/pom.xml
(Cannot find parent:
35 matches
Mail list logo
