|
|
|
Gus, you've met with another issue, namely not loading classes declared in the resource file. It is already fixed, but for more proper editing and highlighting, I'd recommend to use classpath attributes in taskdefs where possible.
I'm not sure I understand your comment. It may be that there are several bugs with IDEA's handling of taskdef, but from a user point of view the following things do NOT work in 5766
1. the taskdef for antcontrib above that references a property file. 2. taskdefs using a classpath ref. <taskdef (where the path is defined in and imported from our build-classpath.xml like this 3. (unsuprisingly) the combination of the two also does not work <!-- this loads <emma> and <emmajava> custom tasks: --> 4. included classpath almost works but all the attributes for the taks are red (this was a problem in 5.1 also) <taskdef name="junit" So whether it is one bug or several bugs, every aspect of taskdef is broken in at least some way and it is impossible to write any but this absolute simplest build files without a lot of red marks in the gutter, and useless complaints about errors when I checkin any set of files that includes a build file (unless I tell it not to perform code analysis for the effected files). Given that nothing works a general bug about taskdef seems appropriate. I did not find bugs for the current release that described these cases individually (my search may have been faulty of course). If this should be split into separate bugs or duplicates existing bugs let me know I'll be happy to watch/file those instead. If you've fixed one or all of these cases then thank you! |
|||||||||||||||||||||||||||||||||||||||||||||||
<taskdef resource="net/sf/antcontrib/antcontrib.properties">
<classpath>
<pathelement location="${lib}/${lib.ant-contrib}"/>
</classpath>
</taskdef>
<if> and <var> are not recognized, and taskdef is underlined in red saying "failed to load type"
The problem also occurs for emma, and our custom tasks too.
All of this had been green before the upgrade, and all the location specified above for the pathelement does correctly point to the jar.