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 93749 - backing bean doesn't remove all references when disassociating a complib completly from a project
Summary: backing bean doesn't remove all references when disassociating a complib comp...
Status: NEW
Alias: None
Product: obsolete
Classification: Unclassified
Component: visualweb (show other bugs)
Version: 5.x
Hardware: All Windows XP
: P3 blocker (vote)
Assignee: _ edwingo
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-01-31 23:40 UTC by bugbridge
Modified: 2007-01-31 23:40 UTC (History)
1 user (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description bugbridge 2007-01-31 23:40:12 UTC
Original status: 5-Cause Known; Suggested Status: NEW

Original Target Release: shortfin_dev; Suggested Target Milestone : 5.5


Original submitter: sjangity

Description:
Build 925-TP/ML, 918 NB, WinXP
1.5 Project/JDK 1.5.06

1. New userdir

2. Start IDE and w/ new project import ajax complib found here (0.1.1):
http://wiki.java.net/bin/view/Javatools/AllAboutComplibs

3. Drop the AutoComplete Text Component
> project now has a copy of the complib

4. delete the component from designer, so project is not actually using any of
the imported comp's

5. now follow the instructions to delete/deassociate the complib found on this link:
http://wiki.java.net/bin/view/Javatools/AllAboutComplibs#Removing_a_Complib_From_a_Projec

6. when you restart the IDE and load the project, the Source File Error page
surfaces

> turns out the following import stmt is still there in the backing bean
import com.sun.j2ee.blueprints.ui.autocomplete.AutoCompleteComponent;

Evaluation:
Removing a component from the designer does not remove all of its code. "import"
statements still remain.

Evaluation (Entry 2):
Insync has know direct way of knowing which import statements were correct but
simply became incorrect because the user decided to remove the complib. May be
the complib removal action knows that and thus it should tell Insync which
imports should be removes. We could add a service for that. In any case this was
never designed to be supported. This is probably an RFE.

Evaluation (Entry 3):
Has a workaround so making it a P3. Adding a component will add the classes to
the java code, but removing a component only partially removes it because import
statements are still left. It seems like something that the core IDE should be
able to keep track of. I'll assign to insync for more eval. In any case, I don't
think this is a major problem.

Evaluation (Entry 4):
Insync does not do such clean up when the user removes the library. In fact this
kind of error will happen with a normal java project also.

Evaluation (Entry 5):
The problem is that the import statement is not being removed. The workaround is
to remove it manually. You can also use "fix imports". I think this really is a
problem for insync to solve, but I'm afraid of assigning it there. I'll change
this to an RFE because I think there are more serous problems to solve.

Evaluation (Entry 6):
This is more of a refactoring type of RFE. The use case is to remove a component
library and also any components and application related references to that
component. This is a difficult task. See workaround for more info.

Workaround:
Before removing a component library from a project, the user must first remove
all references to classes within the component library. This can include
selecting components from the Navigator and deleting them but typically also
means removing references to those components from the user's application. One
can also run "fix imports". After that, the component library can be removed
from the project.