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