Details
-
Bug
-
Status: Open
-
Major
-
Resolution: Unresolved
-
8.2
-
None
-
None
-
Windows 10 with JDK8 (64bit)
Description
I have found a reliable way to completely lose a Library defined as a project/shared library (does not affect global libraries). Steps to reproduce:
- Have a project open which defines a Library location
- Go to Tools->Libraries
- Choose that project's Library location in the drop-down at the top of the dialog
- Create a New Library with the name: test
- Add some JAR/Folders as you see fit
- Hit OK
- Repeat steps 2 & 3
- Click the test library, verify Classpath contents
- Change the Library Name to: modified
- Hit OK
- Repeat steps 2 & 3
- Click the modified library, verify Classpath contents
- Create a New Library with the name: test
- Hit OK
- Repeat steps 2 & 3
- Notice that modified is gone
This all happens because the internal identifier given to the library in the properties file is its initial Libray Name. When the Libray Name is modified, the internal identifier stays the same. When creating a new library an "already exists" check only compares against the Library Name, not the identifier used in the property keys.
Either the "exists" check needs to compare with the identifier, or the identifier itself should be updated along with the name. The latter would make more sense, so that you could re-use a name that was once used but no longer is – e.g. "MyLib - Latest" after renaming the old Latest one to "MyLib - Previous". This also would eliminate the need to have a displayName key as it would never differ from the identifier.
Or I guess a totally random identifier could be used (UUID style), but that isn't something that seems to be commonly done in Netbeans.
I have only run across this using Netbeans 8.2, haven't tried it in newer versions.
Attachments
Attachments
Issue Links
- is duplicated by
-
NETBEANS-4808 Shared project libraries can get clobbered after being renamed
- Closed