cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jorg Heymans>
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 10:54:56 GMT

Leszek Gawron wrote:

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

If you want to deploy your own project artifacts (say a custom block)
then you would just mvn release this to your repo. Why would you need to
modify cocoon's pom.xml ?

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

snapshots can be made with a timestamped name. The SVN revision is not
included at the moment IIRC, you might want to raise this with the maven
people. I remember maven1 has something that allows the svn revision to
be included in META-INF for example.

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

I reckon similar mechanisms will crystalize out of our build system once
more people get involved.


View raw message