I was just saying that Ant benefits/(or suffer...) from great flexibility, and you should not change that.
Things like the declarative nature of the targets and global properties participate to this flexibility. The fact that you can overwrite target is also a good support for flexibility. I'm not in favour of adding new features to the language just to allow reducing the flexibility. You can add that on top of the language if you want, but it should not be embedded in the language itself. Ant is language with a simple declarative syntax and a rich set of domain specific 'commands'. The evolution of ant should be first the enrichment of the domain specific commands, then only enhance the declarative syntax. But IMHO it is better to limit those changes to things that could not be done outside the language in order to keep that part of ant as simple as it could. Moreover, there is a big issue with 'final' like keyword. It implies that you must be able to anticipate all the possible extensions of your code when you write it. It is already difficult to do in OO languages that have extension via inheritance as a root paradigm. I think it is not possible with a language like ant. Gilles > -----Original Message----- > From: Xavier Hanin [mailto:[EMAIL PROTECTED] > Sent: mercredi 16 janvier 2008 9:53 > To: Ant Developers List > Subject: Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java > projects > > 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/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
