Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Ant Developers List" <dev@ant.apache.org>
Received-SPF: pass (athena.apache.org: domain of gscokart@gmail.com designates
 72.14.202.179 as permitted sender)
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=VH5JWAfiCV+93bQ33VfgCdSzXKBz0KxZpe8Flh/lWImKCit4Bz9rDEWRShRqRImZvthf+e0oDeG/nSdx2ljKHm/RXLsMULuxDhrqDiyvt+SKQKv4nrz7HTIWkzh+1v+brqxWtBEMlxrE6fR31B8aRzxt96ZRViU/s+pMN0YQt1M=
Message-ID: <e9d8a2610801152354p25aac9aax14698866c1af8397@mail.gmail.com>
Date: Wed, 16 Jan 2008 08:54:30 +0100
From: "Gilles Scokart" <gscokart@gmail.com>
To: "Ant Developers List" <dev@ant.apache.org>
Subject: Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java
 projects
In-Reply-To: <478D30A7.2040603@oracle.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_16074_13790205.1200470070717"
References: <20080114205825.4olx878qsgocwg44@zeus.private>
	 <y1uk5mbk5wv.fsf@v30161.1blu.de>
	 <e9d8a2610801150000l59950798raa99cfe528e7746a@mail.gmail.com>
	 <478CFDF9.1000302@oracle.com>
	 <255d8d690801151211v43ea405fpf5c96ada338f6988@mail.gmail.com>
	 <478D30A7.2040603@oracle.com>

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

2008/1/15, Louis Tribble <louis.tribble@oracle.com>:
>
> Dominique Devienne wrote:
> > On 1/15/08, Louis Tribble <louis.tribble@oracle.com> wrote:
> >
> >> Consequently, my main comment (apologies if I missed it in the thread)
> >> is that any magic target overriding feature needs to balanced by
> >> a target locking feature, for at least two reasons: (1) the integrity
> of
> >> the
> >> build depends on certain chunks of script (typically in the xxx-default
> >> targets) always being invoked and (2) nobody can understand and
> >> manage a build of 500 modules if modules do their own thing even for
> >> basic tasks like compiling and creating jars.
> >>
> >
> > This is interesting. So you want some kind of "final" keyword for a
> > target, to allow controlled customization only, right? Basically the
> > template method pattern, with an immutable public target, and only
> > limited customization.
> >
> Right. In fact, we were very conscious of applying design
> patterns to the build system.
> >
> >> A corollary is that if I were to base this system on the hypothesized
> >> Ant-supplied system, I expect I would need to customize quite a bit,
> >> but I would not want to expose most of that customizability to the
> >> modules. (Perhaps that is something like what Gilles was thinking
> >> when he mentioned two levels of customization?)
> >>
> >
> > That's where I'm confused. You want to be able to customize in some
> > places, but not in others??? I don't quite follow what you mean here.
> >
> Sorry if I wasn't clear. Xavier was suggesting (in part) a set
> of reusable build scripts. To be useful, those scripts need to
> be customizable in a variety of ways, which led to the
> discussion of super and before/after and so on. I was noting
> that if we were to implement our build system on top of these
> reusable scripts, we no doubt would be stretching the
> customization hooks to their limit, but we will want to significantly
> limit what individual module developers can customize.
>
> A couple of particulars that come to mind with our
> compile-default target:
>
> The sourcepath, classpath, and output directory for
> each module are dictated by the build system, not the
> module (so we would want to configure that, but not
> let module developers reconfigure it).
>
> Before the actual compile, we convert the property files
> containing translateable resources to Java files and maintain
> a list of all files needing translation (the translation team,
> which services the entire company, uses that list to drive
> their translations).
>
> In the postulated reusable script scenario, our standard resource
> preprocessing would presumably be plugged in to the
> public distribution as a before target. We want to allow
> modules to provide their own before targets, but not allow
> them to mess with our standard one.
>
> (Actually, while I'm at it, we reflexively provided before and
> after targets for the test phase, which seems to have been a
> mistake. The chief use has been to set up test
> fixtures (starting and stopping web servers, etc), which
> would have been more robust and reusable if done from
> within the JUnit test classes.)
>
> Louis
>
> > --DD
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> > For additional commands, e-mail: dev-help@ant.apache.org
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
I'm not favorable to have such restricting feature embbed in the language.
These kind of things have their place in generic strict imperative language,
not in a scripting language, not in declarative language, and usually not in
domain specific language.  And IMHO, Ant is a declarative, domain specific
scripting language.

To put in place such restriction in Ant, you should rather have coding
standards, guidelines or policies, maybe enforced by a PMD-like validation
(I don't know if that exists for ant).

-- 
Gilles Scokart

------=_Part_16074_13790205.1200470070717--