Re: [2.2] Deployment and the maven plugin
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 stay very alike I would
like to extract the common definitions into a reusable artifact.
This goes to any stuff that you need to put into web xml:
- filters
- listeners
- additional servlets (AFAIR some of the users used .xpath files to
include xindice servlets in web.xml)
My common design in: webapp depends on ui-block (contributes COB-INF)
depends on core block (contributes model and spring services) depends on
hibernate and opensessioninview (contributes filters to web.xml)
Ok, I see - obviously we can't patch the web.xml at runtime as its too
late then, so this has to be done during deployment (or packaging).
I think we could leave this functionality in the our plugin for now, but
I would love to have such support directly in the maven webapp plugin.
The same for the shielded classloading stuff. This would free us from
having to use Cocoon specific plugins for non-Cocoon specific things.
First of all: why don't we simply use spring functionality for that?
Spring has a nice resource resolution. Why don't we simply reference
classpath*:/META-INF/cocoon/spring/*.xml for context inclusion and
classpath*:/META-INF/cocoon/properties/*.properties,
classpath*:/META-INF/cocoon/properties/{currentmode}/*.properties
for properties resolution?
Does this work in Spring? I briefly looked at the code but did not find
support for patterns when using the classpath protocol. *If* this is
working we can directly read these files from within the jars without
need to extract anything. That should be simple.
It sure is. I am setting up my tools/test cases like this:
public abstract class AbstractSpringTool {
protected static final Log logger
= LogFactory.getLog( AbstractSpringTool.class );
protected ConfigurableApplicationContextcontext;
public AbstractSpringTool() {
this.context = new ClassPathXmlApplicationContext(
getContextLocation() );
this.context.getBeanFactory().autowireBeanProperties( this,
getAutowireType(),
false );
}
public String[] getContextLocation() {
return new String[] { classpath*:/META-INF/spring/*.xml };
}
public int getAutowireType() {
return AutowireCapableBeanFactory.AUTOWIRE_BY_NAME;
}
public abstract void run() throws Exception;
}
and property placeholders:
bean id=placeholderConfig
class=org.springframework.beans.factory.config.PropertyPlaceholderConfigurer
property name=locations
value=classpath*:META-INF/properties/*.properties/
/bean
works like a charm.
If you only pointed me to the location where cocoon/spring/* are
enumerated I will do the necessary changes.
You can even use ant style wildcards. The only thing you cannot do is
classpath*:*.xml. You have to at least reference a single directory in
the path. The appropriate docs can be found here [1]
Could the archetype stop putting cocoon.xconf into generated webapp?
It does not do this anymore (since monday) :)
Superb. I'll test the changes today.
[1] http://www.springframework.org/docs/reference/resources.html#d0e6335
--
Leszek GawronCTO at MobileBox Ltd.
Re: [2.2] Deployment and the maven plugin
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 support - the only thing remaining should be
testing and bug fixing - I can't test right now as I can't build Cocoon
due to the missing artifacts (jci ...) :(
Ok, here the locations:
SettingsBeanFactoryPostProcessor.java
Read the properties from cocoon/properties and cocoon/properties/{mode}.
For reading the properties it is calling
ResourceUtils.readProperties(..) in line 189ff
I already added the calls, but I guess ResourceUtils.readProperties
might not handle the classpath* case properly.
SettingsElementParser.java
This one reads all bean definitions. I added the call to
this.handleBeanInclude() in line 71 - but handleBeanInclude might
need some updates to handle the classpath:* protocol.
CocoonPropertyOverrideConfigurer.java
This one read the properties from cocoon/spring/*.properties for
overriding bean configurations. I added the calls to
ResourceUtils.readProperties(..) in line 86ff.
HTH
Carsten
--
Carsten Ziegeler - Chief Architect
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: [2.2] Deployment and the maven plugin
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) META-INF/properties/** - Block specific properties
f) META-INF/legacy/cocoon.xconf - The main avalon config file
g) WEB-INF/classes/** - Block specific resources for the classpath
h) WEB-INF/db/** - Support for the hsqldb block
i) META-INF/xpatch/*.xweb - Patches for web.xml
I think we can simplify this a little bit:
- No block should contain a cocoon.xconf - this file is either created
by using an archetype or by directly writing it per hand - so we should
drop the support for f)
- I see no use for g). We can simply put the resources directly into
the jar file.
+1
- I have no clue for h) and i) right now, but they are not very common
use-cases.
+1 for h)
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 would
like to extract the common definitions into a reusable artifact.
This goes to any stuff that you need to put into web xml:
- filters
- listeners
- additional servlets (AFAIR some of the users used .xpath files to
include xindice servlets in web.xml)
My common design in: webapp depends on ui-block (contributes COB-INF)
depends on core block (contributes model and spring services) depends on
hibernate and opensessioninview (contributes filters to web.xml)
- The separation between business components and sitemap components in
avalon is legacy as well, so I think we can all drop them into
legacy/xconf, but in different configuration files.
+1
- Using legacy in the directory structure is fine, but somehow it
seems wrong to me that we use legacy during development but not
in the final web application (there we just use WEB-INF/cocoon/xconf).
So we should imho either rename legacy/xconf to just xconf or
put everything in the resulting webapp under WEB-INF/cocoon/legacy:
the avalon configuration files and the initial cocoon.xconf.
For the reminder of this mail, I'll use the first solution.
+1
This leaves the COB-INF directory and some configuration directories in
META-INF. I know that we discussed the directory structure many times
but today I think we should put all configuration stuff inside one
single directory; I would suggest to put everything in the
META-INF/cocoon directory (apart from COB-INF):
META-INF/cocoon/xconf/**
META-INF/cocoon/spring/**
META-INF/cocoon/properties/**
I like the idea a lot - it is way clearer now.
Changing this simplifies the deployer as it just has to extract the
META-INF/cocoon directory to WEB-INF/cocoon.
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 or runtime. Cocoon would be able
to serve everything directly from the jar files.
First of all: why don't we simply use spring functionality for that?
Spring has a nice resource resolution. Why don't we simply reference
classpath*:/META-INF/cocoon/spring/*.xml for context inclusion and
classpath*:/META-INF/cocoon/properties/*.properties,
classpath*:/META-INF/cocoon/properties/{currentmode}/*.properties
for properties resolution?
This way we can reference the files directly from jar file without the
need to extract it.
Moreover this automatically resolves all current problem for block
development. Currently if you test a development block in isolation none
of the resources are actually deployed into a webapp. Instead everything
is referenced from src/ directory. Everything apart
src/main/resources/META-INF/cocoon/properties/**.
Referencing properties with
classpath*:/META-INF/cocoon/properties/*.properties will also pick
property files from target/classes directory of local block. Poof - the
problem is gone.
While this is a very interesting solution, it has some problems: first
and most important: we have to develop it. As we are lacking resources,
this might take too much time until we have a final version.
So what are our alternatives? I come up with the following three, but
perhaps there are more:
a) We don't care and require people to use maven2 for their development
(or if they don't want to use maven2 they have to figure out how to do it)
b) We support other build system, for example by providing an ant task
doing the same stuff as the maven deployer
c) We implement a simpler solution which works for most people
a) is obviously not a good choice; I'm not sure about b) so I personally
would focus on c). A solution would be to simply extract the
Re: [2.2] Deployment and the maven plugin
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 change it, otherwise we go the usual deprecation path. I offer my help in the matter anywhere I could be useful. Cocoon deployment has been bugging me since day one and as I have already started to take advantage of block in all my new projects it is crucial to me to have a good build system. I have already been trying to identify and modify the code that is responsible for loading spring context files but failed. I felt like a dog chasing his own tail. I am sure a little guidance would be all I need to get the things working. -- Leszek Gawron, IT Manager MobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: [Vote] Block artifact directory structure [was: Re: [2.2] Deployment and the maven plugin]
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 your votes. Carsten +1 -- Leszek Gawron, IT Manager MobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: [2.2] Deployment and the maven plugin
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 would
like to extract the common definitions into a reusable artifact.
This goes to any stuff that you need to put into web xml:
- filters
- listeners
- additional servlets (AFAIR some of the users used .xpath files to
include xindice servlets in web.xml)
My common design in: webapp depends on ui-block (contributes COB-INF)
depends on core block (contributes model and spring services) depends on
hibernate and opensessioninview (contributes filters to web.xml)
Ok, I see - obviously we can't patch the web.xml at runtime as its too
late then, so this has to be done during deployment (or packaging).
I think we could leave this functionality in the our plugin for now, but
I would love to have such support directly in the maven webapp plugin.
The same for the shielded classloading stuff. This would free us from
having to use Cocoon specific plugins for non-Cocoon specific things.
First of all: why don't we simply use spring functionality for that?
Spring has a nice resource resolution. Why don't we simply reference
classpath*:/META-INF/cocoon/spring/*.xml for context inclusion and
classpath*:/META-INF/cocoon/properties/*.properties,
classpath*:/META-INF/cocoon/properties/{currentmode}/*.properties
for properties resolution?
Does this work in Spring? I briefly looked at the code but did not find
support for patterns when using the classpath protocol. *If* this is
working we can directly read these files from within the jars without
need to extract anything. That should be simple.
This way we can reference the files directly from jar file without the
need to extract it.
Moreover this automatically resolves all current problem for block
development. Currently if you test a development block in isolation none
of the resources are actually deployed into a webapp. Instead everything
is referenced from src/ directory. Everything apart
src/main/resources/META-INF/cocoon/properties/**.
Referencing properties with
classpath*:/META-INF/cocoon/properties/*.properties will also pick
property files from target/classes directory of local block. Poof - the
problem is gone.
Yepp.
Could the archetype stop putting cocoon.xconf into generated webapp?
It does not do this anymore (since monday) :)
I
have at last 10 projects running 2.2 and never touched this file in any
project. It only gives me headaches when cocoon-core changes and I have
to update it manually from cocoon sources (Last time all my projects
broke after the namespaces have been renamed). That is why I think we
should move the configuration stuff (log4j configuration file location -
why isn't this controlled by properties after all?) out of the file and
either reference it directly from cocoon-core.jar or remove it
completely (create proper beans programatically at runtime).
Yes we should do something with the logging configuration as well, agreed.
Carsten
--
Carsten Ziegeler - Chief Architect
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
[Vote] Block artifact directory structure [was: Re: [2.2] Deployment and the maven plugin]
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 -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [Vote] Block artifact directory structure [was: Re: [2.2] Deployment and the maven plugin]
-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/** META-INF/cocoon/spring/** META-INF/cocoon/properties/** +1 Giacomo - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFRx4iLNdJvZjjVZARAudYAKCw5V/6rHJBAnXD9n0pFwI3q2HnmACeIa60 xDsWY6umpR2icSeMoPezYEM= =LXzM -END PGP SIGNATURE-
Re: [Vote] Block artifact directory structure [was: Re: [2.2] Deployment and the maven plugin]
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 your votes. +1 Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [Vote] Block artifact directory structure [was: Re: [2.2] Deployment and the maven plugin]
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 your votes.
+1
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: [Vote] Block artifact directory structure [was: Re: [2.2] Deployment and the maven plugin]
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]
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/** META-INF/cocoon/properties/** Please cast your votes. +1 - Not sure I see that there are any other logical alternatives (or if there are why it would matter)? -- Peter Hunsberger
Re: [Vote] Block artifact directory structure [was: Re: [2.2] Deployment and the maven plugin]
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 your votes. +1 Vadim
Re: [Vote] Block artifact directory structure [was: Re: [2.2] Deployment and the maven plugin]
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/** META-INF/cocoon/properties/** Please cast your votes. +1 -- Andreas
Re: [Vote] Block artifact directory structure [was: Re: [2.2] Deployment and the maven plugin]
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]
+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. -- Lars Trieloff visit http://www.mindquarry.com/
Re: [2.2] Deployment and the maven plugin
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 or runtime. Cocoon would be able to serve everything directly from the jar files. While this is a very interesting solution, it has some problems: first and most important: we have to develop it. As we are lacking resources, this might take too much time until we have a final version. Was this a discussion on the mailing list? Maybe I just haven't read that thread yet. Or was this offline at Cocoon GT or similar? Can you give some links or summarize it here please? What's needed more than resource:/? Jörg
Re: [2.2] Deployment and the maven plugin
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 files during deployment or runtime. Cocoon would be able to serve everything directly from the jar files. While this is a very interesting solution, it has some problems: first and most important: we have to develop it. As we are lacking resources, this might take too much time until we have a final version. Was this a discussion on the mailing list? Maybe I just haven't read that thread yet. Or was this offline at Cocoon GT or similar? Can you give some links or summarize it here please? What's needed more than resource:/? We started the discussion at the GT and then continued/summarized it in this mailing list. I greped some pointers from another discussion on this list: We have some ideas about how to get rid of the need for the deployer in the development cycle. See http://marc.theaimsgroup.com/?t=11601324081r=1w=2, http://marc.theaimsgroup.com/?t=11603443062r=1w=2 and http://marc.theaimsgroup.com/?l=xml-cocoon-devm=116035392308084w=2 for that discussion. That would indeed be very nice. But how does the reloading work then? Deploy a special jar into cocoon/libs that somehow points to its original source folders? No, we discussed having a configuration file with associations between block name and block path, that overrides the blocks in the classpath. By using that you can point to your block under development. You need more than the resource procotol as for example you have to scan through the archive for all *.xml files and so on. And the other problem is the mounting of the COB-INF directory. Although it's doable (at least currently we think it's doable), it might get a little bit tricky here and there. 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
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 use of maven 2 for building own projects optional. Currently, if you're developing your own Cocoon 2.2 based project, you depend on the specific artifacts (jar files) which you can get from the repository *and* you need the maven 2 deployer plugin to extract specific files from some of the artifacts into some directories in your web application. For example the legacy avalon configuration files and the spring bean configuration files are extracted into the file system. Before discussing a solution for this, let's have a look at what is currently handled by the deploy plugin (please correct me if the information below is wrong): Currently the deployer plugin handles: a) COB-INF/** - these are all application resources of the block like the sitemap, stylesheets etc. 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) META-INF/properties/** - Block specific properties f) META-INF/legacy/cocoon.xconf - The main avalon config file g) WEB-INF/classes/** - Block specific resources for the classpath h) WEB-INF/db/** - Support for the hsqldb block i) META-INF/xpatch/*.xweb - Patches for web.xml I think we can simplify this a little bit: - No block should contain a cocoon.xconf - this file is either created by using an archetype or by directly writing it per hand - so we should drop the support for f) +1 - I see no use for g). We can simply put the resources directly into the jar file. +1 - I have no clue for h) and i) right now, but they are not very common use-cases. We had a long discussion about i) at the end of August. Maybe Lezek, who integrated this stuff can give a summary. - The separation between business components and sitemap components in avalon is legacy as well, so I think we can all drop them into legacy/xconf, but in different configuration files. so you mean dropping META-INF/legacy/sitemap-additions/? No problems with it. - Using legacy in the directory structure is fine, but somehow it seems wrong to me that we use legacy during development but not in the final web application (there we just use WEB-INF/cocoon/xconf). So we should imho either rename legacy/xconf to just xconf or put everything in the resulting webapp under WEB-INF/cocoon/legacy: the avalon configuration files and the initial cocoon.xconf. For the reminder of this mail, I'll use the first solution. This leaves the COB-INF directory and some configuration directories in META-INF. I know that we discussed the directory structure many times but today I think we should put all configuration stuff inside one single directory; I would suggest to put everything in the META-INF/cocoon directory (apart from COB-INF): META-INF/cocoon/xconf/** META-INF/cocoon/spring/** META-INF/cocoon/properties/** Changing this simplifies the deployer as it just has to extract the META-INF/cocoon directory to WEB-INF/cocoon. +1 (maybe somebody can write some script that moves around the directories (again) so that they follow this. 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 or runtime. Cocoon would be able to serve everything directly from the jar files. While this is a very interesting solution, it has some problems: first and most important: we have to develop it. As we are lacking resources, this might take too much time until we have a final version. So what are our alternatives? I come up with the following three, but perhaps there are more: a) We don't care and require people to use maven2 for their development (or if they don't want to use maven2 they have to figure out how to do it) b) We support other build system, for example by providing an ant task doing the same stuff as the maven deployer c) We implement a simpler solution which works for most people a) is obviously not a good choice; agreed I'm not sure about b) doable but if we rewrite things we can go for a better solution like c) so I personally would focus on c). A solution would be to simply extract the files on startup of Cocoon into the web archive. We already have a place where we can do this (in the setting up of the properties system of Cocoon which is the first activity on startup) and implementing this should be fairly easy. We just have to find a smart way of not extracting everything on each startup
Re: [2.2] Deployment and the maven plugin
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
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 the usual
deprecation path.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
