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.
Summary: | Deser of AntProjectSupport with new project unreliable | ||
---|---|---|---|
Product: | projects | Reporter: | Jesse Glick <jglick> |
Component: | Ant | Assignee: | David Konecny <dkonecny> |
Status: | CLOSED FIXED | ||
Severity: | blocker | CC: | dieterl, mihmax, pkeegan |
Priority: | P2 | ||
Version: | 3.x | ||
Hardware: | PC | ||
OS: | Linux | ||
URL: | http://www.netbeans.org/servlets/ReadMsg?msgId=345702&listName=nbusers | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: |
stack trace of NPE
Suggested debugging patch (not patch to solve bug) patch patch2 zip file with "modules/ant.jar" |
Description
Jesse Glick
2002-07-16 18:05:27 UTC
Created attachment 6733 [details]
stack trace of NPE
Created attachment 6734 [details]
Suggested debugging patch (not patch to solve bug)
When I switch the project and try to compile Rara.java I always get the NPE and "Script" property of "[foo|bar] comp" is always "<missing Ant script>". Created attachment 6755 [details]
patch
Attached is patch for this problem. I decided to implement your first suggestion. Could you please skim it and let me know if you have some objections? Thanx. The exception message from IndirectAntCompilerType is not quite right... perhaps it should rather say: # {0} - node display name # {1} - display name of compiler type The object {0} is configured to use {1} but the build script can no longer be found. updateFileObject() as written is wrong: if FSIE is thrown, then fileName != null && fsName == null, so resolveFileObject will throw NPE etc. If FSIE is thrown make sure you null out *both* variables. getNameExt() is also wrong - you want getPackageNameExt('/','.') I think. Otherwise the patch looks right to me. Does it work? Created attachment 6783 [details]
patch2
Created attachment 6784 [details]
zip file with "modules/ant.jar"
Thanx Jesse, apart from getNameExt() I implemented your comments. getNameExt() according to JavaDoc "Getter for name and extension of a file object. Dot is used as separator between name and ext.". The patch works fine. Before I commit it into CVS I would like to ask Dieter if he could donwload the attached zip file containing ant.jar file and put it into his NB3.4B3 (into modules folder) and try whether his problem was fixed as well. Based on feedback I will commit and apply for integration into NB3.4. I installed the patch instead the original jar file, delete the compiler, delete the projects (not completly ...) create all new but the problem I have is not solved. But the problem with NPE for really new projects seems to be solved. Maybe my problem is because I created the projects with an older NB (NB3.4B1, I guess). If I can help you with any other information, please ask me. getNameExt() is not correct AFAIK - it does not include the folder path, only the name of the file object within its folder! I assume you did not test the patch using a build.xml in a subdirectory of the root of a mounted filesystem, only directly in the root. FileSystem.findResource expects the full path of course. Target milestone was changed from '3.4' to TBD. Maybe we should integrate the known patch and merge it, since there is a reproducible NPE solved by it, and Dieter can open a fresh bug for his problem if he can provide steps to reproduce it. OK, I will fix it in the trunk and test it as much as I can and can try to ask for nb34 integration. Again I'm in favor of puting the fix into NB 3.4.1. I don't think this is showstopper. Although it is serious problem it had to be there for a long time. The functionality (projects & indirect compiler) is simply not used by users what means that they will not miss it if it won't work, otherwise this defect would be filed long time ago. But I will try to get it into NB34. I'm going to further test it. You were of course right Jesse that getNameExt must be used. Fixed in files: Checking in src/org/apache/tools/ant/module/run/Bundle.properties; new revision: 1.13; previous revision: 1.12 Checking in src/org/apache/tools/ant/module/run/IndirectAntCompilerTyp new revision: 1.7; previous revision: 1.6 Checking in src/org/apache/tools/ant/module/xml/AntProjectSupport.java new revision: 1.19; previous revision: 1.18 Diff URLs: <http://ant.netbeans.org/source/browse/ant/src/org/apache/tools/ant/mo dule/run/Bundle.properties.diff?r1=1.12&r2=1.13> <http://ant.netbeans.org/source/browse/ant/src/org/apache/tools/ant/mo dule/run/IndirectAntCompilerType.java.diff?r1=1.6&r2=1.7> <http://ant.netbeans.org/source/browse/ant/src/org/apache/tools/ant/mo dule/xml/AntProjectSupport.java.diff?r1=1.18&r2=1.19> The fix was reviewed by Jesse. It is integrated in trunk and was tested by Milan. I think that this bug is not stopper for release34 (only stoppers can be intagrated now), since it's there very long time. Fix should be integrated to post-release34 release. Should we mention it in Release notes? Mentioning it in RELNOTES make sense. Putting Patrick on cc:. David or Jesse, could you provide a brief description and a workaround (if applicable)? Brief? That will be problem.... If an AntIndirectCompiler is used in the project and the build script defined in the AntIndirectCompiler lies on the filesystem mounted in the project, after switching to this project in NetBeans the link to build script will be invalid and must be set again. There is no workaround. If user does not switch projects in NB this problem will not happen. If NB IDE is started with this project, the problem will not happen - it happens only when you switch to project. If the build script lies outside of the mounted filesystems the problem will not happen. Here is my attempt to shorten this: "If you use indirect Ant compilation in a project and the build script defined in the AntIndirectCompiler lies on the filesystem mounted in the project, the link to the build script will become invalid if you switch to another project and then switch back to that project. You will need to reset the link to the build script every time you switch back to that project. This problem will not occur if you never switch projects or if the build script is not in a mounted filesystem." Another qualification to add to the release notes: The problem only occurs if you explicitly customize Indir Ant Comp to point to a specific build script. Its default behavior is to search for a build.xml in the directory in which the file to be compiled resides, or the nearest parent directory up the file tree containing a build.xml file. (This behavior is akin to Ant's regular -find switch.) This default behavior should be unaffected by #25701, because I.A.C. will find the build.xml from scratch each time it is run, so a project switch is irrelevant. Could easily be added to an update release I guess. Link to diffs: <http://ant.netbeans.org/source/browse/ant/src/org/apache/tools/ant/module/run/Bundle.properties.diff?r1=1.12&r2=1.13> <http://ant.netbeans.org/source/browse/ant/src/org/apache/tools/ant/module/run/IndirectAntCompilerType.java.diff?r1=1.6&r2=1.7> <http://ant.netbeans.org/source/browse/ant/src/org/apache/tools/ant/module/xml/AntProjectSupport.java.diff?r1=1.18&r2=1.19> Diffs look OK to me. For the future Repository.findResource is not good to use - will be pretty useless with disk roots mounted, so prefer to use e.g. FileUtil.{to,from}File, or just trust that FileObject serialization is more robust under the uni filesystem. But this minor comment does not matter at all for 3.4. Integrated in NB341. (Jesse, thanx for the note about Rep.fR) removing RELNOTE keyword since this has been fixed Closed |