|
Re: Eclipse's refactoring does not cover aspectj files [message #37121 is a reply to message #36856] |
Wed, 02 June 2004 12:50 |
Eclipse User |
|
|
|
Originally posted by: clemas.uk.ibm.com
You are right that we should be updating references to modified types in
aspects too. The fact that aspects are not first class citizens in
Eclipse is the cause of many of our problems throughout AJDT. We are
working on it ...
Andy.
Michael Moser wrote:
> When refactoring in eclipse (e.g. I just moved one class to a
> different package) the AspectJ-files seem to be left out of this
> operation, i.e. imports or identifiers in such classes are not
> adjusted accordingly. I only noticed this, when things were suddenly
> not working as expected and after some search I finally realized that
> the Aspect(-file) was still listing the old classname.
>
> Strange enough in my case - even though the moved class was explicitly
> listed in one pointcut - this yielded no compile errors but only the
> VERY strange and confusing effect, that the moved class was not
> properly advised any more (well it may even have been properly
> advised, but it was not called any more by the refactored code...).
>
> I can only explain that by the fact, that I had not done a "proejct
> clean" after the move, so the old class file was probably still lying
> around thus preventing compile errors. I can tell you: such
> coincidences can be VERY surprising and confusing!
>
> I would say, that when one refactors a class and an aspect contains
> some explicit reference(s) to some class(s) or method(s) then the
> "normal expectation" would be that such names are refactored as well.
> Can that be changed such that aspects become part of the refactored
> working-set?
>
> Michael
>
>
|
|
|
|
Powered by
FUDForum. Page generated in 0.01780 seconds