This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
If a xml file is included into build.xml using a http url, the targets located in the include file isn't displayed in the explorer The start of my build.xml file looks like this <?xml version="1.0"?> <!-- Define the entity buildsystem to point to buildsystem/common.xml --> <!-- You may need to adjust the path of the buildsystem isn't checked out above current directory --> <!DOCTYPE project [ <!ENTITY buildsystem SYSTEM "http://donald.dannet.dk/buildsystem/common.xml"> ]> <project name="perfmon" default="all" basedir="."> <!-- Define properties used by buildsystem --> <property name="project" value="${ant.project.name}"/> <property name="version" value="v100"/> <!-- This property holds a comma-seperated list of packagenames for --> <!-- which there should be generated javadoc --> <property name="packages.javadoc" value="dk.dannet.perfmon"/> <property name="build.compiler" value="modern"/> <!-- Include buildsystem/common.xml --> &buildsystem;
I don't see this being fixed anytime soon. The problem is that if you show objects from included files, you have to decide what to do if changes are made from the Explorer. Update the included file? Very risky as it could be included from something else too. Make these objects read-only? Perhaps, though somewhat strange UI.
*** Issue 25440 has been marked as a duplicate of this issue. ***
Not going to be fixed anytime soon. Perhaps when Ant module is rewritten to use the XML support.
I see the point about the difficulty in how to keep supporting the editing of ant build files if includes are involved. However, what if you simply have a rule that says "if the ant file contains includes, it is considered readonly in the gui and will parse it properly"? This could be combined with a switch in the IDE user options which allows the user to select what he/she prefers: the current non-fully-parsing but read/write behaviour, or the alternative readonly fully parsing behaviour (this choice being only excercised when there are includes present in the ant file.). I doubt that any further clever features would ever be needed. A full read/write fully-parsing infrastructure would be over the top IMHO. I'd always have the option to edit the include file directly as text, which is fine by me. People who use includes will either be able to edit the XML directly, or will have obtained the project from somewhere else and will therefore not want to modify the build file (unless you know what you're doing).
I think it would suffice to make all files with entity includes r/o in the Explorer and leave it at that (no option is really necessary). Probably not so hard; not sure if it will make sense to implement it or whether we will get real XML support soon anyway.
*** Issue 29883 has been marked as a duplicate of this issue. ***
For Ant 1.6 the same concern applies to <import>ed scripts. Might skip support for DTD-based entity includes since these are essentially obsoleted by the <import> directive.
Should probably fix this for D at least for <import>.
*** Issue 41001 has been marked as a duplicate of this issue. ***
*** Issue 42069 has been marked as a duplicate of this issue. ***
Waiting for issue #20532 is unrealistic.
Could be useful for various project types, not just j2seproject.
*** Issue 43200 has been marked as a duplicate of this issue. ***
See commit info in issue #44360.
*** Issue 46631 has been marked as a duplicate of this issue. ***
verified in NB 5.0