cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <reinh...@apache.org>
Subject Re: M10N
Date Wed, 18 Jan 2006 09:26:13 GMT
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
--------------------------------------------------------------------

Mime
View raw message