Carsten Ziegeler wrote:
Reinhard Poetz wrote:
Reinhard Poetz wrote:
On a separate issue, as David pointed out some time ago, we have to make
the files available at http://www.apache.org/dist/cocoon/ too. This also
requires signing the files with PGP. Can somebody take care of this please?
Any
Reinhard Poetz wrote:
Since we are releasing artifacts separatly, the cocoon/tags directory in
our SVN gets crowded and I guess that in a couple of months we will have
hundrets of subdirectories there. We should find some way to reduce this
number.
My first idea was using the year and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Reinhard Poetz wrote:
I have compiled a release of following artifacts
- org.apache.cocoon:cocoon:2
- org.apache.cocoon:cocoon-core-modules:2
- org.apache.cocoon:cocoon-core:1.0.0-M2
- org.apache.cocoon:cocoon-blocks-modules:2
-
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Carsten Ziegeler wrote:
Vadim Gritsenko wrote:
Carsten Ziegeler wrote:
Have a look at the core.properties file in the cocoon-core module. Just
put a properties file with the appropriate configuration into
WEB-INF/cocoon/properties. This should
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Marc Portier wrote:
Reinhard Poetz wrote:
Since we are releasing artifacts separatly, the cocoon/tags directory in
our SVN gets crowded and I guess that in a couple of months we will have
hundrets of subdirectories there. We should find some
Giacomo Pati wrote:
This raises the question if we need this? I think we should readd the
support for reading properties from WEB-INF/cocoon/properties.
IIRC we mentioned putting those into
WEB-INF/classes/META-INF/cocoon/properties
Yes, you're absolutely right! This brings back my
Giacomo Pati wrote:
One little fix I have encountered yesterday and fixed it this morning. The
deployer-plugin was not
applying xpatches in case of packagingwar/packageing (I thought this was
not intended, right?).
The deployer plugin hasn't been released this time. I want to work on a
Giacomo Pati wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Marc Portier wrote:
Reinhard Poetz wrote:
Since we are releasing artifacts separatly, the cocoon/tags directory in
our SVN gets crowded and I guess that in a couple of months we will have
hundrets of subdirectories there. We
[
http://issues.apache.org/jira/browse/COCOON-1437?page=comments#action_12457683
]
Jeroen Reijn commented on COCOON-1437:
--
This seems to be fixed cocoon 2.1.10. I've tried it with a small webapp and it
seems to work.
Htmlarea lost
Luca Morandini wrote:
Remember to update the comments in the source code of
SettingsBeanFactoryPostProcessor.java then, because they still state
that WEB-INF/cocoon/properties is supported in the fall-back chain of
properties loading.
Yepp, thanks for the info - I'll take care of it in
Carsten Ziegeler wrote:
Luca Morandini wrote:
One issue, though: since the property loading mechanism uses
classpath:° protocol, property files are read in alphabetical order,
which means I might have my per-project properties ruined by the
addition of a block, unless I call them
Luca Morandini schrieb:
Carsten Ziegeler wrote:
Luca Morandini wrote:
One issue, though: since the property loading mechanism uses
classpath:° protocol, property files are read in alphabetical order,
which means I might have my per-project properties ruined by the
addition of a block,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Reinhard Poetz wrote:
Giacomo Pati wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Marc Portier wrote:
Reinhard Poetz wrote:
Since we are releasing artifacts separatly, the cocoon/tags
directory in
our SVN gets crowded and I guess
Giacomo Pati wrote:
Carsten Ziegeler wrote:
Luca Morandini wrote:
This was neatly solved by the use of WEB-INF/cocoon/properties, since it
was loaded after the classpath:* chain.
Yes, you're right. Hmm, perhaps we should load properties from
WEB-INF/classes last. I'll have a look at that
Carsten Ziegeler wrote:
Luca Morandini schrieb:
Carsten Ziegeler wrote:
Luca Morandini wrote:
This was neatly solved by the use of WEB-INF/cocoon/properties, since it
was loaded after the classpath:* chain.
Yes, you're right. Hmm, perhaps we should load properties from
WEB-INF/classes
On Dec 12, 2006, at 7:33 AM, Luca Morandini wrote:
In truth, I don't find the use of classes for configuration stuff
done outside JARs particularly intuitive...
+1
—ml—
Hi Carsten,
maybe I'm missing something, but isn't there a ProcessInfoProvider, with
which you can access request, response, servlet context and object model
(and from there all the rest)?
It ends in a thread local anyway, since uses the environment stack
Daniel told about.
If this is not the
Reinhard Poetz wrote:
Reinhard Poetz wrote:
On a separate issue, as David pointed out some time ago, we have to
make the files available at http://www.apache.org/dist/cocoon/ too.
I'd say the jar files (cocoon-core, cocoon-template-impl,
cocoon-flowscript-impl, cocoon-blocks-fw-impl) only.
Marc Portier wrote:
Reinhard Poetz wrote:
Since we are releasing artifacts separatly, the cocoon/tags directory in
our SVN gets crowded and I guess that in a couple of months we will have
hundrets of subdirectories there. We should find some way to reduce this
number.
My first idea was using
Mark Lundquist wrote:
On Dec 12, 2006, at 7:33 AM, Luca Morandini wrote:
In truth, I don't find the use of classes for configuration stuff
done outside JARs particularly intuitive...
+1
me-too/
Vadim
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
Reinhard Poetz wrote:
On a separate issue, as David pointed out some time ago, we have to
make the files available at http://www.apache.org/dist/cocoon/ too.
I'd say the jar files (cocoon-core, cocoon-template-impl,
cocoon-flowscript-impl,
On Mon, 2006-12-11 at 14:55 +0100, Carsten Ziegeler wrote:
7. Make sure you describe your test environment: Platform and JVM,
including version numbers.
The following blocks do not compile with Sun JDK 1.3.1_19:
-- databases: import javax.sql cannot be resolved
-- imageop: import
Reinhard Poetz wrote:
Giacomo Pati wrote:
One little fix I have encountered yesterday and fixed it this
morning. The deployer-plugin was not
applying xpatches in case of packagingwar/packageing (I thought
this was not intended, right?).
The deployer plugin hasn't been released this time. I
Luca Morandini wrote:
So, the chain you propose is (sorted by order of loading):
1) WEB-INF/classes/META-INF/cocoon/properties (block-wide stuff).
2) WEB-INF/classes/cocoon/properties (project-wide stuf).
In truth, I don't find the use of classes for configuration stuff
done outside JARs
On Wed, 13 Dec 2006, Simone Gianni wrote:
Date: Wed, 13 Dec 2006 01:32:24 +0100
From: Simone Gianni [EMAIL PROTECTED]
Reply-To: dev@cocoon.apache.org
To: dev@cocoon.apache.org
Subject: Re: [vote] Releasing from trunk (cocoon-core-2.2.0-M2 and others)
Reinhard Poetz wrote:
Giacomo Pati wrote:
Reinhard Poetz wrote:
Please cast your votes, whether we want to publish these artifacts to the
official Maven repository and make the release official. The vote is open
for 72 hours.
-1
I tried to raise these issues when Reinhard proposed the release plan.
The procedure is not being
On 12/13/06, Alfred Nathaniel [EMAIL PROTECTED] wrote:
...Shall we say that 2.1.10 is the last 1.3 compatible release? Or even
that 2.1.9 is already the last one?...
If no one's willing to fix 2.1.10 for JDK 1.3, I agree to stop
supporting 1.3 officially. But IIRC we've been saying for a
27 matches
Mail list logo
