On Jan 16, 2008 8:54 AM, Gilles Scokart <[EMAIL PROTECTED]> wrote: > 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.
Could you argue a little bit more? I don't see why we couldn't provide an extension limiting feature to people building build systems from Ant. In large development teams, build team sometimes suffer from developers hacking the build system instead of talking with the build team to get what they want, which can end up in maintenance headaches. Being able to clearly define what can be customized/extended in a build system would be a very good feature for such build teams. I don't know if we would use this kind of feature in EasyAnt, because as I see it it needs to be extremelly flexible. But giving this feature for people who use Ant directly or just want to extend EasyAnt by restriction would be a good thing for such large environment IMHO. Xavier > 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 > -- Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/ http://ant.apache.org/ivy/ http://www.xoocode.org/
