Return-Path: 
 <dev-return-82597-apmail-ant-dev-archive=ant.apache.org@ant.apache.org>
Delivered-To: apmail-ant-dev-archive@www.apache.org
Received: (qmail 94303 invoked from network); 7 Apr 2008 15:08:21 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 7 Apr 2008 15:08:21 -0000
Received: (qmail 65889 invoked by uid 500); 7 Apr 2008 15:08:10 -0000
Delivered-To: apmail-ant-dev-archive@ant.apache.org
Received: (qmail 65822 invoked by uid 500); 7 Apr 2008 15:08:10 -0000
Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:dev-unsubscribe@ant.apache.org>
List-Help: <mailto:dev-help@ant.apache.org>
List-Post: <mailto:dev@ant.apache.org>
List-Id: "Ant Developers List" <dev.ant.apache.org>
Reply-To: "Ant Developers List" <dev@ant.apache.org>
Delivered-To: mailing list dev@ant.apache.org
Received: (qmail 65715 invoked by uid 99); 7 Apr 2008 15:08:09 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 07 Apr 2008 08:08:09 -0700
X-ASF-Spam-Status: No, hits=2.0 required=10.0
	tests=HTML_MESSAGE,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of xavier.hanin@gmail.com
 designates 209.85.200.172 as permitted sender)
Received: from [209.85.200.172] (HELO wf-out-1314.google.com) (209.85.200.172)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 07 Apr 2008 15:07:25 +0000
Received: by wf-out-1314.google.com with SMTP id 27so1525281wfd.10
        for <dev@ant.apache.org>; Mon, 07 Apr 2008 08:07:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        bh=w+PzKp1piq8kH6CK8Cexx5KlLCsqzVneaTvry2ynZQo=;
        b=HtXfLuNRxJDMEwCvcC1KNE6cbVjFWGKD88DcuIVUefnV2zGdjDZFb/ubvD9sNhB30x3GykpmoYZkDLe7hbotaZz1AQ+KlOBLZCwSSM3KWgH5UB/2SI5ug8WN9Fzu5u5zkV9EfB1pCK41QigPXRH5j6z21wKUIvwGDMAFL2ybi28=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=IfF79DPjHTaR3iXxgjxDFjscEqgtjV2+KVil9kvlqXkej0Dix+tJlm0qZvJPZ7kzMJ2o4OhnQX+D876nx421b4nEo/oRRqkq5vu2lz6kaKbVM56Os3Cqirz1tUUjND3GhwUm08Sv042h4wAKpxqtivxi3d9ROIIbWY7UqZtpC6Q=
Received: by 10.142.177.7 with SMTP id z7mr2567750wfe.0.1207580856212;
        Mon, 07 Apr 2008 08:07:36 -0700 (PDT)
Received: by 10.142.255.15 with HTTP; Mon, 7 Apr 2008 08:07:36 -0700 (PDT)
Message-ID: <635a05060804070807p61f468e2m801ed20784495015@mail.gmail.com>
Date: Mon, 7 Apr 2008 17:07:36 +0200
From: "Xavier Hanin" <xavier.hanin@gmail.com>
To: "Ant Developers List" <dev@ant.apache.org>
Subject: Re: EasyAnt POC
In-Reply-To: <y1uve2tzpnu.fsf@v30161.1blu.de>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_24240_2169010.1207580856210"
References: <y1uzls5x3an.fsf@v30161.1blu.de>
	 <635a05060804070607y60f95bf1uf2a09000f9da92ca@mail.gmail.com>
	 <y1uve2tzpnu.fsf@v30161.1blu.de>
X-Virus-Checked: Checked by ClamAV on apache.org

------=_Part_24240_2169010.1207580856210
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Mon, Apr 7, 2008 at 4:48 PM, Stefan Bodewig <bodewig@apache.org> wrote:

> On Mon, 7 Apr 2008, Xavier Hanin <xavier.hanin@gmail.com> wrote:
>
> > On Mon, Apr 7, 2008 at 2:22 PM, Stefan Bodewig <bodewig@apache.org>
> wrote:
>
> >> Extends and Use
> >> ===============
> >>
> >> I'm not sure I fully grasp the difference.  Currently we prefix
> >> target names as well, just in addition, don't we?
> >
> > Yes, but this is not enough. Imagine you have two files like this:
> > moduleA.xml:
> > <target name="init" />
> > <target name="run" depends="init" />
> >
> > moduleB.xml:
> > <target name="init" />
> > <target name="test" depends="init" />
> >
> > Then if you import both, and execute the "test" target, you can't be
> > sure the init target of the same build file will be executed. It
> > depends on the order in which the files are included.
>
> in moduleB.xml you'd rather say <target name="test"
> depends="moduleB:init"/>
> should work with import today.

Yes, but then you have to always think about prefixing your target
dependencies in B. And if you want to avoid collisions, you need to use
fully qualified names for your modules, so your target would be <target
name="test" depends="org.foo.bar.moduleB:init"/>. With several target
dependencies, it becomes quickly ugly:
<target name="test" depends="org.foo.bar.moduleB:init,
org.foo.bar.moduleB:prepare, org.foo.bar.moduleB:assert"/>


>
>
> >> Phase
> >> =====
> >>
> >> Should we enforce that the special targets created as phases are
> >> empty?
> >
> > Well, I'm not sure. The problem is who is responsible for defining
> > the phase content? By enforcing they are empty, we can be sure they
> > are used as placeholders to organize the build, and that's all.
>
> OK, let me rephrase my question to make sense: "I think we should
> enforce phase targets to be empty but don't see any code that does it.
> Do you agree that we should?"  Your answer looks as if you would 8-)

Indeed :-)

>
>
> >> Does phase mapping come from a specific use-case?
> >
> > Not really, it's inspired by configuration mapping in Ivy, which is
> > a key of integration of modules developped by different people at
> > different time.
>
> Right now it is confusing me and I'd rather want to understand when it
> would be useful.
>
> > The same can apply to build modules development, and phase mapping
> > can help to integrate pretty different build modules.
>
> Do you have an example for dumb me 8-)


Let's say that I have a module A which has been designed to be used with 2
phases: generate, compile
module B from another organization has been designed to be used with 5
phases: generate-src, compile-src, generate-test, compile-test and test

If I want to integrate both modules in one build, I may choose to define 5
phases (the same as for module B), and map generate to generate-src and
compile to compile-src when using module A.

Does it make sense?

>
>
> > It's also useful if you want to execute some targets at a different
> > than what they were designed to be, giving more control to the build
> > integrating the build modules.
>
> Where do you expect this flexibility to be required?

I think one of the key aspect of the build system I'm thinking about is
flexibility. If you don't need something flexible, you should better use
maven, because it exists. In a system where you let people define their own
phases, you need to let control to the people who assemble the build
modules.

Xavier


>
>
> >> You talk about "before" targets but I don't seem them implemented,
> >> yet.  Am I missing something?
> >
> > I don't remember, but you're probably right. I haven't implemented
> > everything that I first though about, just what I need for the first
> > POC.
>
> OK, I didn't expect a POC to be anything complete.  I just wanted to
> be sure I wasn't overlooking anything.
>
> Thanks
>
>        Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>


-- 
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/

------=_Part_24240_2169010.1207580856210--