Giacomo Pati wrote:
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.
Correct. But I think we need a thing for "first contact".
Can you give an example for what you mean with "first contract"?
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.
Yes, I see that, too.
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.
Ok.
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.
Shouldn't it be "you can't use more than _this_ block". This in contrary
to the "full blown sample distribution" where all our samples blocks are
independant (application) blocks which itself depend on
(composition/service) blocks (i.e. like cron, or ajax which itself will
be referenced by many of those independant blocks). Such a "full blown
sample distribution" could well be a separate block in our repository
just for building that distribution (at the ent it could be a war package).
yes
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.
Fine. Do you have in mind to support this by a Maven plugin to create
descriptors, based on dependencies defined in the pom, unpack them to
create the webapp structure suitable for war packaging?
pom.xml only contains the Java library dependencies. But yes, we could provide
some plugin that creates an initial block-deploy.xml if we see that we need this
- time will show.
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.).
The difference is made up in the descriptors (i.e. has a sitemap, just
supplies some common components/services).
yes, that's an internal difference. A block can
- contain Java classes and a Cocoon app
- only Java classes
- only a Cocoon app
Looking at block.xml shows only two differences: Does it has a <servlets>
section and does it have a <components> section? At deployment time you don't
care which "type" of block it is internally.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
