-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, 18 Jan 2006, Reinhard Poetz wrote:
Date: Wed, 18 Jan 2006 10:26:13 +0100
From: Reinhard Poetz <[EMAIL PROTECTED]>
Reply-To: [email protected]
To: [email protected]
Subject: Re: M10N
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"?
A distribution that can be downloaded, unpacked, and started with all
samples we have to give her the overview what Cocoon is, can do, and
feels like.
> 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.
And the wiring.xml I suppose.
> 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.
Ok
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFDzhERLNdJvZjjVZARAlUAAKCqyElJqsdBvoVShcsFGN/0iHfKLQCgoPJc
JJz9ueUMUxpLYzx6z2nW+bw=
=9d+6
-----END PGP SIGNATURE-----
