> >> 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
