Daniel Fagerstrom wrote:
Great guys, let us go back to work again :)
yep :-)
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.
Yes follow M2 conventions as long as possible.
What do you think about moving block dependecy handling from block.xml
to pom.xml? It means reduced flexibilty as block dependencies becomes
direct instead of indirect as in the current schema. OTH it reduce
complexity and fullfills our current use cases. If we need indirect
dependencies we can add it later. There would be a need to give the
dependencies POM unique ids that can be used in the block protocol and
we also need a way to be able to mark a dependency as "extension", any
idea if this would be possible?
I don't think so, but maybe Jorg has some ideas. The problem is that our block
dependencies are "only" telling which contract a dependant block has to fullfill
(+ the information about a default implementation). Additionally we have other
dependencies as a block can extend another block or implement interfaces.
IMO the only thing we can do is that we add a goal to the Maven lifecycle that
checks whether block.xml and pom.xml are in sync.
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.
Hmm, while that would be nice at some point I think that it currently
would be enough to have a block aware variant of the war pluggin. That
fetch and install all needed blocks in the webapp one i developing.
Maybe wiring.xml could even be expressed as a POM for this pluggin?
Hmm, have to think more about this.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
