Carsten Ziegeler wrote:
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
Leszek Gawron wrote:
It sure is. I am setting up my tools/test cases like this:
Great! So we don't have to extract this stuff! Thanks for the info!
If you only pointed me to the location where cocoon/spring/* are
enumerated I will do the necessary changes.
Ok, I just added initial
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
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
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 your votes.
Carsten
--
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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/**
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/**
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
On 10/31/06, Carsten Ziegeler [EMAIL PROTECTED] wrote:
...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/**...
+1
-Bertrand
On 10/31/06, Carsten Ziegeler [EMAIL PROTECTED] 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/**
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
2006/10/31, Carsten Ziegeler [EMAIL PROTECTED]:
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/**
On 31.10.2006 08:59, Carsten Ziegeler wrote:
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/**
+1
Jörg
+1
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 your votes.
The current version of trunk is feature complete; we only have one item
left which we discussed briefly at the GetTogether and a little bit more
in the past weeks in this mailing list: removing the need of the maven
deploy plugin.
There is one major advantage: make the use of maven 2 for building
Carsten Ziegeler cziegeler at apache.org writes:
So the final part is how to avoid the maven deploy plugin? We recently
discussed a possible solution which works using some classloader
functionality, some new protocols and so on and does not require any
extraction of files during deployment
Joerg Heinicke wrote:
Carsten Ziegeler cziegeler at apache.org writes:
So the final part is how to avoid the maven deploy plugin? We recently
discussed a possible solution which works using some classloader
functionality, some new protocols and so on and does not require any
extraction of
Carsten Ziegeler wrote:
The current version of trunk is feature complete; we only have one item
left which we discussed briefly at the GetTogether and a little bit more
in the past weeks in this mailing list: removing the need of the maven
deploy plugin.
There is one major advantage: make the
Reinhard Poetz wrote:
do we establish any contracts? I guess the only thing is the includes in
cocoon.xconf, right?
Yes.
Carsten
--
Carsten Ziegeler - Open Source Group, SN AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
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 change it, otherwise we go
22 matches
Mail list logo