Reinhard Poetz wrote:
- o -
+-------------------------------------------------------------------+
| Build and deployment from a Cocoon user's POV |
+-------------------------------------------------------------------+
ROOT
+-- block.xml
+-- pom.xml
+-- src
+-- main
| +-- java
| +-- myApp
| +-- MyJavaFlowController.java
| +-- webapp
| +-- sitemap.xmap
| +-- hello.xml
+-- test
Note that this follows the standard M2 project structure which makes the
M2 life much easier as it saves you configuration time (greetings from RoR).
yes. Include also src/main/resources , contents here gets automatically
added to the classpath as well.
The next step is adding your block to Cocoon application server by
mvn cocoon:deploy
-Dserver=/home/rpoetz/cocoon2.2
-Dmount-point=/myBlock
at a later stage we could also provide
mvn cocoon:deploy
-Dserver=/home/rpoetz/cocoon2.2
-Dmount-point=/myBlock
-DartifactId=myblock
-DgroupId=org.apache.cocoon.blocks
-Dversion=1.0beta
which would just fetch the block and install it.
This will add an entry to the wiring.xml and will resolve all block
dependencies by putting them into the "<connections>" part.
I'm assuming it will deploy the block dependencies as well ?
For Cocoon 2.2 this will also make sure that all library dependencies
specified in pom.xml are resolved.
If we hook in to the normal lifecycle then maven will resolve declared
library dependencies for us. They should be available from the local
repo by the time our deployer kicks in.
Now you can start your Cocoon server and enter
http://[server]/myBlock/hello or
http://[server]/myBlock/javaflow-hello
If you want to use the block from other blocks you simply have to call
mvn install
and it is available for other local projects.
this standard maven goal would jar up the compiled project and put it as
is in the local maven repo.
What do you mean by "use the block from other blocks", from
IDE/container/... ?
- o -
+-------------------------------------------------------------------+
| Build and deployment :: in depth |
+-------------------------------------------------------------------+
Now let's look a bit deeper into the implementation. A Cocoon block is
1. well, a valid Cocoon block by providing "block.xml"
2. a valid Maven2 artifact
3. a valid JAR file
IMO 2. and 3. are equivalent, or maybe i don't fully understand what a
valid jar file encompasses.
The jar (packaged block) has following content:
ROOT
+-- block.xml
+-- myApp
| +-- MyJavaFlowController.java
+-- sitemap.xmap
+-- hello.xml
+-- META-INF
+-- maven
+-- ...
+-- pom.properties
+-- pom.xml
Are you sure we want to include the sources in each block by default? By
"packaged block" i'm assuming you're referring to the artifact that
get's deployed to the repository for others to grab.
Same should work for creating IDEA and Eclipse project properties files.
For the purpose of RAD, the output directory of the IDE can be set to the target
directory of Maven.
maven creates idea and eclipse project files out of the box. These mojos
are highly configurable so we wouldn't need to do much there.
http://maven.apache.org/plugins/maven-eclipse-plugin/eclipse-mojo.html
This requires special Maven goal. Thanks to Maven2 it has become very
easy to write your own goals (they call them MOJOs). This goal will be
able to deploy a block and
- resolve all JAR dependencies (pom.xml)
- resolve all block dependencies (block.xml)
again i think if we hook up the deployer to the correct lifecycle phase
the jar dependencies will be resolved already. Resolving the block
dependencies should be trivial as at this point they are nothing but
plain artifacts from a maven point of view.
and copies (and for now unpacks) the block into
/cocoon-app/WEB-INF/blocks/myBlock. And, in Cocoon 2.2 it will also copy
all JARs the block depends on into /WEB-INF/lib. The mojo has to be smart
enough to avoid JAR version conflicts. Thanks to the Maven naming conventions for
JARs this should be at least possible. (Note: OSGi will help us to overcome this
problem once and for all).
yes.
And Jorg, if you agree with my ideas, are the proposed changes difficult
to implement?
Thanks for the summary.
No I don't think any of this stuff is difficult to implement at all.
Have a look at the ArtifactFactory for artifact resolution. maven's jar
conflict strategy is pluggable so we should be able to reuse that as well.
Maybe you could start a block deployer directory in the whiteboard ?
Regards
Jorg
