[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xml-cocoon-dev
Subject:    Re: Cocoon 2.2 - Build and deployment with Maven2
From:       Daniel Fagerstrom <danielf () nada ! kth ! se>
Date:       2005-12-06 21:12:07
Message-ID: 4395FEA7.5000405 () nada ! kth ! se
[Download RAW message or body]

BURGHARD Éric wrote:

>Daniel Fagerstrom wrote:
>  
>
>>What do you think about moving block dependecy handling from block.xml
>>to pom.xml? It means reduced flexibilty as block dependencies becomes
>>direct instead of indirect as in the current schema. OTH it reduce
>>complexity and fullfills our current use cases. If we need indirect
>>dependencies we can add it later. There would be a need to give the
>>dependencies POM unique ids that can be used in the block protocol and
>>we also need a way to be able to mark a dependency as "extension", any
>>idea if this would be possible?
>>
>>Hmm, while that would be nice at some point I think that it currently
>>would be enough to have a block aware variant of the war pluggin. That
>>fetch and install all needed blocks in the webapp one i developing.
>>Maybe wiring.xml could even be expressed as a POM for this pluggin?
>>    
>>
>
>2 wonderfull ideas !
>
>Before you wrote that, daniel, i was very frightened by the new 'hot' block
>framework because of
> * the new kind of descriptor,
>  
>
The current design involves a pom.xml and a block.xml (and a Manifest.mf 
whith OSGi) for each block and a wiring.xml globally. This is certainly 
to much, some merging of configuration files is needed on the block 
level. How to do this is an open question. With Jorg's and Reinhard's 
ongoing work and the block mechanism in place we hopefully will be able 
to "real blockify" a number of blocks in trunk RSN. Then hopefully the 
community can take some interst in such mundane questions as 
configuration file formats ;)

> * all the new jar introduced (osgi, knopflerfish: even if don't know if
>there are really related to this, it's part of the cocoon new face)
>  
>
They will be removed from the 2.2 releases and only be part of 3.0. And 
it is not as bad as it might seem, framework, log and http which 
together is less than 350kB is needed for actually running serving 
webpages with Cocoon in OSGi mode. The rest (rather small as well) are 
for the Knopflerfish OSGi runtime console.

> * the fact that blocks are not regular jar (even if i don't know what it
>means it's frightening for a java developer :-)
>  
>
Bundles are regular jars that happen to include some extra fields in the 
manifest. Blocks will be as well.

>After 2 years using cocoon i just can't explain clearly how to build an
>application over cocoon-core and a few blocks staticaly. You should do
>something with block management for sure, but IMHO hot deployment should
>not be a priority. It just seems like adding an unecessary new layer of
>complexity (i know that you think this is simpler :-).
>  
>
No I don't think complete hot deployment is simple. Block that are 
"leaves" in the dependency chain and that not are connected to 
complicated external things like DBs, is not that complicated to get hot 
deployable. And having hot deployable user blocks will make wonders for 
development. Think about having your Cocoon (which will be a couple of 
bundles) deployed within Eclipse while you develop your own block with 
the pluggin development mode in Eclipse.

But as you suggest hot deployment is far from the main priority. First 
we need to get everything working statically and even without OSGi.

...

>So please (poor user request) define first a clean static build process with
>well defined dependencies (concern 99% of users) before thinking of hot
>deployment stuff. This build process could be defined for cocoon 2.1.9
>without redefining the block management nor the jar stucture. It would give
>new users the possibility to fire a new cocoon project in 30s (how lucky !
>it took me several month just to know how to build a minimal cocoon
>webapp).
>  
>
Hmm ... might there be simpler things we could do than redefining 
ourself completely, to attract users? Could a first step be as easy as 
reducing  the startup phase of Cocoon from 3 months to ... say 1 month 
;) Or maybe to a few minutes. The ongoing M2 and blocks work will get us 
there.

/Daniel

[prev in list] [next in list] [prev in thread] [next in thread]