Bug 49659 - [regression] Project.getReference(key) no longer returns certain references
Summary: [regression] Project.getReference(key) no longer returns certain references
Status: NEW
Alias: None
Product: Ant
Classification: Unclassified
Component: Core (show other bugs)
Version: 1.8.2
Hardware: PC Linux
: P2 normal (vote)
Target Milestone: ---
Assignee: Ant Notifications List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-07-28 11:17 UTC by Michael Rennie
Modified: 2010-12-27 11:13 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Rennie 2010-07-28 11:17:23 UTC
Working on updating Eclipse to use Ant 1.8.1 I found that we have numerous test suite failures around popup /completion proposals. I tracked the problem back to where we try to look up a path element by its id.

The following is the test build file that fails:

<project default="1">
	<path id="project.class.path">
		<pathelement location="lib/" />
		<pathelement path="${java.class.path}/" />
		<pathelement path="${additional.path}" />
	</path>
	
	<target name="1">
		<path id="project.class.path2">
			<path refid="project.class.path" />
		</path>
	</target>
	<target name="compile">
		<javac srcdir="src"
	       destdir="dst"
	       classpathref=""
	       sourcepathref=""
	       bootclasspathref=""
	       debug="on" />
	</target>
	<target name= "depends" depends=" compile  , 1 ">
	</target>
	<property name="name with spaces" value="value with spaces"/>
	<fileset dir="dir" id="filesetTest">
	    <include name="include"/>
	    <exclude name="exclude"/>
	</fileset>
	<patternset id="patternSetTest">
			<include name="*.xml"/>
			<exclude name="**/*Test*"/>
	</patternset>
	<patternset id="patternSetTestBad">
		<includesfile name="nothere"/>
	</patternset>
	<echo>${name with spaces}</echo>
	<fileset refid="filesetTest">
		<patternset refid="patternSetTest"></patternset>
		<patternset refid="patternSetTestBad"></patternset>
	</fileset>
</project>

During our tests we try to look up the element "project.class.path". In versions < 1.8.* this worked fine, however in Ant 1.8.1 the lookup will always result in null being returned.

I tracked the cause to Project.getReference(key), where you used to lookup the element in the idReferences map to try and resolve it if it did not appear in the references mapping. 

Perhaps AntRefTable.get(..) needs to also consult the idReferences cache in the event of a miss?
Comment 1 Stefan Bodewig 2010-08-09 16:02:46 UTC
I'm not sure how you are getting your project instance.  What has been done by Ant before you try to look up "project.class.path"?
Comment 2 Michael Rennie 2010-08-10 10:26:12 UTC
(In reply to comment #1)
> I'm not sure how you are getting your project instance.  What has been done by
> Ant before you try to look up "project.class.path"?

We have a subclass of Project - AntModelProject - that allows us to hook into getting user properties and knowing when a build is done. When we create our project instance we simply call Project.init() on it, set a few system properties and set some custom tasks and types using ComponentHelper.

Ant handles the parsing of the buildfile, although we do have some logic to try optionally configuring Task nodes after parse, but this also no longer works for the same reason mentioned above. We do have our own copy of ProjectHelper, but 99% of the code in it is a direct copy from Ant with a few additional hooks for us.
Comment 3 Michael Rennie 2010-12-14 15:53:33 UTC
Would have been nice to have this fixed in Ant 1.8.2.

I spent some time doing some more debugging of the org.apache.ant source and found that during the parse of a build file in 

ProjectHelpr2$ElementHandler#onStartElement(...)

a call is made to AntXMLContext.configureId(...) which maps the UnknownElement to its id in Project#idReferences. Prior to Ant 1.8.0 you could then look up these UnknownElements by passing their id into Project#getReference. This no longer works as mentioned in comment #0.
Comment 4 Antoine Levy-Lambert 2010-12-14 16:24:15 UTC
Hello Michael,

sorry I have not been active in reading bug reports recently :(

In Ant 1.8.0 I think that the possibility of using references which were detected at parse time has been removed. The ant targets only see the references which have been defined in targets previously executed.

Probably when this was changed the needs of API clients such as the Eclipse integration had not been taken into account.

Let's see what the other committers think about this.
Comment 5 Michael Rennie 2010-12-15 09:56:37 UTC
(In reply to comment #4)
> Hello Michael,
> 
> sorry I have not been active in reading bug reports recently :(
> 
> In Ant 1.8.0 I think that the possibility of using references which were
> detected at parse time has been removed. The ant targets only see the
> references which have been defined in targets previously executed.
> 
> Probably when this was changed the needs of API clients such as the Eclipse
> integration had not been taken into account.
> 
> Let's see what the other committers think about this.

Sounds good.