Return-Path: 
 <dev-return-85223-apmail-ant-dev-archive=ant.apache.org@ant.apache.org>
Delivered-To: apmail-ant-dev-archive@www.apache.org
Received: (qmail 14930 invoked from network); 25 Feb 2010 19:12:32 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3)
  by minotaur.apache.org with SMTP; 25 Feb 2010 19:12:32 -0000
Received: (qmail 23422 invoked by uid 500); 25 Feb 2010 19:12:32 -0000
Delivered-To: apmail-ant-dev-archive@ant.apache.org
Received: (qmail 23369 invoked by uid 500); 25 Feb 2010 19:12:32 -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 23361 invoked by uid 99); 25 Feb 2010 19:12:32 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 25 Feb 2010 19:12:32 +0000
X-ASF-Spam-Status: No, hits=2.2 required=10.0
	tests=HTML_MESSAGE,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of gscokart@gmail.com designates
 209.85.218.227 as permitted sender)
Received: from [209.85.218.227] (HELO mail-bw0-f227.google.com)
 (209.85.218.227)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 25 Feb 2010 19:12:25 +0000
Received: by bwz27 with SMTP id 27so1603410bwz.20
        for <dev@ant.apache.org>; Thu, 25 Feb 2010 11:12:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:mime-version:received:in-reply-to:references
         :date:message-id:subject:from:to:content-type;
        bh=Wi7CVbwyFC4DDnKtvGrtxxb9EBrYYSVFzpGTL+02Gzo=;
        b=RoPLchhWvZpA/vXbeuXKlsEAKIgV86n50FnG72r61on94t8IcKKdyaLFR/IJh1cc68
         wuwGzaL48lemzow9Am3W1OGrho3KdNEwLpr+KEFfZ8gMkI7j7fSrM0UJlyxYykZ/IVHv
         5ui7Q6Hr/3mqUYZQOsJZIsKcZS4+m9LME9mGM=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=slMQIf6aZjEi+SjJnj52c1VE1nb5tkbELJQpPKv+iMqKxHQjjtbrNeoONTd/tie1bo
         l8HXDtYoxC92qKkJpsguwvFp8AhWXXsLStTs+gXIu1op8lvALR9MdAnBHrNLPWNrROKo
         TdhxtiNfeqku2pjXmxlR0uzTJWcX0AjPqVmrk=
MIME-Version: 1.0
Received: by 10.204.33.196 with SMTP id i4mr911586bkd.155.1267125123891; Thu,
	25 Feb 2010 11:12:03 -0800 (PST)
In-Reply-To: <255d8d691002250853r763fe532xdbb0b704bc9cc9fb@mail.gmail.com>
References: <4EEC2385-E3B8-4642-9A62-D786632E21AB@gmail.com>
	 <e9d8a2611002250800y32e788beu328cfda09551a8d@mail.gmail.com>
	 <255d8d691002250853r763fe532xdbb0b704bc9cc9fb@mail.gmail.com>
Date: Thu, 25 Feb 2010 20:12:03 +0100
Message-ID: <e9d8a2611002251112n1f296b97u305f2920a648b027@mail.gmail.com>
Subject: Re: task that allows augmentation of previously declared references
From: Gilles Scokart <gscokart@gmail.com>
To: Ant Developers List <dev@ant.apache.org>
Content-Type: multipart/alternative; boundary=000325554316e542ae0480718e78

--000325554316e542ae0480718e78
Content-Type: text/plain; charset=ISO-8859-1

On 25 February 2010 17:53, Dominique Devienne <ddevienne@gmail.com> wrote:

> On Thu, Feb 25, 2010 at 10:00 AM, Gilles Scokart <gscokart@gmail.com>
> wrote:
> > Did you have any example to demonstrates the benefits of such task ?
>
> The benefits with conjunction with <import> could be important, in
> that you can "mix-in" specialized pre-defined builds dealing with
> specific concerns (like JAXB pre-compilation for example) and have
> those builds "implicitly" augment the classpath or Javac source path
> appropriately for example (as documented in those builds, and you do
> explicitly import those, so are kinda in control).



This is indeed a valuable use case.



> Sure, it does open
> the door for some complexity, and Ant would enter some un-chartered
> waters indeed, but when trying to design reusable builds in the
> (distant now) past, I've often felt the need for such a feature. Yet
> it doesn't necessarily mean that would have been the right solution
> either. I'd be interesting to have the input of the EasyAnt people on
> the matter in fact.


Yes, that would be interresting.


> Maybe an opt-in approach, explicitly adding
> final="false" on those datatype ids *designed* for extension, would be
> a more conservative introduction of this feature, although that does
> force to have "perfect hindsight" into what will be necessary to
> extend/augment or not. --DD
>
>
If we want to allow mutability, it seems indeed safer  to keep immutability
by default (for easier maintainability of the script).

Note that there is an other benefits to immutability : it make it easier to
make multithread system.  The more support ant has for mutable datatype, the
more complex it will be to make it multithread (and I believe that's one of
the important evolution for the coming years).

BTW, isn't already possible to overwrite a reference?  If I remember well,
it prints a warning but it replace the object.

Gilles Scokart

--000325554316e542ae0480718e78--