Thank you Grzegorz for this email. I think there's some points you are
missing. You misunderstand my understanding of maven. I am not against
using it at all. In fact, I believe it's a great way to tell Ruby
developers that java can easily be adopted for rapid development. It's a
great way to get a newbie started building the site he/she needs for a
blog/portal/photos. I can not use maven at this point. Not that I am
against it. I know in the future I will, and it will help me a lot when
I need to create a block and add it to my collection. For now, maven is
not the right choice for me. I need to understand every single file
before I use it in my projects. If something goes wrong, I want to find
out why and immediately. I need to know how I can utilize it in my work.
How does it contribute to lowering the risk in my projects. Think about
it this way, if you go to a restaurant and you are on a diet, won't you
ask about every single ingredient in the meal you are going to order ?
Same thing when you are engaged in a professional work and you have dead
line and risk to manage. You need to know about every single file, and
evaluate and think about how you are going to need this file.
I have worked with Struts2 and with .NET products. One big difference I
noticed between these two technologies. Stop reading my email, think
about the difference and come back.
=====================
BREAK.
=====================
DONE? ok, The BIG DIFFERENCE IS: .Net makes the starting point very easy
while Java not. Visual Studio hides all the details about the components
involved in a project and give you the easy things. You can develop and
make progress with it but at some point you will loss control about what
you have there and you will start wondering where all these files came
from. When something goes wrong, you will be stressed like anything. Not
to mention the slow learning process that .NET develop for you. On the
other hand Java makes harder to start but once you start, you don't
stop! You keep progressing and learning new things every day. I can see
that SUN relies more on the academic institute to market their technology.
By the way, when I started learning Struts2, you know what I used? Don't
laugh! I went back to vi for quick edits, and emacs for regular
development :)
Anyway, this is not a comparison between Java and .Net. I just wanted to
give you (and everyone else wondering why I need this) an idea about the
downside of automating the learning process. It's helping many newbies
to get started, but advanced users need a solid ground before moving
ahead. Another good example is one of my previous responses on this
thread. I deleted the whole section for the component and could not
figure out why things are not working. If there was a step by step
tutorial, I would have fixed the problem by myself.
It's great that you are considering the newbies but what about bigger
projects? Definitely you can not document every single way Cocoon can be
used in there projects, but you can give the basics, and let the
programmers decide and find ways to use Cocoon in their development.
I hope my point is clear about "tutorials using Maven".
I used the word "you" many times, and I did not mean "you", but
"Cocoon's Community".
I have been looking into Cocoon 2.2 and I am getting ready to build
another HelloWorld from zero using Cocoon 2.2. However, I find very few
jars there. Is this again one of maven's trick to make things easier?
Does it download a different set of jars that are only for this
template? Can I use these jars in another way, like importing them
directly into my app? Does this 716K set of jars "REALLY" replace the
~30 MB ones (in Cocoon 2.1)?
As soon as I finish this, I will try to write a tutorial.
Grzegorz Kossakowski wrote:
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
