Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
To: dev@cocoon.apache.org
From: Nicola Ken Barozzi <nicolaken@apache.org>
Subject: Re: What's wrong with our build system?
Date: Tue, 25 May 2004 10:22:13 +0200
Lines: 64
Message-ID: <c8uvo3$2gl$1@sea.gmane.org>
References: <41303.10.0.0.5.1085433531.squirrel@ags01.agsoftware.dnsalias.com>
 <9D9078A6-AE1F-11D8-B49A-000A95AF004E@apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
In-Reply-To: <9D9078A6-AE1F-11D8-B49A-000A95AF004E@apache.org>
Sender: news <news@sea.gmane.org>

Bertrand Delacretaz wrote:

>> ...I propose to move Cocoon to Maven. Please VOTE:
> 
> I know the vote is canceled, but maybe we can talk about the problems 
> before looking at a solution?

+1

> IMHO these are the problems of the current build system:
> 
> 1) Monolithic repository makes it impossible to include libraries having 
> non-ASF compatible licenses.
> 
> That's the big thing for me, specially as it causes a big loss of energy 
> discussing licenses for library X or Y instead of just hosting these 
> cool components in non-ASF repositories.
> 
> I know Real Blocks will solve this, but does anyone see Real Blocks 
> happening in the near future?
> 
> 2) Monolithic repository requires a big download before being able to do 
> anything with Cocoon.
> 
> I might be wrong but I don't see any other issues with the current build 
> system.
> 
> IMHO, being able to include parts of external repositories in the build 
> (by getting them dynamically from their CVS or SVN repositories at build 
> time) would bring most of what people are waiting for in Real Blocks.

http://incubator.apache.org/depot/

in particular

http://incubator.apache.org/depot/update/

The current SVN version gets the jars specified in the gump xml file too.

                    - 0 -

As for our build, there is another thing that should be done to make it 
better, as the current xsl-based hack I had put up was needed with Ant 1.5.

Now that we have Ant 1.6, we should instead do this:

1 - make a block-build.xml file in the blocks dir that contains
     a default block build file.
2 - add a build.xml file to every block with
       <import file="../block-build.xml">
3 - in each block build.xml file we can add extra targets or
     override the ones imported
4 - use <subant> to make the build system call all block buildfiles


This is how to set up in Ant what Maven calls the "reactor". I was 
waiting to see the switch to SVN to test it on a branch, but since you 
came up with this thread, I thought I'd share it now :-)

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------