cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leszek Gawron <lgaw...@mobilebox.pl>
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 Mon, 09 Jan 2006 23:27:54 GMT
Daniel Fagerstrom wrote:
> Jorg Heymans skrev:
> 
>> giacomo@apache.org wrote:
>>
>>> Author: giacomo
>>> Date: Mon Jan  9 12:12:17 2006
>>> New Revision: 367382
>>>
>>> URL: http://svn.apache.org/viewcvs?rev=367382&view=rev
>>> Log:
>>> try to fix issues with JMX but couldn't test it as current build.sh 
>>> isn't working for a full build
>>
>>
>> build.sh is broken because of the repository flattening.
>>
>> I'm wondering actually how long we should still keep trunk/lib around.
>> It can confuse people into thinking that this way of building is
>> still/will still be supported.
> 
> 
> 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.

2. Follow up for 1): jar names should include timestamps/revisions so 
one can have multiple production sites working on different cocoon versions.

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?

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.

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/

-- 
Leszek Gawron                                      lgawron@mobilebox.pl
IT Manager                                         MobileBox sp. z o.o.
+48 (61) 855 06 67                              http://www.mobilebox.pl
mobile: +48 (501) 720 812                       fax: +48 (61) 853 29 65

Mime
View raw message