Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Language IDEs » AspectJ » Eclipse's refactoring does not cover aspectj files
Eclipse's refactoring does not cover aspectj files [message #36856] Thu, 27 May 2004 18:10 Go to next message
Michael Moser is currently offline Michael MoserFriend
Messages: 914
Registered: July 2009
Senior Member
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
Re: Eclipse's refactoring does not cover aspectj files [message #37121 is a reply to message #36856] Wed, 02 June 2004 12:50 Go to previous message
Eclipse UserFriend
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
>
>
Re: Eclipse's refactoring does not cover aspectj files [message #580523 is a reply to message #36856] Wed, 02 June 2004 12:50 Go to previous message
Andrew Clement is currently offline Andrew ClementFriend
Messages: 162
Registered: July 2009
Senior Member
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
>
>
Previous Topic:moved workspace problem
Next Topic:intertype declarations and declare-parents declarations not shown
Goto Forum:
  


Current Time: Tue Mar 19 02:44:39 GMT 2024

Powered by FUDForum. Page generated in 0.01780 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top