cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <giac...@apache.org>
Subject Re: M10N
Date Wed, 18 Jan 2006 09:57:37 GMT
-----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-----

Mime
View raw message