Jorg Heymans wrote:
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 ?
Future versions, yes ;-) The first implementation will show a meaningful error
that dependencies are missing.
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.
yes
we only have to take care that library dependencies are different from block
dependencies *at deployment*. During development they are equal.
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.
it also has to put in the "block application" (sitemaps, templates, images, ...)
What do you mean by "use the block from other blocks", from
IDE/container/... ?
From IDE or during build as another block can compile against my block.
- 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.
yes, but until last week I believed that there is a different as I had put Java
binaries into /BLOCK-INF/classes and not directly into the root directory.
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?
Sorry, replace "MyJavaFlowController.java" with "MyJavaFlowController.class".
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
yes
the only thing I'm not sure about is how to differentiate between binary
dependencies (one Eclipse project depends on a block as JAR) and project
dependencies (one Eclipse project depends on a block as another Eclipse
project). How do I set this?
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.
for building blocks, right but not for the deployment as we can't put all blocks
into WEB-INF/lib as a block is more than Java binaries (sitemaps, templates,
...). These additional resources have to be put into /WEB-INF/blocks/myblock/...
as we can't look them up in JARs. Right Daniel?
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 ?
Yes, I will start with the initial code base this week. It's only important for
me that we get a deployer API that is independant from Maven and can be included
in other tools (e.g. a future GUI-based deployer). I now that Maven offers a
high level API to be included in other tools but I have to think more about what
this means for our deployer.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
