cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <g...@tuffmail.com>
Subject Re: Starting with Cocoon
Date Sun, 18 Nov 2007 21:29:00 GMT
Joerg Heinicke pisze:
> On 18.11.2007 11:35 Uhr, Mansour wrote:
> 
> If you are only starting with Cocoon right now you should really 
> consider using Cocoon 2.2, especially in regard to minimal build. Many 
> "optional" components which are in core in 2.1 have been made really 
> optional in 2.2. Integration should be much easier in general. Learning 
> now 2.1 and later 2.2 seems to be too much effort since so much has 
> changed between both.

I agree with Joerg on suggestion that it's better to start with Cocoon 
2.2. It has much cleaner contracts and you get much more fine-grained 
control over what comes to your application. Cocoon 2.1 was quite 
monolithic compared to 2.2.

As you seem to really want to understand low-level architecture of 
Cocoon I think you will find content of e-mail conversation I had with 
Danilo Gurovich privately.

Before I present the most important e-mail I want to give you some 
background. Take a look at this:
http://danilogurovich.wordpress.com/2007/11/09/struts-vs-cocoon-why-cocoon-lost-the-battle/
blog post and comments below it. As you can see, Danilo was looking for 
low-level description of Cocoon 2.2 that would give him ability to 
integrate it with his own solutions.

In private conversation I decided to explain many fundamental things of 
2.2. Here goes my e-mail (I was given a permission to publish this 
e-mail from Danilo):

------------------------------------------------------------------------------------------
[...]

For now, (..) I would only say that we don't describe how 
block/application should be structured in detail because we ship Maven 
archetypes that take burden of prototype creation, see [1] and [2].

I hope that you don't get nervous because I repeatedly suggest using 
Maven. I'm aware of the fact that you want to avoid using Maven but if 
there is one command to type instead of tedious work of creating all 
needed files and directories why not use that command? Creating 
prototype by using Maven does not tie rest of development stages 
(compiling, deploying) to Maven.

I think that you will get the best results if you use Maven as 
recommended at the beginning. Only after a few hours of playing with 
Cocoon and getting to know with all basic concepts you will be
sure when it pays off to use Maven without going deep into details 
(because we don't make a learning curve too steep) and when your own 
tools are better.

For example, we have developed Maven plug-in called Reloading 
classloader that makes development of Cocoon applications really rapid 
because any changes made to configuration (Spring bean configuration) 
and even Java classes code are visible instantly without any restarts of 
servlet container or any manual work! The best of this plug-in is that 
it is IDE-agnostic so you can edit your classes with Notepad (or 
IntelliJ) and it will pick up these changes. For more details, see
here[3].

Getting back to answering your question. In Cocoon almost everything 
happens in a block(s) when it comes to application development. Here[4] 
you will get general description, and here[5] technical details are 
provided that will probably interest you the most. Casual application 
based on Cocoon consists of few custom blocks (each one for some 
distinguishable set of functionality) wired to each other and to some 
standard Cocoon blocks (like Cocoon Forms).

After creating and compiling your own blocks you get a few JARs (as each 
block is a standard JAR in the end) and not a WAR file, right? Creation 
of WAR file is left as last step, you just collect all needed JARs 
(including your blocks, Cocoon blocks and other dependencies of Cocoon 
or your application) and put everything into WEB-INF/lib directory of 
the WAR you are preparing. Apart from that, you need to put these three 
files into WEB-INF directory:
   * applicationContext.xml (some Spring beans configuration)
   * log4j.xml (logging config)
   * web.xml (the most important bit in this file is configuration of 
Cocoon's dispatcher servlet)

Then you package everything into single WAR and you are done. You can 
deploy your application to any servlet container you like. Have a look 
at here[6] for exact content of three files you need to put
into WEB-INF directory or run a command:
mvn archetype:create -DarchetypeGroupId=org.apache.cocoon
-DarchetypeArtifactId=cocoon-22-archetype-webapp 
-DarchetypeVersion=1.0.0-RC2
-DgroupId=com.mycompany -DartifactId=myCocoonWebapp
(taken from [2])

I hope that this e-mail helps to arrange your knowledge about Cocoon a 
little bit. I also hope that it's clear now that development on top of 
Cocoon is not tied to Maven by any means but Maven only aids this 
process. We had to decide on something and we decided on Maven for 
several reasons but we really understand that there can be circumstances 
when Maven is not applicable thus we are really careful on not 
introducing hard dependencies on Maven.

[...]

[1] http://cocoon.apache.org/2.2/1159_1_1.html
[2] http://cocoon.apache.org/2.2/1362_1_1.html
[3] 
http://cocoon.apache.org/2.2/maven-plugins/maven-plugin/1.0/1297_1_1.html
[4] http://cocoon.apache.org/1363_1_1.html
[5] http://cocoon.apache.org/2.2/core-modules/core/2.2/1263_1_1.html
[6]
http://svn.apache.org/repos/asf/cocoon/trunk/tools/archetypes/cocoon-22-archetype-webapp/src/main/resources/archetype-resources/src/main/webapp/WEB-INF/

------------------------------------------------------------------------------------------

I hope that this in conjuction with our standard tutorials will give you 
  a quite good picture of Cocoon 2.2.

If you have any additional questions feel free to ask but please explain 
your problems in detail including sharing your motivations behind the 
questions you ask. This will help to avoid any tensions.

-- 
Grzegorz Kossakowski

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message