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 96145 - name conflict with addition of several classes/interfaces to a package
Summary: name conflict with addition of several classes/interfaces to a package
Status: VERIFIED FIXED
Alias: None
Product: uml
Classification: Unclassified
Component: General Diagram (show other bugs)
Version: 5.x
Hardware: All All
: P2 blocker (vote)
Assignee: Yang Su
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-02-21 12:44 UTC by Sergey Petrov
Modified: 2007-05-11 15:08 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sergey Petrov 2007-02-21 12:44:47 UTC
reproducible with 070221_1

steps:
1. create class diagram
2. add package to the diagram
3. put class within the package on the diagram
4. select interface in Palette
5. click on the class
6. click in empty area of the package
interface with default name is created
7. repeat steps 5,6
name conflict dialog appears and unnamed inteface is created in root package
Comment 1 Peter Lam 2007-03-20 23:12:24 UTC
low use case not currently impacting our installed user base.
Comment 2 Alexandr Scherbatiy 2007-04-04 13:33:46 UTC
The issue affects Advanced UML Modeling with NetBeans HOL.
I need to put two Use Case elements on the package.
The information dialog taht says 'An element with this name already exists
in the current namespace' appears.
Comment 3 Yang Su 2007-04-09 20:43:32 UTC
Historically, the newly created NamedElement is given a name "Unnamed", which is
also an editable option in Options -> UML -> New Project -> Default Element
Name. There is no other attribute to tell the unnamed from named. The obvious
fallacy is that when default name is modified all previously unnamed become
regular named elements, which causes error in logic where unnamed should be
singled out, like code generation.

The safest approach to address this issue is to ignore unnamed element naming
conflict check and make this option hidden (remove from option list) so users
won't be able to modify it, the distinct name can then be used to mark the
unnamed status. This option was really unnecessary, it did not offer any
benefits. A useful model should be clear and unambiguous, default name only
provides convenience for initial creation and is expected to be changed later. I
don't see such an option in other applications.

Made changes in config file to remove it from option list, and add logic to skip
validation if element is unnamed.
Comment 4 Andrew Korostelev 2007-04-10 13:53:01 UTC
verified in all-nbms-hydra-070409_14
should be also ported to 5.5 patch
Comment 5 Andrew Korostelev 2007-04-17 14:56:19 UTC
verified in all-nbms-griffin_fixes-070416_1-ml