ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gilles Scokart" <gscok...@gmail.com>
Subject Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
Date Wed, 16 Jan 2008 07:54:30 GMT
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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message