Spring Tool Suite
  1. Spring Tool Suite
  2. STS-814

Improve experience for adding Roo to existing projects

    Details

    • Type: New Feature New Feature
    • Status: Open Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: MAVEN, ROO
    • Labels:
      None

      Description

      Roo has some great features (@RooJavaBean, @RooToString, etc) that can be applied just as well to existing projects that have their own development methodology as green field projects that buy into the whole Roo enchilada. I attempted to add Roo support to an existing project, and while I was able to eventually get it to work, I was left wondering if the user experience could be improved.

      As a user, I'd like to be able to execute a single command on my project to turn on Roo support. This command would add the Roo nature, add the AspectJ nature, enable JDT weaving, add the roo.annotations .jar to my .pom, and configure AspectJ compilation in Maven. Currently, I have to do each of these steps individually in STS which is a error prone process.

        Activity

        Hide
        Keith Donald added a comment - - edited

        One of the things that particularly tripped me up: I wasn't sure whether JDT weaving was needed or not, and the "scary" error message saying it would impact the performance of my IDE led me to turn it off. In reality, for any kind of STS + ROO experience, this feature needs to always be enabled. If it's not enabled, you get red squiggles that aren't really compiler errors and no code completion on ITDs.

        Show
        Keith Donald added a comment - - edited One of the things that particularly tripped me up: I wasn't sure whether JDT weaving was needed or not, and the "scary" error message saying it would impact the performance of my IDE led me to turn it off. In reality, for any kind of STS + ROO experience, this feature needs to always be enabled. If it's not enabled, you get red squiggles that aren't really compiler errors and no code completion on ITDs.
        Hide
        Andy Clement (c) added a comment -

        I agree with Keith on that last point. Due to Roo's heavy use of ITDs, running without JDT weaving can lead to a confusing initial experience (because the JDT weaving fixes the red squigglies produced during ITD reconciling). Feels like Add Roo nature should cause the AspectJ nature to be added and offer to turn on JDT weaving (avoiding the dialog that AJDT normally puts up, perhaps).

        Show
        Andy Clement (c) added a comment - I agree with Keith on that last point. Due to Roo's heavy use of ITDs, running without JDT weaving can lead to a confusing initial experience (because the JDT weaving fixes the red squigglies produced during ITD reconciling). Feels like Add Roo nature should cause the AspectJ nature to be added and offer to turn on JDT weaving (avoiding the dialog that AJDT normally puts up, perhaps).
        Hide
        Christian Dupuis added a comment - - edited

        This seems like a reasonable request but I'm not sure about the outlined solution and making this a STS feature:

        • STS does not know anything about the version of Roo that is being used (e.g. for the annotation jar)
        • STS does not know anything about requirements of current and future Roo versions in the pom.xml
        • ...

        All this knowledge is already part for Roo. So I guess this should get the command in Roo itself where a user can do the following in STS:

        • Add Roo support (as the current action)
        • Open Roo Shell and
        • roo> configure project

        This also enables this to be executable outside of STS.

        Certainly I can merge the above three separate steps into one action in STS. But the core implementation needs to go into Roo.

        Regarding enabling JDT weaving out of the box, I put in my veto for the following two reasons:

        • JDT weaving has still a significant impact on memory consumption which would hurt users that don't intent to use Roo within STS or other means of ITD support
        • I haven't heart a single user complaining about the dialog that comes up. Maybe we should re-phrase the dialog text to be less "scary"

        Christian

        Show
        Christian Dupuis added a comment - - edited This seems like a reasonable request but I'm not sure about the outlined solution and making this a STS feature: STS does not know anything about the version of Roo that is being used (e.g. for the annotation jar) STS does not know anything about requirements of current and future Roo versions in the pom.xml ... All this knowledge is already part for Roo. So I guess this should get the command in Roo itself where a user can do the following in STS: Add Roo support (as the current action) Open Roo Shell and roo> configure project This also enables this to be executable outside of STS. Certainly I can merge the above three separate steps into one action in STS. But the core implementation needs to go into Roo. Regarding enabling JDT weaving out of the box, I put in my veto for the following two reasons: JDT weaving has still a significant impact on memory consumption which would hurt users that don't intent to use Roo within STS or other means of ITD support I haven't heart a single user complaining about the dialog that comes up. Maybe we should re-phrase the dialog text to be less "scary" Christian
        Hide
        Keith Donald added a comment -

        Ok, I'm just trying to speak from the user experience perspective, not outline how I think it should be implemented... sounds good to me.

        Regarding the JDT weaving message: The scariness of the message is one aspect of it, the other is it's not clear to the user if this weaving is required or not. I learned the hard way it is required if you're using ITDs, otherwise the project user experience is unacceptable in the IDE. Once you disable it and permanently dismiss the dialog, it's a little tricky trying to figure out how to enable it again. Again, this is all just thinking from the user perspective.

        Show
        Keith Donald added a comment - Ok, I'm just trying to speak from the user experience perspective, not outline how I think it should be implemented... sounds good to me. Regarding the JDT weaving message: The scariness of the message is one aspect of it, the other is it's not clear to the user if this weaving is required or not. I learned the hard way it is required if you're using ITDs, otherwise the project user experience is unacceptable in the IDE. Once you disable it and permanently dismiss the dialog, it's a little tricky trying to figure out how to enable it again. Again, this is all just thinking from the user perspective.
        Hide
        Alexander Heusingfeld added a comment -

        I agree with Christian but I don't see this as an additional command in Roo. Instead I think the existing "perform eclipse" should be enhanced with the points named by keith as most of these are IMHO configuration options special to eclipse/STS. However adding AspectJ nature when the Roo nature is added sounds kind of self-evident to me.

        Another thing is that I think there should definitely be a command which enables the user to "upgrade" an existing Roo project. Therefore I added https://jira.springsource.org/browse/ROO-605 as this ain't a STS issue either.

        Regards
        Alex

        Show
        Alexander Heusingfeld added a comment - I agree with Christian but I don't see this as an additional command in Roo. Instead I think the existing "perform eclipse" should be enhanced with the points named by keith as most of these are IMHO configuration options special to eclipse/STS. However adding AspectJ nature when the Roo nature is added sounds kind of self-evident to me. Another thing is that I think there should definitely be a command which enables the user to "upgrade" an existing Roo project. Therefore I added https://jira.springsource.org/browse/ROO-605 as this ain't a STS issue either. Regards Alex
        Hide
        Keith Donald added a comment -

        The issue I have with "perform eclipse" currently is it uses the older command-line mvn eclipse:eclipse plugin. A lot of users these days (me included) prefer Sonatype's m2eclipse plugin because it has better classpath management inside the IDE and a number of other features.

        Show
        Keith Donald added a comment - The issue I have with "perform eclipse" currently is it uses the older command-line mvn eclipse:eclipse plugin. A lot of users these days (me included) prefer Sonatype's m2eclipse plugin because it has better classpath management inside the IDE and a number of other features.
        Hide
        Keith Donald added a comment - - edited

        Here are the specific things I had to do to add Roo to an existing project:

        For Maven:

        • Add roo-annotations to .pom:
        <dependency>
        	<groupId>org.springframework.roo</groupId>
        	<artifactId>org.springframework.roo.annotations</artifactId>
        	<version>1.0.1.RELEASE</version>
        	<scope>provided</scope>
        </dependency>
        
        • Add aspectj to .pom:
        <!-- AspectJ -->
        <dependency>
        	<groupId>org.aspectj</groupId>
        	<artifactId>com.springsource.org.aspectj.runtime</artifactId>
        	<version>${org.aspectj.version}</version>
        </dependency>
        
        • Add the following to .pom for Maven AspectJ compilation (note the 1.3 version of this plugin does NOT appear to work with ITDs)
        <plugin>
        	<groupId>org.codehaus.mojo</groupId>
        	<artifactId>aspectj-maven-plugin</artifactId>
        	<version>1.2</version>
        	<dependencies>
        		<!-- NB: You must use Maven 2.0.9 or above or these are ignored (see MNG-2972) -->
        		<dependency>
        			<groupId>org.aspectj</groupId>
        			<artifactId>com.springsource.org.aspectj.runtime</artifactId>
        			<version>${org.aspectj.version}</version>
        		</dependency>
        		<dependency>
        			<groupId>org.aspectj</groupId>
        			<artifactId>com.springsource.org.aspectj.tools</artifactId>
        			<version>${org.aspectj.version}</version>
        		</dependency>
        	</dependencies>
        	<executions>
        		<execution>
        			<goals>
        				<goal>compile</goal>
        				<goal>test-compile</goal>
        			</goals>
        		</execution>
        	</executions>
        	<configuration>
        		<outxml>true</outxml>
        		<source>${java.version}</source>
        		<target>${java.version}</target>
        	</configuration>
        </plugin>
        
        • Add the following customizaiton to the surefire test plugin:
        <plugin>
        	<groupId>org.apache.maven.plugins</groupId>
        	<artifactId>maven-surefire-plugin</artifactId>
        	<configuration>
        		<junitArtifactName>org.junit:com.springsource.org.junit</junitArtifactName>
        		<excludes>
        			<exclude>**/*_Roo_*</exclude>
        		</excludes>
        	</configuration>
        </plugin>
        

        For STS IDE:

        • Right-click on project -> Spring Tools -> Add Roo Project Nature
        • Right-click on project -> Configure -> Configure as AspectJ project
        • Remove newly added AspectJ Runtime Library classpath container since Maven Classpath Container already contains aspectjrt.jar.
        • Make sure Preferences -> JDT Weaving is enabled

        After doing these things, I can go into STS, open a Roo shell against my project and start adding @RooJavaBean, @RooToString, etc to my types with Roo properly recognizing them & the resulting ITDs weaved successfully both inside and outside the IDE.

        Show
        Keith Donald added a comment - - edited Here are the specific things I had to do to add Roo to an existing project: For Maven: Add roo-annotations to .pom: <dependency> <groupId>org.springframework.roo</groupId> <artifactId>org.springframework.roo.annotations</artifactId> <version>1.0.1.RELEASE</version> <scope>provided</scope> </dependency> Add aspectj to .pom: <!-- AspectJ --> <dependency> <groupId>org.aspectj</groupId> <artifactId>com.springsource.org.aspectj.runtime</artifactId> <version>${org.aspectj.version}</version> </dependency> Add the following to .pom for Maven AspectJ compilation (note the 1.3 version of this plugin does NOT appear to work with ITDs) <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>aspectj-maven-plugin</artifactId> <version>1.2</version> <dependencies> <!-- NB: You must use Maven 2.0.9 or above or these are ignored (see MNG-2972) --> <dependency> <groupId>org.aspectj</groupId> <artifactId>com.springsource.org.aspectj.runtime</artifactId> <version>${org.aspectj.version}</version> </dependency> <dependency> <groupId>org.aspectj</groupId> <artifactId>com.springsource.org.aspectj.tools</artifactId> <version>${org.aspectj.version}</version> </dependency> </dependencies> <executions> <execution> <goals> <goal>compile</goal> <goal>test-compile</goal> </goals> </execution> </executions> <configuration> <outxml> true </outxml> <source>${java.version}</source> <target>${java.version}</target> </configuration> </plugin> Add the following customizaiton to the surefire test plugin: <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-surefire-plugin</artifactId> <configuration> <junitArtifactName>org.junit:com.springsource.org.junit</junitArtifactName> <excludes> <exclude>**/*_Roo_*</exclude> </excludes> </configuration> </plugin> For STS IDE: Right-click on project -> Spring Tools -> Add Roo Project Nature Right-click on project -> Configure -> Configure as AspectJ project Remove newly added AspectJ Runtime Library classpath container since Maven Classpath Container already contains aspectjrt.jar. Make sure Preferences -> JDT Weaving is enabled After doing these things, I can go into STS, open a Roo shell against my project and start adding @RooJavaBean, @RooToString, etc to my types with Roo properly recognizing them & the resulting ITDs weaved successfully both inside and outside the IDE.
        Hide
        Ben Alex added a comment -

        It would also be necessary to add the Spring Aspects JAR, so that @Transactional, @Configurable etc works. If people just want to @RooToString etc, this isn't needed, but they'll be surprised when they use @RooEntity.

        I agree with Christian that Roo should understand what it needs to do to a Maven POM to make it into a Roo project and cause the required adjustments to take place. It would be a source of incompatibilities, support incidents and maintenance cost for STS to be continuously updated to reflect the latest Roo POM configuration policies.

        In any event there have been requests from the Roo community to be able to use their own POMs - not the Roo template POM. Accordingly having some sort of "setup my existing POM" command in Roo would make it possible to implement that new feature.

        On the downside the present project metadata and services abstractions were intentionally designed to generalise the dependency management features of Maven and Ant+Ivy. If we start to add more Maven-related commands, it gets harder and harder to support Ant+Ivy. The relevant ticket is https://jira.springsource.org/browse/ROO-91 and presently has some 26 votes. I am reluctant to go down a path that would make Ant+Ivy even harder to achieve. Having said that, we already have the "perform" commands and these are not going to be supported by Ant+Ivy either, so maybe it will just be a case that you get a better experience with Maven and Ant/Ivy support is more primitive. As an aside, can Christian comment on the state of Ant/Ivy container classpaths in Eclipse/STS at this time? Last time I discussed it with Ben Hale he said it was not quite ready for prime time, but that was some time ago.

        Keith, I would not recommend the svn:ignore portion of the commands. We generally recommend the checkin of ITDs, so your project will always be compilable without running Roo again and you know the exact ITDs you had when you did a CI/release build. In any event I'm not sure we'd want to favour SVN, as I think it's fair to say SVN has a lot more feasible OSS competition these days.

        Christian, I would also like to see the AJDT weaving message be eliminated if any project in the workspace has the AspectJ nature. An informational message might be of the style, "One or more of your projects is currently using AspectJ [name of projects]. JDT weaving has therefore been enabled to ensure you have a better development experience. You can switch this off if required by using Preferences > etc after the restart (although this is not recommended)". We know they need this feature, so switching it on and informing them delivers better usability. I'd also like to see fewer messages to do with AJDT weaving. I'd like AJDT to simply tell them what has happened and click the "Restart Now" button or "Restart Later" in the same dialogue. Then when the IDE restarts it can do the reindex automatically. Right now there are three prompts (enable weaving, restart workbench, should I reindex) and each require a decision from the user. We could have an "automatically handle AJDT weaving decisions" tick box under the AJDT settings (which would default to true) if we wanted to ensure expert users could still have the present three messages displayed.

        Show
        Ben Alex added a comment - It would also be necessary to add the Spring Aspects JAR, so that @Transactional, @Configurable etc works. If people just want to @RooToString etc, this isn't needed, but they'll be surprised when they use @RooEntity. I agree with Christian that Roo should understand what it needs to do to a Maven POM to make it into a Roo project and cause the required adjustments to take place. It would be a source of incompatibilities, support incidents and maintenance cost for STS to be continuously updated to reflect the latest Roo POM configuration policies. In any event there have been requests from the Roo community to be able to use their own POMs - not the Roo template POM. Accordingly having some sort of "setup my existing POM" command in Roo would make it possible to implement that new feature. On the downside the present project metadata and services abstractions were intentionally designed to generalise the dependency management features of Maven and Ant+Ivy. If we start to add more Maven-related commands, it gets harder and harder to support Ant+Ivy. The relevant ticket is https://jira.springsource.org/browse/ROO-91 and presently has some 26 votes. I am reluctant to go down a path that would make Ant+Ivy even harder to achieve. Having said that, we already have the "perform" commands and these are not going to be supported by Ant+Ivy either, so maybe it will just be a case that you get a better experience with Maven and Ant/Ivy support is more primitive. As an aside, can Christian comment on the state of Ant/Ivy container classpaths in Eclipse/STS at this time? Last time I discussed it with Ben Hale he said it was not quite ready for prime time, but that was some time ago. Keith, I would not recommend the svn:ignore portion of the commands. We generally recommend the checkin of ITDs, so your project will always be compilable without running Roo again and you know the exact ITDs you had when you did a CI/release build. In any event I'm not sure we'd want to favour SVN, as I think it's fair to say SVN has a lot more feasible OSS competition these days. Christian, I would also like to see the AJDT weaving message be eliminated if any project in the workspace has the AspectJ nature. An informational message might be of the style, "One or more of your projects is currently using AspectJ [name of projects] . JDT weaving has therefore been enabled to ensure you have a better development experience. You can switch this off if required by using Preferences > etc after the restart (although this is not recommended)". We know they need this feature, so switching it on and informing them delivers better usability. I'd also like to see fewer messages to do with AJDT weaving. I'd like AJDT to simply tell them what has happened and click the "Restart Now" button or "Restart Later" in the same dialogue. Then when the IDE restarts it can do the reindex automatically. Right now there are three prompts (enable weaving, restart workbench, should I reindex) and each require a decision from the user. We could have an "automatically handle AJDT weaving decisions" tick box under the AJDT settings (which would default to true) if we wanted to ensure expert users could still have the present three messages displayed.
        Hide
        Christian Dupuis added a comment -

        Ben, that sounds like we are on the same page.

        I'll work with Andrew to get the changes into the enablement of JDT weaving as I think your comments are very valid and will help the user to decide for JDT weaving. There is no need to tell the technical details and instead present the advantages.

        Show
        Christian Dupuis added a comment - Ben, that sounds like we are on the same page. I'll work with Andrew to get the changes into the enablement of JDT weaving as I think your comments are very valid and will help the user to decide for JDT weaving. There is no need to tell the technical details and instead present the advantages.
        Hide
        Alexander Heusingfeld added a comment -

        Ben, I don't know how this could be achieved exactly but how about the "MANIFEST-first-approach" for dependency management?
        STS does currently support this out-of-the-box and as I know from Jason van Zyl Maven 3 will also leverage this. In detail Maven (and the new version of m2eclipse) will be able to read the MANIFEST.MF and so to say generate the pom on the fly.

        Perhaps this could be an alternative so that Roo is not too strongly bound to one or the other dependency management system AND Roo will also support OSGi which would be a very nice goodie :-D

        Regards
        Alex

        Show
        Alexander Heusingfeld added a comment - Ben, I don't know how this could be achieved exactly but how about the "MANIFEST-first-approach" for dependency management? STS does currently support this out-of-the-box and as I know from Jason van Zyl Maven 3 will also leverage this. In detail Maven (and the new version of m2eclipse) will be able to read the MANIFEST.MF and so to say generate the pom on the fly. Perhaps this could be an alternative so that Roo is not too strongly bound to one or the other dependency management system AND Roo will also support OSGi which would be a very nice goodie :-D Regards Alex

          People

          • Assignee:
            Unassigned
            Reporter:
            Keith Donald
          • Votes:
            6 Vote for this issue
            Watchers:
            6 Start watching this issue

            Dates

            • Created:
              Updated:
              First Response Date: