Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <4315E6CD.6000407@apache.org>
Date: Wed, 31 Aug 2005 13:20:13 -0400
From: Stefano Mazzocchi <stefano@apache.org>
User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [2.2] Past, present and future of the maven build
References: <431451AF.1020206@apache.org> <43147BE2.8070908@dslextreme.com>
 <4314C907.4050102@gmx.de> <df3lge$g48$1@sea.gmane.org>
In-Reply-To: <df3lge$g48$1@sea.gmane.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Nicola Ken Barozzi wrote:
> Joerg Heinicke wrote:
> 
>>On 30.08.2005 17:31, Ralph Goers wrote:
> 
> ...
> 
>>>So to summarize, I would suggest that it would be a good idea for each
>>>"component" - be it core or a block - to have api, impl, test and
>>>samples projects.
>>
>>Did I mention that I hate tools needing changes in the subject they
>>should work on to make them work? The above scenario and the other
>>mentioned necessary restructurings were the reason why I ever were
>>against a change of the build system to Maven.
>>
>>Ok, we really have a problem with our current build system. Nobody (me
>>included) started with another solution like Ant 1.6 or similar. The
>>Maven fraction started now to address the problem and I'm ok with it.
>>The above rant probably just shows I'm a smart-ass ;-)
> 
> 
> If you, or me, or anyone would have really gone deep in fixing the Ant
> build system, we would have been forced to do the same restructuring.

FYI, i wrote considerable chunks of ant with my desire to have a build 
system that could stand the complexity of cocoon. For a long time, you 
could build cocoon only with the version of ant that shipped with it.

I wouldn't be against shipping maven2 with cocoon 2.2 for the time being.

Wherever cocoon uses, it will stretch it and maybe break it. We are one 
of the most complex (in terms of dependency and use of different 
technologies/languages) software systems in the java world.

So, let's not be afraid to taste a little blood on the bleeding edge.

-- 
Stefano.