Uploaded image for project: 'Spring Tool Suite'
  1. Spring Tool Suite
  2. STS-2068

push-in of Roo-generated converter methods in ApplicationConversionServiceFactoryBean doesn't move method to java source

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Complete
    • Affects Version/s: 2.7.1.RELEASE, 2.8.0.M1
    • Fix Version/s: 2.8.0.M2
    • Component/s: EDITING, ROO
    • Labels:
    • Environment:
      Mac OS X 10.5.8, jdk 1.5 (build 1.5.0_30), Roo 1.2.0.BUILD-SNAPSHOT [rev 6002fca]

      Description

      When I push in a converter method from the Roogenerated ApplicationConversionServiceFactoryBean_Roo_ConversionService.aj with "Refactor -> Push-in" command the methods are not moved to the Java source file. My expectations were they were going to be moved, just like when I push-in other methods.

      I'm not sure this is so by design or from a mistake.

        Activity

        Hide
        aeisenberg Andrew Eisenberg added a comment -

        Can you attach the aspect as well as the target java classes that are causing the problem?

        Show
        aeisenberg Andrew Eisenberg added a comment - Can you attach the aspect as well as the target java classes that are causing the problem?
        Hide
        aeisenberg Andrew Eisenberg added a comment -

        Thanks. This should be sufficient.

        Show
        aeisenberg Andrew Eisenberg added a comment - Thanks. This should be sufficient.
        Hide
        aeisenberg Andrew Eisenberg added a comment -

        Unfortunately, I was not able to reproduce with only the provided files. Can you send me the full project by email: [email protected]?

        Also, let me know if the source code must remain private and I will make sure that it will not be shared.

        Show
        aeisenberg Andrew Eisenberg added a comment - Unfortunately, I was not able to reproduce with only the provided files. Can you send me the full project by email: [email protected]? Also, let me know if the source code must remain private and I will make sure that it will not be shared.
        Hide
        aeisenberg Andrew Eisenberg added a comment -

        Thanks for your project. I was able to reproduce your problem at first, but that was due to an unresolved maven problem. I have upgraded to m2e 1.0 in my workspace and the pom.xml was initially causing some errors.

        The result was that maven was able to compile the project, but it could not be compiled inside of Eclipse. This further meant that even though class files were generated, there was no crosscutting model.

        Because of this odd state, AJDT thought that everything was ok, but the crosscutting model was empty. So, it allowed you to do a push-in even though it didn't know where to push them in to (and so they were simply deleted).

        Could this be the behavior that you see? Does your pom.xml have any error markers on it? Do you see AJ gutter markers in your AJ files?

        If this is the case, then perhaps the solution is to be more explicit and warn users when this kind of error occurs.

        Show
        aeisenberg Andrew Eisenberg added a comment - Thanks for your project. I was able to reproduce your problem at first, but that was due to an unresolved maven problem. I have upgraded to m2e 1.0 in my workspace and the pom.xml was initially causing some errors. The result was that maven was able to compile the project, but it could not be compiled inside of Eclipse. This further meant that even though class files were generated, there was no crosscutting model. Because of this odd state, AJDT thought that everything was ok, but the crosscutting model was empty. So, it allowed you to do a push-in even though it didn't know where to push them in to (and so they were simply deleted). Could this be the behavior that you see? Does your pom.xml have any error markers on it? Do you see AJ gutter markers in your AJ files? If this is the case, then perhaps the solution is to be more explicit and warn users when this kind of error occurs.
        Hide
        mib MiB added a comment - - edited

        No error markers in POM. I see gutter markers to the left in my .aj files that says on mouseover say "annotates XX".

        There are other smaller problems, significantly roo-made overrides annotation for interfaces that gives errors under jdk5. The rest are just warnings. Main reason to move these to the java source. In later Roo builds the overrides are gone though.

        Show
        mib MiB added a comment - - edited No error markers in POM. I see gutter markers to the left in my .aj files that says on mouseover say "annotates XX". There are other smaller problems, significantly roo-made overrides annotation for interfaces that gives errors under jdk5. The rest are just warnings. Main reason to move these to the java source. In later Roo builds the overrides are gone though.
        Hide
        aeisenberg Andrew Eisenberg added a comment -

        Hmm....it is possible that these compile errors are preventing the code from compiling in Eclipse and hence push in is not working.

        I'll see if I can get this behavior happening for me.

        Show
        aeisenberg Andrew Eisenberg added a comment - Hmm....it is possible that these compile errors are preventing the code from compiling in Eclipse and hence push in is not working. I'll see if I can get this behavior happening for me.
        Hide
        aeisenberg Andrew Eisenberg added a comment -

        In general, there will need to be a clean compile in order to get the correct crosscutting model generated (although if the errors have nothing to do with the area you are pushing in, this requirement may not be necessary).

        Are there gutter markers over the ITD that you are unsuccessfully trying to push in? And is there an associated gutter marker in the target? Also, the markers should say something like "Declared on..." and "Aspect declaration...". If they are missing, that implies a broken crosscutting model.

        Show
        aeisenberg Andrew Eisenberg added a comment - In general, there will need to be a clean compile in order to get the correct crosscutting model generated (although if the errors have nothing to do with the area you are pushing in, this requirement may not be necessary). Are there gutter markers over the ITD that you are unsuccessfully trying to push in? And is there an associated gutter marker in the target? Also, the markers should say something like "Declared on..." and "Aspect declaration...". If they are missing, that implies a broken crosscutting model.
        Hide
        mib MiB added a comment - - edited

        No, there are no such markers I see now, also after a clean rebuild. What I saw before was probably left from an earlier build. There were no warnings about a broken crosscutting model.

        I also did clean restart of STS and then autobuilt again. Still no markers. So I did another clean rebuild and now I think there are markers. Is there some way to verify they are all correct? The test run green, unless the ones that currently have design errors and could be expected to fail in the current state of the project in question.

        My suggestion is that a clean restart should be a menu alternative.

        Show
        mib MiB added a comment - - edited No, there are no such markers I see now, also after a clean rebuild. What I saw before was probably left from an earlier build. There were no warnings about a broken crosscutting model. I also did clean restart of STS and then autobuilt again. Still no markers. So I did another clean rebuild and now I think there are markers. Is there some way to verify they are all correct? The test run green, unless the ones that currently have design errors and could be expected to fail in the current state of the project in question. My suggestion is that a clean restart should be a menu alternative.
        Hide
        aeisenberg Andrew Eisenberg added a comment -

        Thanks for the response. What do you mean 'a clean restart'? At a minimum, AJDT should add some kind of marker when the crosscutting model is invalid or incomplete. The problem is going to be detecting when this occurs, but this is something that I can work on.

        Show
        aeisenberg Andrew Eisenberg added a comment - Thanks for the response. What do you mean 'a clean restart'? At a minimum, AJDT should add some kind of marker when the crosscutting model is invalid or incomplete. The problem is going to be detecting when this occurs, but this is something that I can work on.
        Hide
        mib MiB added a comment -

        With "clean restart" I meant I started up STS with "-clean" on a sepratate line in "STS.ini".

        I could see some markers I think, but very few.

        How can I help you at this stage?

        Show
        mib MiB added a comment - With "clean restart" I meant I started up STS with "-clean" on a sepratate line in "STS.ini". I could see some markers I think, but very few. How can I help you at this stage?
        Hide
        aeisenberg Andrew Eisenberg added a comment -

        Nothing right now. I'll have a look at this in the next day or two and see if I can detect when the model is incomplete (and then have the push in refactoring produce a fatal error).

        Show
        aeisenberg Andrew Eisenberg added a comment - Nothing right now. I'll have a look at this in the next day or two and see if I can detect when the model is incomplete (and then have the push in refactoring produce a fatal error).
        Hide
        aeisenberg Andrew Eisenberg added a comment -

        I committed a fix such that pushin refactoring will do more extensive conditions checking before performing.

        Now, if there are any errors in the aspect or the target type (even if they are unrelated to the ITD being pushed in). Also, it is now checking for ITDs that have no target. In either case, if an error is found the refactoring will be blocked until fixed.

        The downside is that some refactrings that would have worked in the past are now blocked. However, we are also preventing situations that would cause unexpected, subtle errors like the one that you received earlier.

        I think this fix covers the problem described in this issue, so closing. The fix will be available in the next dev build of AJDT.

        Show
        aeisenberg Andrew Eisenberg added a comment - I committed a fix such that pushin refactoring will do more extensive conditions checking before performing. Now, if there are any errors in the aspect or the target type (even if they are unrelated to the ITD being pushed in). Also, it is now checking for ITDs that have no target. In either case, if an error is found the refactoring will be blocked until fixed. The downside is that some refactrings that would have worked in the past are now blocked. However, we are also preventing situations that would cause unexpected, subtle errors like the one that you received earlier. I think this fix covers the problem described in this issue, so closing. The fix will be available in the next dev build of AJDT.
        Hide
        mib MiB added a comment -

        Thanks Andrew. Springsource/Vmware is easily one of the most responsive software companies I've been bug reporting to. An inspiration.

        Show
        mib MiB added a comment - Thanks Andrew. Springsource/Vmware is easily one of the most responsive software companies I've been bug reporting to. An inspiration.

          People

          • Assignee:
            aeisenberg Andrew Eisenberg
            Reporter:
            mib MiB
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: