On Wed, Nov 5, 2008 at 9:59 AM, Stefan Bodewig <[EMAIL PROTECTED]> wrote: > IIUC EasyAnt solits the two use-cases found for <import> into two > logical tasks. > > * you never want to override a target, you just want to reuse them: <use>
That's an <include> to me. Rename <use> into <include>, and I'm +1, even with the forced prefix (from build file or @as) to included targets. > * you may want to override some/most targets: <extends> That's the current <import> indeed. > Technically <extends> is what <import> is today. <import>ed targets > that haven't been overwritten in the main build are known under two > names (prefixed and not prefixed) and the depends lists of the targets > in the <extends>-imported file are not rewritten. > > Targets coming from a <use>d file only exist in their prefixed form > and their dependencies are rewritten to include prefixes as well. > I.e. you can not override the <use>d target's dependencies. > > There has been some confusion from time to time on the user list as to > how you can ensure you get "your" target and not an overwritten one in > an imported file, so I think <use> is useful outside of EasyAnt as > well. > > EasyAnt also adds an as-attribute to <use> where the writer of the > importing build file can control the prefix of the <use>d targets and > overrules the <use>d project's name. This makes sense IMHO. It does to me too :) > I'm not totally sure whether the as-attribute would make sense for > <extends> as well, EasyAnt currently silently ignores it in that case. It makes as much sense in <import> as it does in <include> to me, i.e. to restore proper compartmentalization of the builds. > Changes would be required to the import task as well as to > ProjectHelper2 (the specific patch also patches AntXMLContext and > ProjectHelper, but that may turn out to be not necessary. It's an > implementation detail). > > Opinions? I don't think we should invent new terminology (use/extends) for something that already exists (import) and it's natural equivalent to use (include, which doesn't exist). The import/include difference already exists in XSLT. It's not that import/include is *better* than use/extends, it's that they are a fairly well known precedent, especially given that we already have import in Ant. What's missing from the above is the notion of TargetGroup to implement the phase concept of EasyAnt (and Maven I guess). Although it's possible to tack this on to Target, having a separate class to model this would be better IMHO. --DD --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
