cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
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:03:00 GMT
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.

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

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

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

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

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

/Daniel

Mime
View raw message