cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leszek Gawron <>
Subject Re: svn commit: r367382 - in /cocoon/trunk/lib: core/jetty-jmx-5.1.8.jar core/mx4j-3.0.1.jar core/mx4j-jmx-3.0.1.jar jars.xml
Date Tue, 10 Jan 2006 00:45:33 GMT
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: 
>, 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 

> 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 

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

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

How do I parametrize continuations manager. It's current configuration 
is rather incoherent:

   <continuations-manager logger="flow.manager" time-to-live="3600000"
     <expirations-check type="periodic">

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

>> 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]
>> [2]
> 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.

> In total Maven have a lot of functionality OOTB that help you with what 
> you describe above. And with some customizing and own plugins we can 
> make it even neater. Join the work and help make Cocoon builds as simple 
> and powerful as possible :)
I am already resolving some issues with maven guys. I must say their 
attitude towards helping a lame like me is impressive. Their IRC support 

Leszek Gawron                            
IT Manager                                         MobileBox sp. z o.o.
+48 (61) 855 06 67                    
mobile: +48 (501) 720 812                       fax: +48 (61) 853 29 65

View raw message