Re: [2.2] Deployment and the maven plugin

2006-11-03 Thread Leszek Gawron
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

Re: [2.2] Deployment and the maven plugin

2006-11-03 Thread Carsten Ziegeler
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

Re: [2.2] Deployment and the maven plugin

2006-11-02 Thread Leszek Gawron
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)

Re: [2.2] Deployment and the maven plugin

2006-11-02 Thread Leszek Gawron
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

Re: [Vote] Block artifact directory structure [was: Re: [2.2] Deployment and the maven plugin]

2006-11-02 Thread Leszek Gawron
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

Re: [2.2] Deployment and the maven plugin

2006-11-02 Thread Carsten Ziegeler
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

[Vote] Block artifact directory structure [was: Re: [2.2] Deployment and the maven plugin]

2006-10-31 Thread Carsten Ziegeler
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 --

Re: [Vote] Block artifact directory structure [was: Re: [2.2] Deployment and the maven plugin]

2006-10-31 Thread Giacomo Pati
-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/**

Re: [Vote] Block artifact directory structure [was: Re: [2.2] Deployment and the maven plugin]

2006-10-31 Thread Carsten Ziegeler
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/**

Re: [Vote] Block artifact directory structure [was: Re: [2.2] Deployment and the maven plugin]

2006-10-31 Thread Reinhard Poetz
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

Re: [Vote] Block artifact directory structure [was: Re: [2.2] Deployment and the maven plugin]

2006-10-31 Thread Bertrand Delacretaz
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

Re: [Vote] Block artifact directory structure [was: Re: [2.2] Deployment and the maven plugin]

2006-10-31 Thread Peter Hunsberger
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/**

Re: [Vote] Block artifact directory structure [was: Re: [2.2] Deployment and the maven plugin]

2006-10-31 Thread Vadim Gritsenko
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

Re: [Vote] Block artifact directory structure [was: Re: [2.2] Deployment and the maven plugin]

2006-10-31 Thread Andreas Hochsteger
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/**

Re: [Vote] Block artifact directory structure [was: Re: [2.2] Deployment and the maven plugin]

2006-10-31 Thread Joerg Heinicke
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

Re: [Vote] Block artifact directory structure [was: Re: [2.2] Deployment and the maven plugin]

2006-10-31 Thread Lars Trieloff
+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.

[2.2] Deployment and the maven plugin

2006-10-30 Thread Carsten Ziegeler
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

Re: [2.2] Deployment and the maven plugin

2006-10-30 Thread Joerg Heinicke
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

Re: [2.2] Deployment and the maven plugin

2006-10-30 Thread Carsten Ziegeler
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

Re: [2.2] Deployment and the maven plugin

2006-10-30 Thread Reinhard Poetz
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

Re: [2.2] Deployment and the maven plugin

2006-10-30 Thread Carsten Ziegeler
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/

Re: [2.2] Deployment and the maven plugin

2006-10-30 Thread Reinhard Poetz
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