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.
1. Go to Tools -> Library Manager 2. Click on Absolute Layout library 3. The file name in the Classpath tab is jar:nbinst:///modules/AbsoluteLayout.jar!/ which is user unfriendly and cryptic. Should be a real file name. Same for libraries created by the user.
File != URL. URL encodes more than Files. How would you encode nbres: or nbloc: or in future http: using File?
Well, I think that the report is valid name like this: jar:nbinst:///modules/AbsoluteLayout.jar!/ is really scary. We should show something better to user, nbinst is translated to something isn't it? Or we can show <nb install dir>/ide5/modules/AbsoluteLayout.jar. User doesn't need to have 'jar:' in the beginning and so on.
As I already explained, there is no mapping URL->File (eg. Http for javadoc, which I hope will be reintroduced). Next case is a jar file with relative offset. You can translate nbinst to something ugly byt what to do with nbres? EJB defines new URLMapper for app server, who will create the "nice" name for it? In general library may contain any URL are you going to extend the openide URLMapper to add some method getNiceURLName() ? Probably not.
Hey, let's not talk about whether this can be easily implemented or not, but whether this is a problem for the user or not. If it's a problem for the user, then this issue can't be INVALID.
This is not about implementation but also about user interface. Having something like file or URL in case it is more complex (taken from off line discussion) is probably even worse interface. It seems that this will not lead to any solution, I am reopening the issue and assigning it to UI to evaluate this. This is probably the best solution for now.
Jano, can you evaluate it?
I think the desired behavior is clear. In fact, I had thought that the libraries display code already did this, but perhaps it got broken at some point and no one noticed. The URL should be mapped to a FileObject if possible, using URLMapper. If it is possible, which should always be the case for a URL corresponding to something on disk (i.e. not HTTP), the entry should be displayed using FileUtil.getFileDisplayName. Otherwise, the URL may be displayed as is. It should be the case that e.g. jar:nbinst:///modules/ext/AbsoluteLayout.jar!/ is then displayed as e.g. "/opt/nb41/ide5/modules/ext/AbsoluteLayout.jar". The same should apply to the Java Platform Manager, of course.
It seems that J2SEPlatformCustomizer.PathModel.getElementAt already displays something reasonable for many cases (my patch, rev 1.7). But it could surely be simplified and improved, using URLMapper + FileUtil.getFileDisplayName, to match what should be done in J2SEVolumeCustomizer.ContentRenderer. Note that J2SEVC.CR seems to have a bug in its current impl, too: displayName = url.toExternalForm(); if ("jar".equals(url.getProtocol())) { url = FileUtil.getArchiveFile (url); } What does changing the url local var accomplish? Nothing, as far as I can see. The displayName is already set and url is not used again in this method.
Obviously not for 4.1.
Checking in j2seplatform/src/org/netbeans/modules/java/j2seplatform/libraries/J2SEVolumeCustomizer.java; /cvs/java/j2seplatform/src/org/netbeans/modules/java/j2seplatform/libraries/J2SEVolumeCustomizer.java,v <-- J2SEVolumeCustomizer.java new revision: 1.23; previous revision: 1.22 done