2008/1/15, Louis Tribble <[EMAIL PROTECTED]>: > > Dominique Devienne wrote: > > On 1/15/08, Louis Tribble <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > 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
