Nov 11th, 2010, 07:26 AM
Push in refactor in STS 3.5.0 -> "No crosscutting model"
Whoops! I meant STS 2.5.0 of course!
I select my Spring Roo project and go to refactor. There is no "push in" to select. If I go to my main package, I can select "push in", but then the cursor changes to a ball and nothing at all happens. I wait a while and move the mouse and cursor changes to an arrow and it's like my command never was given.
If I then restart the STS and open it and chooses "push in", again at the package level, I get a dialog that says: "Rebuild Project. No crosscutting model available".
So I rebuild with mvn clean install. The build is successful including basic tests. I select "push in" again. Same dialog.
This problem may be related to my other problem: STS 2.5.0RELEASE failure of "enable spring aspects tooling".
If it is then the problem must be that I can't get the spring aspects tooling to work fully.
This sure feels like a bug or several in STS 2.5.0 or if it has something to with the version of the AJDT plugin. Anyone else have similar experiences?
Anyone have some advice how to analyze this problem with STS or its plugins?
STS 2.5.0 on JDK1.5.0_20 on Mac OS X 10.5.8 PPC
Last edited by MiB; Nov 15th, 2010 at 02:06 AM.
Nov 11th, 2010, 07:49 AM
I have checked the plugin folder of STS to see if there are any .gz-files and there weren't. I'm going to reinstall to see if that helps, then go back to the version before 2.5.0 to see it that works better.
It would be helpful if anyone else using 2.5.0 on jdk1.5 on Mac could tell about their experiences.
Last edited by MiB; Mar 3rd, 2011 at 10:58 AM.
Nov 11th, 2010, 10:50 AM
As mentioned in your previous post, you first need a successful build inside Eclipse before the crosscutting model is created correctly. However, this must be a build executed from within Eclipse. Try doing a Project -> Clean... on the Roo project. Doing a Maven->Clean does not invoke the AJDT builder (but rather ajc is invoked from maven) and so the crosscutting model is not created (it should be faster also).
Nov 15th, 2010, 02:05 AM
This distinction between native STS build and maven build was actually something I had missed, so that paired with the fact that private members of the .aj file isn't available directly from the advised java file gave me the proper approach.
All your answers gave very useful information. A big thank you, Andrew!
Nov 15th, 2010, 10:05 AM
No problem. Glad to see the issue resolved.
Mar 2nd, 2011, 09:41 AM
I wished the project>clean would had help me... but not.
I know for sure that the command is working. But right clinking on Roo project refactor submenu, only shows rename and move after cleaned. No push-in at all.
I tried on latest fresh installation of 2.5 and 2.6. What else can I do at this point.
Thank you in advance
Mar 2nd, 2011, 10:51 AM
I can't imagine why you would not be seeing the Push in... option unless there is something wrong with your STS installation.
Have a look in your error log to see if there are any relevant exceptions and please paste them here.
Mar 2nd, 2011, 01:11 PM
I agree with you it was really weird and time consuming...
In one of my many tries: I deactivate and active the JDT Weaving and suddenly started to work.
I am sure I did that before since I installed multiple versions of sts and eclipse.
Anyway is working Good grief!
Second quick question you might help me. I am trying to use the new caching feature coming with Spring 3.1 with Roo generated entities. I am getting an exception that cache is not supported with aspect proxies. I assume that by pushing my entities and removing the aspects cache would started to work. But not. I wonder if you know anything about it.
Thank you for replying this promptly
Last edited by delgad9; Mar 2nd, 2011 at 01:18 PM.
Mar 3rd, 2011, 10:50 AM
I'd recommend that you ask your follow up question on the Roo forum. They'd be better able to help you.
Mar 3rd, 2011, 11:58 AM
private members in Java and AspectJ
Andrew, could you please clarify to what length my assumption above that private members in the itd-files being private also to the java source file that those very itd-files belong to is true?
After all, post-compilations all members from the Java source file and its corresponding AspectJ files end up in one java class file and all members there must be assumed to be reachable within this class, just as with regular java-files, no?
But while this is true this is not reflected within the crosscutting model? Is this because this model models the relationships between the Java and AspectJ constructs rather than reflecting the compiled java classes?
I suppose I'd know this if I had learned more about AspectJ. But I don't, thus my need to ask.
Tags for this Thread