Giacomo Pati wrote:
Recently I was thinking about how we want our new build system to behave
from a user perspective because I wanted to get the plugins going ASAP.
Now I want to make sure that we all align on the same things.
In general the build system of Cocoon 2.1.x was quite handy for most of us.
./buils.[sh|bat]
./cocoon.[sh|bat]
Was all one needed to type to get a running system (yes some needed to
adjust the local.[build|block].properties file but with M2 this should
be doable in a similar but more Mavne-like way).
Now, is it the goal of M10N to get as close to this as well? Or are we
going to have different building procedures (mvn goals) depending on
whether it is a component block, application block, webapp block, etc.
M2 offers quite a lot of possibilities how to interact with its
lifecycle/build phases so that building different types of artifacts
could be standardized with our plugins which may be attached into those
lifecycles/build phases.
We can define our own artifact types so that there is possibilities to
supply archetypes for things like application blocks, component blocks,
abstract blocks, whatever and build them in a consistent way (from the
users perspective), but package them as we need/like.
I.e.
=> mvn # build the package depending on the artifact we
# want to produce for a certain module (single modules
# as well as multi module build)
mvn cocoon:run # run it (independent whether this is the root or
# a single module)
WDYT?
Hmm, I'm not sure if I can follow your mail. From my POV any Cocoon development
is done as block. I only see differences in what you want to do:
First contact with Cocoon
-------------------------
We can provide "ready to use" downloads that basically consist of
- container (Jetty)
- web application with blocks
We can also offer different sizes:
- standard: contains the most important samples blocks
(forms, template, auth, flowscript, javaflow)
+ all required blocks
- portal: just the portal samples
+ all required blocks
- full: all our samples
+ all required blocks
These downloads are *not* the starting point for new Cocoon projects but only
show the functionality.
These download packages can also be used at cocoon.zones.apache.org for our live
demos. I'm sure we can automate the packaging process in some way using the
block deployer Maven plugin.
BTW, I wouldn't even say these downloads are our _releases_ as IMO our releases
are the block jars that we make available at our download pages and (more
important!) via the Maven repositories.
Start your Cocoon project
-------------------------
As I said above, a Cocoon project is also a block. You create your block
skeleton using the Maven block archetype, add your dependencies, e.g. your block
depends on forms and template, and that's it.
It's the same process as adding a Maven plugin to your pom.xml. You browse the
Cocoon website and find a list of all available blocks. Than you add the
required block to block.xml as requirement.
As pointed out in the tutorial, you can use the "cocoon:simple-deploy" and
"jetty6:run" to test-drive your block at development time.
See http://cocoon.zones.apache.org/daisy/documentation/g2/796.html
A Cocoon web application
------------------------
The "cocoon:simple-deploy" is only useful at development time as you don't have
the possibility to change e.g. your web.xml and you can't use more than one block.
My plan is doing it the same way like other webapp projects. You provide your
web application in /src/main/webapp which means that you put your web.xml there
at least.
Then you create your block-deploy.xml and you can say there which blocks you
want to deploy, how they are configured and which implementations you want to
use to fulfill their requirements.
See http://cocoon.zones.apache.org/daisy/documentation/g2/797.html
Developing Cocoon (--> for Cocoon developers)
---------------------------------------------
AFAIU there is no difference to developing an "application block" (I even think
that we should restrain from introducing this distinction.).
What we have to do is splitting our blocks once again and separate our APIs,
implementations and samples:
- the sample block depends on the implementation
- the implementation depends on the API
In order to get fast turn-around-cycles at development time, you can use the
blocks, that you are working on, directly without having to put them into
WEB-INF/blocks/[block]. The wiring.xml will simply point to ./target/classes.
The reloading classloader will be our friend :-)
Of course this feature can (will) be used by people that want to develop their
own projects ("application blocks") based on Cocoon.
For me the only open question is how I can create the .classpath/.project files
for Eclipse (or any other IDE) so that they use project references instead of
JAR dependencies which would make the debugging process smoother. But I'm sure
we will find a way to automatize this.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
