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: | Unable to build project on UNC path | ||
---|---|---|---|
Product: | projects | Reporter: | Tomas Danek <musilt2> |
Component: | Ant | Assignee: | Jesse Glick <jglick> |
Status: | VERIFIED FIXED | ||
Severity: | blocker | CC: | anebuzelsky, dlipin, jskrivanek, lhasik, lvskiprof, mkubec, mmirilovic, pchytil, psunb |
Priority: | P3 | Keywords: | RELNOTE |
Version: | 6.x | ||
Hardware: | PC | ||
OS: | Windows XP | ||
URL: | https://issues.apache.org/bugzilla/show_bug.cgi?id=42275 | ||
Issue Type: | DEFECT | Exception Reporter: | |
Bug Depends on: | |||
Bug Blocks: | 46813 | ||
Attachments: | Output of ant -v -f "\\computer\share\ShowMessage\build.xml" |
Description
Tomas Danek
2008-09-11 14:27:37 UTC
Maybe an Ant problem. Can you build from the command line? well, AFAIK windows commandline does not support UNC path. But tried in Cygwin: cd \\\\tm-ws\\sharedLoc\\JavaApplication8 ant jar Builds the app OK. How do you actually created such a project? I tried that and 1) filechooser doesn't allow me to select UNC path 2) if I type it manually I get message "Project Folder is not a valid path" (I'm trying on MS Vista though) well, i did not use UI, i just typed "\\tm-ws\sharedLoc" in project location. If I do that I get "Project Folder is not a valid path" message and disabled Finish button. I will try Windows XP. It's indeed reproducible, you just need to enter the whole path in the wizard, then Finish button gets enabled. But I still think that it's problem of Ant tool itself. From the following error message it seems to be obvious: ... parsing buildfile \\MILANKUBECF003\Sdileno\JavaApplication2\build.xml with URI = file:////MILANKUBECF003/Sdileno/JavaApplication2/build.xml - this is OK, the build script is found correctly ... Project base dir set to: \\MILANKUBECF003\Sdileno\JavaApplication2 - Also correct ... Importing file C:\MILANKUBECF003\Sdileno\JavaApplication2\nbproject\build-impl.xml from C:\MILANKUBECF003 \Sdileno\JavaApplication2\build.xml - And here is the problem: import task tries to load imported script (that is defined relatively) from bad location ... C:\MILANKUBECF003\Sdileno\JavaApplication2\build.xml:7: Cannot find nbproject/build-impl.xml imported from C:\MILANKUBECF003\Sdileno\JavaApplication2\build.xml at org.apache.tools.ant.taskdefs.ImportTask.execute(ImportTask.java:134) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) I don't think that IDE can do much about it. Jesse, do you have any idea? BTW, if I type the command from the terminal - it works fine. Created attachment 69948 [details]
Output of ant -v -f "\\computer\share\ShowMessage\build.xml"
... but it created folder C:\sard.russia.sun.com\.... which is certainly wrong.:() Looks like "-javadoc-build" creates that wrong directory (C:\sard...). If I run only "ant -v -f ... clean jar" - then it is not created at all. If the issue can be reproduced from a command shell, should be filed on ant.apache.org. Otherwise, please assign to ant/code with a minimal reproducible test case. You are right, running the script from cmd line using 'ant -f \\... ' works OK. Then indeed the problem is in IDE. The minimum testcase is creating j2seproject in some UNC path folder and then Clean and Build the project in IDE. I always get "Project Folder is not a valid path" when I try to create the project, whether I use the file chooser or just enter the desired path directly as text. This is under VirtualBox. (I have no real Windows shares to test with; just using \\VBOXSVR\... pseudomounts.) So for now at least I am unable to reproduce and hence unable to work on finding a fix - whether in NB or in Ant. Workaround is obvious - use a drive letter rather than UNC path. Maybe Jirka has some ideas about this. I tried to reproduce the issue on exactly the same configuration (JDK 1.6.0_10, Ant 1.7.1) on cmd line and in IDE and I got exactly the same result: cmd line: ... parsing buildfile \\MILANKUBECF003\Sdileno\JavaApplication2\build.xml with URI = file:////MILANKUBECF003/Sdileno/JavaApplication2/build.xml Project base dir set to: \\MILANKUBECF003\Sdileno\JavaApplication2 [antlib:org.apache.tools.ant] Could not load definitions from resource org/apache/tools/ant/antlib.xml. It could not be found. Importing file C:\MILANKUBECF003\Sdileno\JavaApplication2\nbproject\build-impl.xml from C:\MILANKUBECF003\Sdileno\JavaApplication2\build.xml BUILD FAILED C:\MILANKUBECF003\Sdileno\JavaApplication2\build.xml:7: Cannot find nbproject/build-impl.xml imported from C:\MILANKUBECF003\Sdileno\JavaApplication2\build.xml IDE: parsing buildfile \\MILANKUBECF003\Sdileno\JavaApplication2\build.xml with URI = file:////MILANKUBECF003/Sdileno/JavaApplication2/build.xml Project base dir set to: \\MILANKUBECF003\Sdileno\JavaApplication2 Importing file C:\MILANKUBECF003\Sdileno\JavaApplication2\nbproject\build-impl.xml from C:\MILANKUBECF003\Sdileno\JavaApplication2\build.xml C:\MILANKUBECF003\Sdileno\JavaApplication2\build.xml:7: Cannot find nbproject/build-impl.xml imported from C:\MILANKUBECF003\Sdileno\JavaApplication2\build.xml So I suppose we can close the issue as a problem in Ant tool itself. We could try to identify whether the problem is actually bug in Ant, JDK or XML parser. Looks like ant regression. I`ve tried both 1.7.0 and 1.7.1 - it works fine with 1.7.0 and throws an exception with 1.7.1 (in both cases I used it from command-line). To the end it also works fine with ant 1.6.5. Not likely to be a NB issue as such; it seems that the implementation of <import> obtains the base file path from a URI, which is potentially broken in the case of UNC paths (cf. Java bug #4723726). Could be affected by - version of Ant (1.7.0 vs. 1.7.1) - Java version (1.5 vs. 1.6) - Xerces version (2.8.0 bundled with NB, vs. whatever random version bundled with Ant, vs. fork bundled in JRE) Possibly related: https://issues.apache.org/bugzilla/show_bug.cgi?id=8031 https://issues.apache.org/bugzilla/show_bug.cgi?id=42275 Jesse, It is unlikely xerces issue - I`ve copied xerces libraries from ant 1.7.0 to 1.7.1 - it didn`t help. And it is not the issue of JDK since I`ve tried both ant versions with the same JDK. Indeed, org.apache.tools.ant.launch.Locator.fromURI("file:////mysystem/Project/build.xml") returns : \\mysystem\Project\build.xml with 1.6.5 \\\\mysystem\Project\build.xml with 1.7.0 C:\\\\mysystem\Project\build.xml with 1.7.1 those results are for JDK6, for JDK5 they are a little bit different: \\mysystem\Project\build.xml with 1.6.5 \\mysystem\Project\build.xml with 1.7.0 C:\\mysystem\Project\build.xml with 1.7.1 Presumed regression in Ant needs to be identified, filed, and fixed, possibly with a binary patch bundled with NB (though I am nervous about testing a patch in this very sensitive area of code). Seems it is already fixed in Ant 1.8; see URL. I do not want to risk shipping a patched version of Ant 1.7.1 as there are too many possible regressions. Workarounds include: - use Ant 1.7.0 for builds - use an alpha of Ant 1.8.0 for builds - use the project from a mapped drive letter rather than UNC path The creation of a bogus dest dir when running Javadoc is a separate issue in the JDK (that AFAIK we cannot work around): http://bugs.sun.com/view_bug.do?bug_id=4696488 > use Ant 1.7.0 for builds
Jesse, what exactly did 1.7.1 bring to us that we could not live without in 6.5?
I am considering going back to 1.7.0 until the UNC bug in Ant is fixed.
Would rather bundle a patch for Ant 1.7.1's Locator.java, as in the URL. Would need to be rather carefully tested since this is in a heavily used method. Also may be possible to work around in the build.xml by replacing <import file="nbproject/build-impl.xml"/> by <import file="${basedir}/nbproject/build-impl.xml"/> but this would permanently affect user scripts (and would only work for people who had never edited their build.xml). Note that even with a fix for this issue, there are likely to be various problems using a project on a UNC path - Javadoc builds will not work (as previously mentioned), you cannot even CD to the project from a command shell to run an offline build, etc. Using a mapped drive letter is much safer in general. Bundling a minimal Ant patch to fix the <import> problem: core-main #f72cedf5282c (Javadoc generation will still not work.) Jesse, thanks for preparing the fix. QA folks, please verify it fixes the problem and does not break anything else. Thanks! when the fix of this issue seems so risky shouldn't we rather go the safer way -> just add release note? How many users are using project on UNC path? This could be fixed in a patch if necessary. Tomas and Petr are testing Jesse's patch however I'm scared that we could miss something during the testing. I agree with Lukas. The fix doesn't cure all UNC project related issues anyway. Workaround is easy and straightforward. Either use mapped drive letter or modify <import file="${basedir}/nbproject/build-impl.xml"/> in build.xml. Just my 2Kc. The patch seems to be safe. It should not affect anything else but UNC paths. My opinion is to let the patch in the repository. i've tested for regression on linux, project actions (build, clean, c&b, run, debug,...) on various project types (j2se project, j2se library, java desktop app, freeform, module, module suite ...) and it seems wo work. Will try also on Win XP tomorrow. There would be no users of 6.1 using projects on UNC paths because it was impossible prior to the fix of issue #46813 (in 6.5 M1). But that fix would be pretty useless if you could not even build your project! (You could still keep your userdir on a UNC share.) There seem to be conflicting opinions on whether the patch should stay or go. For now I will leave it in. I believe it is safe, since it only looks to affect code involving UNC paths, which are known to be unusable otherwise. BTW I increased the priority of the javadoc destdir bug to P3; it looks trivial to fix, so maybe we would get a fix for it in some JDK 6 update. Integrated into 'main-golden', will be available in build *200810031107* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/f72cedf5282c User: Jesse Glick <jglick@netbeans.org> Log: #146948: failure to build project on UNC path. Patching Ant PR 42275: bug in URL resolution breaks <import> w/ relative path when basedir is UNC. did not catch any regression in projects actions neither on XP. Project build on UNC path works too (but filed #149069). Hopefully it is ok. Building project on UNC path works now, we did not catch any regression from patch. verified. If issue is fixed and verified, why should it be added to the release notes? The discussion about this issue is quite long and complex and it is not clear to me what the problem is because the issue is marked as fixed due to either a rollback of the Ant version or a patch for the ant script. If there is still an issue, can someone clarify what the problem is and how to use a workaround, please? The problem is fixed by patching Ant tool that is executed inside IDE. You don't need to do anything to use UNC paths now, just get the right build of IDE. Removing RELNOTE kw, since the issue is fixed. well, the problem (building project on UNC path) was solved by patching bundled Ant. And even with this patch, javadoc generation will not work. User can also choose to use non-bundled Ant (which does not contain patch). Therefor i suggest to add do release notes something like: "Build javadoc action will not work if you are using project on UNC path. If you decide to use custom (not the bundled one) Ant 1.7.1, building project on UNC path will not work at all." ..and also it may be worth to mention workarounds (use Ant 1.7.0, where everything mentioned should work well.) This looks like a good FAQ topic as users are more likely to find that info than the relnotes. It also is not so serious a problem to require a release note. Please see http://wiki.netbeans.org/ReleaseNoteGuidelines for details. There should probably be a FAQ page for people using UNC paths, as there are various things you need to be careful about. I created FAQ - http://wiki.netbeans.org/FaqUNCPaths, feel free to enhance it or fix it *** Bug 198563 has been marked as a duplicate of this bug. *** (In reply to comment #42) > *** Bug 198563 has been marked as a duplicate of this bug. *** Sorry, but bug 198563 may be running into a problem with UNC paths, but no UNC paths are being provided to it within the project. So I have reopened that as a bug to address why UNC paths are showing up when none are provided. See my comment in that bug. For future reference: (In reply to comment #43) > no UNC paths are being provided to it within the project Not true, see bug #198563 comment #14. |