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.

Bug 146948

Summary: Unable to build project on UNC path
Product: projects Reporter: Tomas Danek <musilt2>
Component: AntAssignee: 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
Product Version: NetBeans IDE Dev (Build 200809101401)
Java: 1.6.0; Java HotSpot(TM) Client VM 1.6.0-b105
System: Windows XP version 5.1 running on x86; Cp1250; cs_CZ (nb)
Userdir: C:\Documents and Settings\uadmin\.netbeans\dev
-------------
- created project on UNC path (\\tm-ws\sharedLoc in my case)
- run project -> works, but only because of default CoS
- try to clean and build project -> build fails with 

-----SNIP-----
parsing buildfile \\tm-ws\SharedLoc\JavaApplication8\build.xml with URI =
file:////tm-ws/SharedLoc/JavaApplication8/build.xml
Project base dir set to: \\tm-ws\SharedLoc\JavaApplication8
Importing file D:\tm-ws\SharedLoc\JavaApplication8\nbproject\build-impl.xml from
D:\tm-ws\SharedLoc\JavaApplication8\build.xml
D:\tm-ws\SharedLoc\JavaApplication8\build.xml:7: Cannot find nbproject/build-impl.xml imported from
D:\tm-ws\SharedLoc\JavaApplication8\build.xml
        at org.apache.tools.ant.taskdefs.ImportTask.execute(ImportTask.java:134)
-----SNIP-----

(verbose output)
Comment 1 Jesse Glick 2008-09-11 15:47:16 UTC
Maybe an Ant problem. Can you build from the command line?
Comment 2 Tomas Danek 2008-09-11 15:53:15 UTC
well, AFAIK windows commandline does not support UNC path. But tried in Cygwin:

cd \\\\tm-ws\\sharedLoc\\JavaApplication8
ant jar

Builds the app OK.
Comment 3 Milan Kubec 2008-09-12 09:52:28 UTC
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)
Comment 4 Tomas Danek 2008-09-12 10:43:22 UTC
well, i did not use UI, i just typed "\\tm-ws\sharedLoc" in project location.
Comment 5 Milan Kubec 2008-09-12 11:26:04 UTC
If I do that I get "Project Folder is not a valid path" message and disabled Finish button. I will try Windows XP.
Comment 6 Milan Kubec 2008-09-16 12:43:28 UTC
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?
Comment 7 dlipin 2008-09-16 14:17:11 UTC
BTW, if I type the command from the terminal - it works fine.
Comment 8 dlipin 2008-09-16 14:18:22 UTC
Created attachment 69948 [details]
Output of ant -v -f "\\computer\share\ShowMessage\build.xml"
Comment 9 dlipin 2008-09-16 14:25:39 UTC
... but it created folder C:\sard.russia.sun.com\.... which is certainly wrong.:()
Comment 10 dlipin 2008-09-16 14:35:57 UTC
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.
Comment 11 Jesse Glick 2008-09-16 14:41:23 UTC
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.
Comment 12 Milan Kubec 2008-09-16 14:48:31 UTC
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.
Comment 13 Jesse Glick 2008-09-17 17:50:35 UTC
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.
Comment 14 Milan Kubec 2008-09-18 09:35:16 UTC
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.

Comment 15 dlipin 2008-09-18 12:04:58 UTC
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.
Comment 16 Jesse Glick 2008-09-18 12:38:17 UTC
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)
Comment 18 dlipin 2008-09-18 12:53:09 UTC
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.
Comment 19 dlipin 2008-09-18 13:30:03 UTC
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
Comment 20 dlipin 2008-09-18 13:35:10 UTC
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
Comment 21 Jesse Glick 2008-09-22 23:32:04 UTC
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).
Comment 22 Jesse Glick 2008-09-30 19:05:59 UTC
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
Comment 23 Jesse Glick 2008-09-30 19:24:32 UTC
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
Comment 24 Antonin Nebuzelsky 2008-10-01 09:17:49 UTC
> 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.
Comment 25 Jesse Glick 2008-10-01 17:08:23 UTC
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.
Comment 26 Jesse Glick 2008-10-01 17:43:52 UTC
Bundling a minimal Ant patch to fix the <import> problem: core-main #f72cedf5282c

(Javadoc generation will still not work.)
Comment 27 Antonin Nebuzelsky 2008-10-01 21:06:30 UTC
Jesse, thanks for preparing the fix.

QA folks, please verify it fixes the problem and does not break anything else. Thanks!
Comment 28 Lukas Hasik 2008-10-02 12:30:29 UTC
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. 
Comment 29 Milan Kubec 2008-10-02 12:43:14 UTC
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.
Comment 30 Jiri Skrivanek 2008-10-02 14:40:26 UTC
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.
Comment 31 Tomas Danek 2008-10-02 15:43:32 UTC
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.
Comment 32 Jesse Glick 2008-10-02 19:07:02 UTC
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.
Comment 33 Quality Engineering 2008-10-03 14:33:26 UTC
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.
Comment 34 Tomas Danek 2008-10-03 16:32:03 UTC
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.
Comment 35 Tomas Danek 2008-10-06 18:08:57 UTC
Building project on UNC path works now, we did not catch any regression from patch. verified.
Comment 36 Bradley Schmidt 2008-10-15 12:44:16 UTC
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?
Comment 37 Milan Kubec 2008-10-15 12:53:03 UTC
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.
Comment 38 Tomas Danek 2008-10-15 13:30:04 UTC
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.)
Comment 39 Bradley Schmidt 2008-10-27 16:36:44 UTC
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.
Comment 40 Jesse Glick 2008-11-07 03:18:36 UTC
There should probably be a FAQ page for people using UNC paths, as there are various things you need to be careful about.
Comment 41 Lukas Hasik 2008-11-07 08:23:53 UTC
I created FAQ - http://wiki.netbeans.org/FaqUNCPaths, feel free to enhance it or fix it
Comment 42 Jesse Glick 2012-02-17 15:50:10 UTC
*** Bug 198563 has been marked as a duplicate of this bug. ***
Comment 43 lvskiprof 2012-02-17 17:37:52 UTC
(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.
Comment 44 Jesse Glick 2012-02-20 21:29:15 UTC
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.