-----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 <reinhard@apache.org>
> Reply-To: dev@cocoon.apache.org
> To: dev@cocoon.apache.org
> 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-----
|