Bugzilla – Full Text Bug Listing
| Summary: | [refactoring] Moving classes to diff pkg breaks JSPs w/ * imports | ||
|---|---|---|---|
| Product: | [WebTools] WTP Source Editing | Reporter: | Mark Sederqvist <ms> |
| Component: | jst.jsp | Assignee: | Ian Tewksbury <itewksbu> |
| Status: | CLOSED DUPLICATE | QA Contact: | Nitin Dahyabhai <thatnitind> |
| Severity: | normal | ||
| Priority: | P2 | CC: | itewksbu, nsand.dev |
| Version: | 1.0 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 2000 | ||
| Whiteboard: | |||
|
Description
Mark Sederqvist
Phil, do we get "refactoring events" for these? This should be working. We definitely get refactoring events for this (if invoked from the refactoring wizard or dnd from package explorer). May be related to occurrences in file not working either. Raising priority since it's important to have this working for 0.7. This works for me when I test it so that brings up a couple questions: - what type of project are you in (java, web, simple...)? - how did you invoke the "move"? (dnd, refactoring dialog...) - how did you create the project (import, from scratch...) It also might be possible that the JSP core plugin wasn't started when you imported your files... which would cause the JSPs to not be indexed, so they would be ignored by refactoring/search operations. Sorry for the lack of specifics. I am running integration build I20050527-1300. Also, the problem only occurs when the JSP import directive does not explicitly mention the class, but instead imports a whole package using '*' wildcard. Moving a class to a new package fails to update the import directive. It works when the import directive specifies the class name. The error is recreated quite easily by creating a new J2EE web project, writing a class, writing a JSP that imports the class' package (using page import directive with wildcard, like <%@ page import="mypackage.*" %>) and then moving the class to another package using the 'refactor' menu. Ah that makes sense then. Thanks for the details. We're not handling this case. The way refactoring currently works is we do a search for the Java element that moved, then update the package if it's fully qualified (in an import or in the file). We currenly don't keep track of if the import "*" is linked to the refactored Java element. There would have to be some logic added... Here are the scenarios that I can think of for handling "*" imports during refactoring: - if there's 1 class from the imported package in the JSP, we would just update that import - if there's 2 classes from the same package in the JSP, we would have to add an aditional import, and leave the original - if the import came from an included file, that might make it more complicated We would need to use not expensive way to find the import associated with the moved Java element when it's not fully qualified in the file, and we would need to know if the import "*" covers other classes in the JSP. Maybe we should just start by adding another import statement (if it doesn't exist already) which would usually be the case if someone uses import "*" (they want to cover more than one class). I don't think we'll be able to cover this for 0.7, but I at least wanted to write some ideas down. modifying abstract. Just adding another import statement would be a good enough fix for us for the time being. The fact that refactoring breaks JSPs is a far worse issue than a few overlapping import statements. Moving to M8 in light of other bugs. Part of a mass update. Based on 9/22/2005 development review meeting, it's determined this was an open bug/enhancement with tartget mistakenly set to M8. Since this will not be in M8, I am changing to "unspecified". If this is an error, please correct (for example the bug really has been fixed in M8, change back to M8, and "fixed".) this would be less important if the content-assist would do the imports for you. since it doesn't, the JSP developer has to manually type the imports. due to this huge flaw, the developer is more likely to use the * during import, and then get burned again during refactoring. Raising priortiy to see if we can address this or the content assist bug (auto import) by M10. Nitin, will you evaluate and make a recommendation for 1.5 stream? This scenario has been fixed by Bug 164263. This scenario has mostly been fixed by Bug 164263 but duping against Bug 298355 because the scenario there has to do with moving and until its fixed I can't claim that the moving scenarios all work. *** This bug has been marked as a duplicate of bug 298355 *** |