Spring Roo
  1. Spring Roo
  2. ROO-222

Allow AJDT-style push-in refactor directly from Roo shell

    Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: @ CORE
    • Labels:
      None

      Description

      It would be great to have a maven2 plugin or roo command to create a roo - & "roo-injected-aspectj" independent source distribution (maybe using the Push in refactoring for AJDT? ). So, no .aj files, no Roo files, only .java files without the "roo aspect" code.

      Goal: use roo to generate boilerplate code and take off from there to build the rest. Prototype the infrastructure, entities and security model etc. and then 'pull out' all the Roo-related stuff in order to go on with manual work on the project.

      This would allow to rapidly perform the initial setup of a project for customers who would perhaps not allow Roo being used for the development in general.

        Issue Links

          Activity

          Hide
          Ben Alex added a comment -

          I can see why people may like this feature, but it is difficult for us to implement because we do not have access to AJDT from within the Roo shell. To use AJDT would mean we need the many components from Eclipse, which not only would represent a significant increase in our download size but would also create some licensing issues (EPL has some significant restrictions if you want to redistribute it with a non-EPL project under an open source license).

          At a philosophical level I also don't believe push-in refactor is a good idea. It means a user has to take manual responsibility for a significant amount of tedious coding in their project, and it will make their Java classes significantly larger due to the introduction of all the Java members that Roo normally efficiently and effectively hides away in separate compilation units and automatically maintains in response to changes in the user's project (eg getters, setters, toStrings, persistence methods, controller methods etc).

          I've left this request open to gauge community interest in this feature (please vote if you're interested), although I have concerns about encouraging people to push-in refactor their projects from Roo. If we did add it, doing so would primarily be to demonstrate our claim of no lock-in as opposed to being something we encourage people to use and particularly given it's easy enough to use AJDT directly to perform the desired push-in refactoring anyway. Please vote for this request if you'd like to see it implemented.

          Show
          Ben Alex added a comment - I can see why people may like this feature, but it is difficult for us to implement because we do not have access to AJDT from within the Roo shell. To use AJDT would mean we need the many components from Eclipse, which not only would represent a significant increase in our download size but would also create some licensing issues (EPL has some significant restrictions if you want to redistribute it with a non-EPL project under an open source license). At a philosophical level I also don't believe push-in refactor is a good idea. It means a user has to take manual responsibility for a significant amount of tedious coding in their project, and it will make their Java classes significantly larger due to the introduction of all the Java members that Roo normally efficiently and effectively hides away in separate compilation units and automatically maintains in response to changes in the user's project (eg getters, setters, toStrings, persistence methods, controller methods etc). I've left this request open to gauge community interest in this feature (please vote if you're interested), although I have concerns about encouraging people to push-in refactor their projects from Roo. If we did add it, doing so would primarily be to demonstrate our claim of no lock-in as opposed to being something we encourage people to use and particularly given it's easy enough to use AJDT directly to perform the desired push-in refactoring anyway. Please vote for this request if you'd like to see it implemented.
          Hide
          Brian Carroll added a comment -

          First of all, I would like to applaud the ROO team. Roo is truely a great addition to help bootstrap projects using Spring. I've been experimenting with it and am "sold" on it.

          Second, as a long term builder of code generation tools, I can see both sides of this discussion. However, I strongly advocate providing means for viewing and editing the fully expanded code within the IDE. There are several reasons for my position:
          1. In Roo's current state (I'm using RC2 and am about to try RC3) there seem to be many aspects (in the non-programming sense) that either don't work quite right, or at least create considerable sense of unease in the user. (Some of that unease and uncertainty may go away with the expanded RC3 doc - thank you.) One example is how does one go about using "field reference" or, more likely, "field set" to express a many-to-many relationship. Another example is that the use of "push-in refactoring" is still quite a mystery (I admit to being an AspectJ/ADJT newbie). Even after reading everying I could find on the topic, I could not get the Push-in refactoring options to show up in context menus (using either Eclipse with JEE (i.e. WST support) with ADJT 20 or with Spring STS 2.1.0).

          2. Given the uncertaintity a new user of a new tool is likely to have (e.g. is the unexpected behavior due to bugs in the recently written code, have good when installing or configuring the tools, or am I simply misinterpreting the sparse documentation), it would be very reassuring to be able to see the generated Java code. While I can imagine what it would look like from reading the .aj files, seeing it all assembled would make extending that code easier sines a developer would know precisely what he is modifiying.

          3. I am likely to need to add JPA annotations to the domain objects beyond what can be expressed in the roo "field" commands. Again, being able to see all the generated code would aid that process.

          So I vote for making it easy to view the full generated code. And at the same time provide a way to retain my edits and still have roo act like that genie looking over my code to fix any inconsistencies I create.

          Thanks again - Even in its present state, I can see that Roo is going to be a killer tool! Keep it up.

          Show
          Brian Carroll added a comment - First of all, I would like to applaud the ROO team. Roo is truely a great addition to help bootstrap projects using Spring. I've been experimenting with it and am "sold" on it. Second, as a long term builder of code generation tools, I can see both sides of this discussion. However, I strongly advocate providing means for viewing and editing the fully expanded code within the IDE. There are several reasons for my position: 1. In Roo's current state (I'm using RC2 and am about to try RC3) there seem to be many aspects (in the non-programming sense) that either don't work quite right, or at least create considerable sense of unease in the user. (Some of that unease and uncertainty may go away with the expanded RC3 doc - thank you.) One example is how does one go about using "field reference" or, more likely, "field set" to express a many-to-many relationship. Another example is that the use of "push-in refactoring" is still quite a mystery (I admit to being an AspectJ/ADJT newbie). Even after reading everying I could find on the topic, I could not get the Push-in refactoring options to show up in context menus (using either Eclipse with JEE (i.e. WST support) with ADJT 20 or with Spring STS 2.1.0). 2. Given the uncertaintity a new user of a new tool is likely to have (e.g. is the unexpected behavior due to bugs in the recently written code, have good when installing or configuring the tools, or am I simply misinterpreting the sparse documentation), it would be very reassuring to be able to see the generated Java code. While I can imagine what it would look like from reading the .aj files, seeing it all assembled would make extending that code easier sines a developer would know precisely what he is modifiying. 3. I am likely to need to add JPA annotations to the domain objects beyond what can be expressed in the roo "field" commands. Again, being able to see all the generated code would aid that process. So I vote for making it easy to view the full generated code. And at the same time provide a way to retain my edits and still have roo act like that genie looking over my code to fix any inconsistencies I create. Thanks again - Even in its present state, I can see that Roo is going to be a killer tool! Keep it up.
          Hide
          Kashif Ur Rehman Qureshi added a comment -

          I am also voting for this issue to generate the pure java code. Thanks

          Show
          Kashif Ur Rehman Qureshi added a comment - I am also voting for this issue to generate the pure java code. Thanks
          Hide
          Haikal Saadh added a comment -

          I'm happy for the Roo generated code to stay as aspects. If I wanted Roo to keep it's hands off something, I'm happy to manually push-in, OR remove the Roo annotations, rename the ITDs, and maintain them by hand (As I am doing for some finders atm).

          Show
          Haikal Saadh added a comment - I'm happy for the Roo generated code to stay as aspects. If I wanted Roo to keep it's hands off something, I'm happy to manually push-in, OR remove the Roo annotations, rename the ITDs, and maintain them by hand (As I am doing for some finders atm).
          Hide
          Ben Alex added a comment -

          Just a quick reminder to myself this would be useful also via build scripts for code metric tools and also compilers like GWT (http://forum.springsource.org/showthread.php?p=285134).

          Show
          Ben Alex added a comment - Just a quick reminder to myself this would be useful also via build scripts for code metric tools and also compilers like GWT ( http://forum.springsource.org/showthread.php?p=285134 ).
          Hide
          Tilman Bender added a comment -

          Ah thanks Ben. Just came here to vote and link to the reply I got on the aspectj list:
          http://old.nabble.com/Code-Analysis-Tools-and-AOP-td27593217.html#a27658458

          Show
          Tilman Bender added a comment - Ah thanks Ben. Just came here to vote and link to the reply I got on the aspectj list: http://old.nabble.com/Code-Analysis-Tools-and-AOP-td27593217.html#a27658458
          Hide
          Grigory added a comment -

          It is badly needed at least for debug.
          +1.

          Show
          Grigory added a comment - It is badly needed at least for debug. +1.

            People

            • Assignee:
              Unassigned
              Reporter:
              David
            • Votes:
              38 Vote for this issue
              Watchers:
              13 Start watching this issue

              Dates

              • Created:
                Updated: