Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (asf.osuosl.org: domain of ap-cocoon-dev@m.gmane.org
 designates 80.91.229.2 as permitted sender)
To: dev@cocoon.apache.org
From: Jorg Heymans <jh@domek.be>
Subject: Re: [M10N] new repo layout
Date: Thu, 03 Nov 2005 23:51:19 +0100
Lines: 39
Message-ID: <dke498$78n$1@sea.gmane.org>
References: <dkd6c9$ucm$1@sea.gmane.org> <436A2490.9090302@reverycodes.com>
 <dkddpu$rhe$1@sea.gmane.org> <436A45DB.1030600@reverycodes.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
In-Reply-To: <436A45DB.1030600@reverycodes.com>
Sender: news <news@sea.gmane.org>


Vadim Gritsenko wrote:
> 
> Separating meaning they are separate projects with independent release
> cycles, as in:
> 
>>> Where each block is treated as independent project, and has own
>>> tags/branches. With Cocoon 2.1.8 out this friday, several blocks will
>>> start having own tags.
>>

Perfect, my proposed layout covers this use case. Each block will have
its own release cycle, we can even use the maven release plugin to do
releases. I will experiment with this in the mini repo and document my
findings.

> Yes, I mean why do you want to combine multiple projects into single
> uber project, in your proposed directory structure:
> 
>   /trunk
>     /block-a
>     /block-b
> 

...

> It seems like a step backward, towards 2.1 situation, where each block
> is part of single project, instead of moving forward and cutting blocks
> loose...

The single root pom has no meaning other than tying the other modules
together and giving us the possibility of a) defining common stuff and
b) being able to do a full build/release/deploy of all modules with one
command. It does not prevent separate release cycles of the individual
modules however.


Regards,
Jorg