On 20/03/2012 22:55, Lars Huttar wrote:
On 3/20/2012 4:35 PM, Lars Huttar wrote:
On 3/8/2012 3:49 AM, Francesco Chicchiriccò wrote:
C) If you want to develop a complete C3 web application
You need to generate a multimodule maven project [2] with the
following structure:
myparent/
mysite/
mywebapp/
Basically, you will need this when either having multiple blocks on
a single webapp or when you want to deploy on an external web
container (say Tomcat).
In the context of these instructions, which now produce for me a
working webapp shell,
where do I start developing my web application?
I expected that I could start putting sitemap.xmap, welcome.html, and
other files in
mywebapp/src/main/resources/COB-INF
I do this; and when I run
cd thewebapp
mvn jetty:run
My new sitemap etc. get copied to
mywebapp/target/classes/COB-INF
as expected.
But when I try to address any URLs in my new sitemap, e.g.
"localhost:8890/test.html", Cocoon tells me (in
mywebapp\target\work\cocoon.log) that there is no matching pipeline.
But it *does* match pipelines in the mysite sitemap
(mysite\src\main\resource\COB-INF).
So then my question is, if I'm running jetty in the mywebapp folder,
why is it serving URLs from the mysite artifact's sitemap? Maybe
that's by design, that the mysite sitemap is sort of like a Cocoon
2.1 top-level sitemap, which would "mount" the sitemaps of the
various webapps?
If this is true... that Cocoon will process URLs starting from
mysite's sitemap even thought I run jetty in the mywebapp folder...
then why should be in the mywebapp folder to run jetty? What
difference would it make if I was in the myparent or mysite folder?
Trying to wrap my head around this...
Lars,
Cocoon 3.0 is very similar to Cocoon 2.2 - and very dissimilar to Cocoon
2.1 - in this respect.
Unfortunately, Cocoon 3.0 documentation is far to be completed, so we
have to rely upon Cocoon 2.2's for the moment: of course you will have
to "translate" some things but the overall meaning should be helpful.
Start from [1]: it will introduce the concept of "block".
Basically, a "block" is a functional subsystem of your final
application: in many cases your application will be composed by a single
block, but this concept let you build more complex and structured
applications.
Coming to you question above: when developing, you only need your block
- i.e. "mysite". Since cocoon blocks feature the reloading plugin, just
launch your block with "mvn jetty:run" and start playing with
mysite/src/main/resources/COB-INF/sitemap.xmap. All your changes will be
immediately available.
If you want, you can of course add a second block [2]. You can make such
two blocks communicating together by empowering the ServletService
Framework, a concept born with Cocoon 2.2 and used by Cocoon 3.0 as well.
You will then eventually deploy your application to an external servlet
container (Tomcat, Glassfish, JBoss, ...): in order to do this, you will
need [3], a complete cocoon web application - mywebapp in your sample -
including all defined blocks. You will also need to group all such
projects - blocks + webapp - in a multimodule maven project, and for
this you need myparent.
I hope it's more clear now.
Cheers.
[1] http://cocoon.apache.org/2.2/1159_1_1.html
[2] http://cocoon.apache.org/2.2/1291_1_1.html
[3] http://cocoon.apache.org/2.2/1362_1_1.html
--
Francesco Chicchiriccò
Apache Cocoon PMC and Apache Syncope PPMC Member
http://people.apache.org/~ilgrosso/
