cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <>
Subject Re: M10N
Date Wed, 18 Jan 2006 08:23:20 GMT
Hash: SHA1

On Wed, 18 Jan 2006, Reinhard Poetz wrote:

> Date: Wed, 18 Jan 2006 08:15:40 +0100
> From: Reinhard Poetz <>
> Reply-To:
> To:
> Subject: Re: M10N
> Giacomo Pati wrote:
>>  Recently I was thinking about how we want our new build system to behave
>>  from a user perspective because I wanted to get the plugins going ASAP.
>>  Now I want to make sure that we all align on the same things.
>>  In general the build system of Cocoon 2.1.x was quite handy for most of
>>  us.
>>      ./buils.[sh|bat]
>>      ./cocoon.[sh|bat]
>>  Was all one needed to type to get a running system (yes some needed to
>>  adjust the local.[build|block].properties file but with M2 this should be
>>  doable in a similar but more Mavne-like way).
>>  Now, is it the goal of M10N to get as close to this as well? Or are we
>>  going to have different building procedures (mvn goals) depending on
>>  whether it is a component block, application block, webapp block, etc.
>>  M2 offers quite a lot of possibilities how to interact with its
>>  lifecycle/build phases so that building different types of artifacts could
>>  be standardized with our plugins which may be attached into those
>>  lifecycles/build phases.
>>  We can define our own artifact types so that there is possibilities to
>>  supply archetypes for things like application blocks, component blocks,
>>  abstract blocks, whatever and build them in a consistent way (from the
>>  users perspective), but package them as we need/like.
>>  I.e.
>> =>  mvn   # build the package depending on the artifact we
>> #  want to produce for a certain module (single modules
>> #  as well as multi module build)
>>     mvn cocoon:run  # run it (independent whether this is the root or
>>                     # a single module)
>>  WDYT?

> First contact with Cocoon
> -------------------------
> We can provide "ready to use" downloads that basically consist of
>  - container (Jetty)
>  - web application with blocks

I think we need to do so. Cocoon is a complex thing and an effort giving 
an easy to install and use distribution to get in touch with it will be 
a must.

> We can also offer different sizes:
>  - standard: contains the most important samples blocks
>    (forms, template, auth, flowscript, javaflow)
>    + all required blocks
>  - portal: just the portal samples
>    + all required blocks
>  - full: all our samples
>    + all required blocks


> These downloads are *not* the starting point for new Cocoon projects but only 
> show the functionality.

I know that.

> These download packages can also be used at for our 
> live demos. I'm sure we can automate the packaging process in some way using 
> the block deployer Maven plugin.
> 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".

> 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.


> See
> 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 

> 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?

> See
> 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).

- -- 
Giacomo Pati
Otego AG, Switzerland -
Orixo, the XML business alliance -
Version: GnuPG v1.4.2 (GNU/Linux)


View raw message