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 131054 - shared libraries - project won't use absolute path
Summary: shared libraries - project won't use absolute path
Status: CLOSED FIXED
Alias: None
Product: javaee
Classification: Unclassified
Component: Web Project (show other bugs)
Version: 6.x
Hardware: All All
: P1 blocker (vote)
Assignee: David Konecny
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-03-25 15:20 UTC by Petr Hejl
Modified: 2008-04-08 17:20 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Petr Hejl 2008-03-25 15:20:48 UTC 
From jersinghaus@nmda.nmsu.edu:

"On a linux box, I'm trying to setup my existing web project to use an
absolute path so cruisecontrol can use the netbeans build scripts on a
separate continuous integration server and pull required libraries from
a shared network source.

But it appears only relative paths are used in project.properties
regardless of selecting an absolute path when converting the project.

Testing this with a new web project and selecting shared library and
absolute path creates a project still setup for relative path only.

Also can't seem to go back in and under properties->libraries change to
absolute path either."

I will ask for more details and/or project configuration.
Comment 2 Petr Hejl 2008-03-25 15:53:10 UTC 
Additional info requested from user.
Comment 3 David Konecny 2008-03-25 22:49:31 UTC 
I can reproduce that too. Looks to me like some heuristic jumps in and decide to relativize reference.
Comment 4 Petr Hejl 2008-03-26 17:44:50 UTC 
Only way I could simulate it was direct context menu usage. From Properties->Libraries everything worked ok.

It was probably caused by not passing the operation value replacing it with constant (see diff).
David, can you verify?

Changeset 67096b484868.
Comment 5 David Konecny 2008-03-27 11:19:30 UTC 
Yeah, looks good to me now. Thanks Petr.
Comment 6 jersinghaus 2008-03-31 18:24:20 UTC 
Gentlemen,

I've downloaded build 200803302302 and still have this issue. This is how I reproduce the problem:

1. Create a new web application.
2. In Step 2. of the "New Web Application" wizard, select "Use Dedicated Folder for Storing Libraries" check box.
3. Select "Browse" and in "Select Libraries Folder" dialog, browse to a shared network folder (in my case, an NFS share)
and select "Use Absolute Path" radio button.
4. In step 4. of "New Web Application" wizard, select JavaServer Faces and Finish.

Project is created and indeed library files have been copied to my network share folder.

But, open project.properties file and I see that the libs classpath is using "../../../../../media/my/share/path..."
relative path instead of the absolute path I selected in 3. from above.

If I select Properties->Libraries and "Browse", I can select the "Use Absolute Path" radio button, but this will break
the project as I get missing library errors once the Browse dialog has closed.

I'm running Kubuntu 7.10, jvm 1.6u3.

Email me if you'd like me to send project files or have any other questions.

Thanks,
Joe
Comment 7 Petr Hejl 2008-03-31 20:13:13 UTC 
Looks like libraries imported from global ones are always relative.
Comment 8 David Konecny 2008-04-01 03:24:25 UTC 
Joe, thanks for catching this one and reporting it.

I fixed it in trunk: http://hg.netbeans.org/main?cmd=changeset;node=d0ade33ca2cb

The fix is relatively simple and its core is in resolving library entry URI against libraries location instead of using
relative path from project folder to library jar. The rest of the diff adds AntProjectHelper to changed method signature.

The problem is in all web/j2ee project types because of their special handling of library jar files (see e.g. bottom of
issue 129316 for more details). J2SE project is using proprietary copylibs task instead and therefore does not suffer
from this problem.

The problem is becoming P1 issue if you decide to create project on Windows on drive C: and put libraries on drive D:.
In such a case the path will have value of "null" and project build fails. I'm leaving priority decision on QA.
Comment 9 Petr Blaha 2008-04-03 09:02:36 UTC 
Increasing priority to P1. The issue is fixed in trunk. Dan Kolar, please verify the bug in the latest trunk build today.
Comment 10 Dan Kolar 2008-04-03 16:30:51 UTC 
I can't reproduce this either in (Build 200803311426) nor in (Build 20080403091634), which should already contain the fix.
David, can you describe some exact steps, which should give different results for fixed and unfixed build, please?
Comment 11 David Konecny 2008-04-03 22:52:52 UTC 
Create web project with visual JSF on C: drive and in wizard on first panel tick Libraries Folder and set path on
different drive, eg. D:. Clean/build of such a project fails with:

 Warning: Could not find file C:\Users\david\Documents\NetBeansProjects\WebApplication8\null to copy.
 BUILD FAILED (total time: 0 seconds)

and in project.properties you should see 

 libs.jsf12-support.classpath.libfile.1=null
 libs.jsf12-support.classpath.libfile.2=null
 ...
Comment 12 Dan Kolar 2008-04-04 13:00:26 UTC 
Ok, verified finally. The key word was "visual", I used only JSF before and this worked ;-)
Comment 13 David Konecny 2008-04-07 04:20:45 UTC 
Fixed in 6.1 as:
http://hg.netbeans.org/release61?cmd=changeset;node=6945c3612a08
Comment 14 Martin Schovanek 2008-04-07 14:08:55 UTC 
Reverting to Resolved > Fixed. Please mark it as verified after verification in release61.
Comment 15 Martin Schovanek 2008-04-07 14:13:58 UTC 
rf.
Comment 16 Dan Kolar 2008-04-08 15:36:56 UTC 
v. in release61