[
https://issues.apache.org/jira/browse/NETBEANS-4808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Johle updated NETBEANS-4808:
----------------------------------
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 identifiers, or the old
identifier itself should be updated along with the name. The latter would let
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". But since there are other
things (e.g. project.properties) referencing this identifier that would
probably not work.
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.
was:
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.
> Shared project libraries can get clobbered after being renamed
> --------------------------------------------------------------
>
> Key: NETBEANS-4808
> URL: https://issues.apache.org/jira/browse/NETBEANS-4808
> Project: NetBeans
> Issue Type: Bug
> Components: projects - Libraries
> Affects Versions: 8.2
> Environment: Windows 10 with JDK8 (64bit)
> Reporter: David Johle
> Priority: Major
> Labels: features
>
> 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 identifiers, or the old
> identifier itself should be updated along with the name. The latter would
> let 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". But since there
> are other things (e.g. project.properties) referencing this identifier that
> would probably not work.
> 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.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
