cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <reinh...@apache.org>
Subject Cocoon development using blocks
Date Tue, 10 Jan 2006 05:49:12 GMT
Leszek Gawron wrote:
> Daniel Fagerstrom wrote:
> 
>> Leszek Gawron skrev:
>>
>>> Daniel Fagerstrom wrote:
>>
>>
>> ...
>>
>>>> I would prefer removing the trunk/lib and Ant build system ASAP, and 
>>>> that everybody helps getting the parts they care for working with 
>>>> the Maven build.
>>>
>>>
>>>
>>> Before taking such drastic moves we should probably have a full 
>>> replacement for current build system. Up till now we had quite a nice 
>>> solution [1]. If we are to drop it we should resolve following issues:
>>>
>>> 1. developers/more advanced users often use trunk snapshots even for 
>>> production (I have probably never used a released version :)). If so 
>>> there has to be a support in our build system to deploy artifacts not 
>>> only to apache repository but also to company's/individual's 
>>> repository.  I am not talking here about simple 'mvn install' which 
>>> only copies the file on the same computer to local repo.
>>
>>
>>
>> The release plugin take care of this: 
>> http://maven.apache.org/guides/mini/guide-releasing.html, IIUC you can 
>> overide where it reads from, I'm not shure about if there if you can 
>> override the release repository without changing the root POM.
> 
> 
> The official documentation states the only way to do this is to change 
> cocoon's POM and that is not a solution I would advise to users.
> 
>>
>>> 2. Follow up for 1): jar names should include timestamps/revisions so 
>>> one can have multiple production sites working on different cocoon 
>>> versions.
>>
>>
>>
>> Take a look at 
>> http://svn.apache.org/maven-snapshot-repository/org/apache/cocoon/cocoon-core/2.2.0-SNAPSHOT/

>>
>>
>> It is automatically generated by Continuum.
>>
>> Jorg have set up this.
> 
> That is very nice. Still my own 'mvn install' should do the same. 
> Imagine a contributor that creates some enhancement and wants to test it 
>  on it's own projects before submitting. He/she cannot use Jorg's 
> snapshots.

Why not? If the user wants to use snapshots, he just points to the snapshot 
repository at Apache. What's missing?

> 
>>
>>> 2. cocoon is not only a set of jars. There is also a set of default 
>>> resources (web.xml, main sitemap, stylesheets and so on). How do we 
>>> ship that so users do not stay out of sync with jar versions?
>>
>>
>>
>> They will be included in the respectively blocks jar. And put in some 
>> blocks unique package so that the framework can find them. Reinhard 
>> work on this.
> 
> To be sure: is it also the case for main sitemap.xmap?

There will be no main sitemap.xmap anymore, however one block can cover the "/" 
URIs by mounting it to "/".

>>> 3. How are we going to distribute .xconf files? As they are also 
>>> artifacts of some kind users shouldn't copy them into own project and 
>>> modify but rather xpatch them as it is performed now. I know we have 
>>> .xconf inclusion and multiple xconf files. Still there are some 
>>> things that inclusion does not solve.
>>
>>
>>
>> The .xconf files will be parametrized with the parts that users might 
>> be interested in changing, and a fixed .xconf will be included in the 
>> blocks jar.
> 
> So how do I add my own cforms convertor? The only way to do it now is 
> xpatch.
> 
> How do I parametrize continuations manager. It's current configuration 
> is rather incoherent:
> 
>   <continuations-manager logger="flow.manager" time-to-live="3600000"
>                          session-bound-continuations="false">
>     <expirations-check type="periodic">
>       <offset>180000</offset>
>       <period>180000</period>
>     </expirations-check>
>   </continuations-manager>
> 
> (BTW type="periodic" is not even parsed by the component :))
> 
> We'll probably need to redesign the way some parts of our systems are 
> configured. I'd love to use Carsten's idea of property files to 
> parametrize components. After all almost every xml configuration can be 
> expressed with a set of properties.

Blocks can be parameterized. I'm not sure how this will work together with 
Carsten's idea of property files.

I've started to write documentation about block usage and deployment and hope 
that this will make things clearer (for me and for us). I will publish it at the 
beginning of the next week as I don't want to confuse people with the current 
state of the documents.

>>> I am working on lots of small cocoon based project. Because of the 
>>> project count I found the [1] technique uniquely useful. I have 
>>> created  a ant based build system (similar to [2]) and isolated 
>>> custom cocoon build into a subproject. This way my cocoon based 
>>> projects do not contain any files copied over from cocoon distro. 
>>> Everything stays in cocoon-build-system and with one simple
>>>
>>> ant -f cocoon.xml cocoon:get
>>>
>>> I update cocoon distro for every of my projects. I hope it will be 
>>> that simple also with maven.
>>>
>>> [1] http://wiki.apache.org/cocoon/YourCocoonBasedProjectAnt16
>>> [2] http://javagen.com/jam/
>>
>>
>>
>> Maven also has the concept of archetypes, that make it possible to 
>> generate different kinds of project templates. Jorg experimented with 
>> that in the whiteboard.
> 
> The problem is archetype is not good in cases when you manage lots of 
> projects because it's merely a template. If you put web.xml into your 
> archetype it will surely be outdated in a year. If you just xpatch the 
> current version than you have no such problem. I resigned from copying 
> any cocoon resource into my project because that brought a lot of 
> problems. Gosh it was a nightmare to synchronize cforms resources before 
> they were put into .jar file. In this case the solution was quite simple 
> as the resources are easily extendable and they do not have to be 
> changed. With other cocoon resources it is not that nice.

First, your Cocoon 2.2 projects will be blocks too. You will use the Cocoon 
block archetype to create one. Then you will use the Cocoon webapp archetype 
that only contains a description which blocks you want to use in your webapp 
(war) and where you want to mount them. Additionally you will find there the 
usual webapp stuff (web.xml, ...).

The rest will be done by the block deployer plugin and standard Maven plugins 
like the webapp plugin. At least that's the plan.

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