On Jan 10, 2008 9:13 PM, Xavier Hanin <[EMAIL PROTECTED]> wrote: > On Jan 10, 2008 7:21 PM, Peter Arrenbrecht <[EMAIL PROTECTED]> > wrote: > > > Providing > > override hooks is all well and good, but that is still basically the > > very controlled and rigit maven approach, I think. > It depends on what you accept to do in your override. If the build system > somewhat relies on Ant import mechanism, you are able to override any > target defined by the build system. In the end if you have something very > specific the worst that could happen is override everything, making the > build system useless except it first provided a structure. But at least you > are always free, which is not the case with maven.
Then by all means let's use import. This is exactly what I meant. > > It's like the > > difference between an interpreter and a code generator. IIRC, in Rails > > you normally get interpretation (on the fly code generation, in fact), > > but you can always switch to full blown code generation which you can > > then inspect and tweak. I think that is part of the reason for its > > success. It makes the whole thing transparent, but let's people stick > > to the standard where that suffices. > Interesting comparison, not sure how it could be applied to the build system > though. IIRC, custom Maven steps are written in Java. You cannot look at the provided build logic in the language you are working in to describe your build. So Maven is an interpreter. The envisioned Ant build template would feel more like on-the-fly code generation (import could be thought of as inlining its stuff), with the option of truly inling the code for tweaking. Background on this way of looking at it: http://peomeint.blogspot.com/2005/10/debugging-domain-specific-languages.html -peo --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
