ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jean-Louis BOUDART" <jeanlouis.boud...@gmail.com>
Subject Re: EasyAnt <use>/<extends> vs <import>
Date Thu, 13 Nov 2008 14:11:50 GMT
> >> by typing ant -p i can see
> >> org.apache.easyant#build-std-java.compile.iLikeToCompileJavaClasses -->
> i
> >> like to compile java classes :)
> >> org.apache.easyant#build-std-java.myPrefix.plop --> foo bar
>
> > This is what I get with Ant trunk:
>
> > $ ./build.sh -f ../../Temp/u.xml -p
> > Buildfile: c:\Temp\u.xml
>
> > Main targets:
>
> >  compile.iLikeToCompileJavaClasses  i like to compile java classes :)
> >  myPrefix.plop                      foo bar
>
> unless I add an empty target to build-std-java in front of the
> includes.  If I do, I get the same prefixed names that you get.

ok  :)

So what is the expected behavior for prefix nesting?
>
> From my reading of what you expect it should be
>
> * <import> import doesn't contribute to the prefix of <include>d files
>  at all

except if we explicitly give an "as" attribute for <import>


>
> * <include>s stack up to make a longer prefix
>
> Is this independent of whether the as asstribute (for either of the
> tasks) has been specified?
>
> Is there some rationale that makes the rules easy to memorize and
> document?


While using nested <include>, stack up to make a longer prefix (the value of
the as attribute or the imported project's name attribute, if any).
<import> doesn't contribute to the prefix of <include>d files at all except
if we explicitly give an "as" attribute for <import>.






>
>
> If my assumptions are correct then
>
>        private String getTargetPrefix(AntXMLContext context) {
>            String configuredValue = getCurrentTargetPrefix();
>             if (configuredValue != null && configuredValue.length() == 0) {
>                configuredValue = null;
>            }
>             if (configuredValue != null) {
>                return configuredValue;
>            }
>
>            String projectName = context.getCurrentProjectName();
>            if ("".equals(projectName)) {
>                projectName = null;
>            }
>
> +           if (context.isIgnoringProjectTag() && isInIncludeMode()) {
>            // help nested include tasks
>            if (projectName != null) {
>                setCurrentTargetPrefix(projectName);
>            }
> +           }
>
>            return projectName;
>
> should help your caae.  It isn's a complete fix since the prefix for
> included files without "as" doesn't get set before the first target
> (if any) is encountered.


Seems to work, thanks

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message