Some comments abt Roo after Rod's JAOO presentation

Hi Team,

I saw Rods presentation on roo at jaoo, during that and now while using it for a small project I came over a number of issues:

Thanks Michael

* aliases for common commands (e.g. "string <name>" for "field string --fieldName <name>"
* shortcuts for commonly used commands (see above) OR better aliases!

* current entity is already in scope OK

* tests are not genereated if entity already exists

* repeat text already visible in command line when showing other completions (--<tab>)

* optional completions are not shown on tab without leading --

* autodetection of classes, I don't want to repeat package time and again if class name is unabiguous

* please put .aj files in separate tree, e.g. src/main/aspectj/pa/cka/ges/*.aj so that they don't clutter the ide's navigation views (not everyone uses sts) and command line completion in a normal shell (if the aj files are not used by the idea it can ignore that subtree completely)

* why is roo's syntax not grails compatible? or at least have a grails compatibility mode (or alias set)

* the roo commands Rod showed where not obvious and rather cumbersome, and also not consistent (sometimes install sometimes new for installation of stuff) - seems to cleaned up a bit in the current version

* how are separate maven modules handled e.g. I want to put the domain and service-facades into a separate maven module and the server (controller) classes in another

* the version Rod showed had no concept of an entity in context so he had to retype it again and again (--type ...)

* isn't the toString Generation using AspectJ overkill? wouldn't a code generation into the javaclass suit better there?

* how do I mock the finders and persistence in a unit testing setup ? (Like it is possible in grails)
* how is the update of references handled with entityManager.persist ? All the references that where also updated by this operation become invalid and have to be reloaded ?
* how do you handle the default auto-flush on query behaviour of JPA queries? how is this customizable per finder (usage) ?
* is the Spring EL supported by Roo ?
* is Roo able to generate and use Spring Java Config instead of XML?
* is there any support for test data generation from roo? You have all the meta-informatione necessary for that
* Rods presentation had "install finder", that was cumbersome, seems to be replaced by "fnder add", more natural would be "finder" or "add finder"
* what happens when I edit the aspects ? are my changes overwritten ?
* are there architectural rules enforced by the AspectJ integration, as often shown by Rod (in eclipse / sts) - again you have all the metadata available
* what transaction settings apply for finders if there is no "outer" transaction?
* JPA 2 support ?
* what about rich client support / (Swing) and for instance Restlet integration?

* Exception after shell suspend:
roo.sh (wd: ~/java/mareprint/backend)
Exception in thread "main" java.lang.IllegalStateException: Shell line reading failure
at org.springframework.roo.shell.jline.JLineShell.pro mptLoop(JLineShell.java:85)
at org.springframework.roo.bootstrap.Bootstrap.run(Bo otstrap.java:112)
at org.springframework.roo.bootstrap.Bootstrap.main(B ootstrap.java:52)
Caused by: java.io.IOException: Interrupted system call
at java.io.FileInputStream.read(Native Method)
at jline.Terminal.readCharacter(Terminal.java:99)
at jline.UnixTerminal.readVirtualKey(UnixTerminal.jav a:128)
at jline.ConsoleReader.readVirtualKey(ConsoleReader.j ava:1453)
at jline.ConsoleReader.readBinding(ConsoleReader.java :654)
at jline.ConsoleReader.readLine(ConsoleReader.java:49 4)
at jline.ConsoleReader.readLine(ConsoleReader.java:44 8)
at jline.ConsoleReader.readLine(ConsoleReader.java:30 0)
at org.springframework.roo.shell.jline.JLineShell.pro mptLoop(JLineShell.java:74)
... 2 more

Quote:

* aliases for common commands (e.g. "string <name>" for "field string --fieldName <name>"

From a usability perspective I believe people should be able to have a good, consistent experience out-of-the-box, even if they use a different person's machine. In a Roo scenario that would mean scripts people publish won't work unless the required aliases are installed. It would also provide multiple paths to achieving the same thing, which doesn't help people "habitate" to the way Roo works. Plus with Roo's TAB completing interface I believe the commands in Roo RC2 are quite short and understandable. So the lack of aliases is intentional.

Quote:

* shortcuts for commonly used commands (see above) OR better aliases!

I'm receptive to shortcut commands that perform a series of tasks, like in RC2 we have "controller all" to discover all entities that do not have a controller and produce them. Other shortcut command suggestions are welcome in Jira and are generally easy to implement.

Quote:

* current entity is already in scope OK

That is correct. For example, you can add a field or a dynamic finder to the last entity you created or otherwise worked with.

Quote:

* tests are not genereated if entity already exists

If you don't include --testAutomatically when using the "entity" command, it's easy to just perform a "test integration" command and create the missing integration test.

Quote:

* repeat text already visible in command line when showing other completions (--<tab>)

Sounds like a bug. We are aware of some minor inconveniences in the current shell, sometimes as a result of a JLine bug and sometimes as a result of a parsing/completion issue. In Roo 1.5.0 (target Q2 2010) we'll be shipping a new Spring Shell that uses a much more sophisticated internal engine that doesn't suffer from these bugs.

Quote:

* optional completions are not shown on tab without leading --

It is by design you must type -- to see optional completions. This is a usability decision, as we believe you should TAB until you complete all mandatory parts of a command and when you hit TAB and nothing more appears, it means pressing ENTER would/should work. The -- prefix says "ok, show me everything please", which we think is a nice way of going about it.

Quote:

* autodetection of classes, I don't want to repeat package time and again if class name is unabiguous

Good idea. We can easily perform a quick search in the converter implementation, as we already have the file system abstractions needed. Please feel free to log this as a feature request at https://jira.springsource.org/browse/ROO and I'll be pleased to look at doing so.

Quote:

* please put .aj files in separate tree, e.g. src/main/aspectj/pa/cka/ges/*.aj so that they don't clutter the ide's navigation views (not everyone uses sts) and command line completion in a normal shell (if the aj files are not used by the idea it can ignore that subtree completely)

A bit of history, in the first experimental prototype releases I used a separate source tree, but due to bugs in Maven or AJDT or Maven's Eclipse plugin or some combination thereof it didn't work. So I put them into src/main/java. Please feel free to log a Jira enhancement request and I'll have another look.

Quote:

* why is roo's syntax not grails compatible? or at least have a grails compatibility mode (or alias set)

As you've probably noticed by now, I have some strong views on usability and I designed both the Roo shell and the Roo commands to reflect these usability views. Because of key differences in the two approaches (TAB completions, spaces in command names, a dedicated shell vs an operating system command etc) it's not possible to make them consistent.

Quote:

* the roo commands Rod showed where not obvious and rather cumbersome, and also not consistent (sometimes install sometimes new for installation of stuff) - seems to cleaned up a bit in the current version

We reviewed this in Roo 1.0.0.RC2 and made a lot of improvements. Further suggestions are welcome as Jira tickets. For the benefits of the archive, https://jira.springsource.org/browse/ROO-232 lists the command name changes made for RC2.

Quote:

* how are separate maven modules handled e.g. I want to put the domain and service-facades into a separate maven module and the server (controller) classes in another

Multi-project modules is presently a feature request under https://jira.springsource.org/browse/ROO-120. Please vote on the issue if you'd like to see this prioritised.

Quote:

* the version Rod showed had no concept of an entity in context so he had to retype it again and again (--type ...)

Perhaps it was just the way Rod used Roo, to make it clear to the audience what he was doing? Contextual awareness has been in Roo since the alpha phases. If there is no contextual awareness, we're happy to receive a Jira bug report and fix it.

Quote:

* isn't the toString Generation using AspectJ overkill? wouldn't a code generation into the javaclass suit better there?

One of the key usability factors behind Roo was it acts in a predictable way. One dimension of predictability is that Roo will only modify a .java file in response to a shell command. On the other hand, Roo will automatically maintain .aj and .jspx files as it sees fit and in response to changes you may make outside of Roo or even while Roo isn't running. This is nice as it makes it really clear to people they can write code and Roo will never go in and clobber your changes (or attempt a fragile merge or similar operation). If you write a toString() method in your normal .java file, Roo will automatically treat your toString() method as priority and remove the Roo toString ITD. As such it works in a natural way and you don't need to tell it to stop making the toString ITD.

Quote:

* how do I mock the finders and persistence in a unit testing setup ? (Like it is possible in grails)

The "test mock" command will let you mock any static method. Normal mocking (eg EasyMock etc) can be used to mock any non-static method.

Quote:

* how is the update of references handled with entityManager.persist ? All the references that where also updated by this operation become invalid and have to be reloaded ?

Because Roo uses JPA, normal JPA semantics apply. Specifically, persistence by reachability within the same transactional unit of work will cause references to be updated. Roo introduces a merge() instance method to entities to facilitate detached entity persistence, as commonly seen in the web tier.

Quote:

* how do you handle the default auto-flush on query behaviour of JPA queries? how is this customizable per finder (usage) ?

Roo's dynamic finders all return a javax.persistence.Query object, so you can easily set the flush mode. eg: Entity.findFoosByNameIsNotNull().setFlushMode(Flus hModeType.COMMIT).

Quote:

* is the Spring EL supported by Roo ?

SPeL is supported where it makes sense, such as Spring Security's Roo integration uses SPeL expressions by default for authorization rules. We'll continue to use SPeL when use cases appear that provide a natural fit. In any event, as Roo produces standard Spring 3 applications, users are free to use SPeL directly in any place they wish to.

Quote:

* is Roo able to generate and use Spring Java Config instead of XML?

Spring application context XML files are so incredibly widely used that it's almost a given anyone who says they know Spring will know how to read those XML files. Because Roo aims to reuse mainstream Java approaches as much as possible, we only intend to support XML for application context definition.

Quote:

* is there any support for test data generation from roo? You have all the meta-informatione necessary for that

We have the "data on demand" feature (DOD). At present you can use the "dod" command, which is automatic if you use the "entity --testAutomatically" or "test integration" commands.

Quote:

* Rods presentation had "install finder", that was cumbersome, seems to be replaced by "fnder add", more natural would be "finder" or "add finder"

I totally agree. We changed it to "finder list" and "finder add" in RC2, as per ROO-232 mentioned above.

Quote:

* what happens when I edit the aspects ? are my changes overwritten ?

You can edit any *.aj file you like, except those with the filename pattern *_Roo_*.aj. Files with the *_Roo_*.aj pattern are managed by Roo and will automatically be created, updated and deleted in response to changes in your project metadata (eg you remove a @RooToString annotation from an entity, or add a new field to a class etc).

Quote:

* are there architectural rules enforced by the AspectJ integration, as often shown by Rod (in eclipse / sts) - again you have all the metadata available

You can create *.aj enforcement aspects at any time. We don't provide any enforcement aspects by default, but it's easy enough to do in the future if there was demand.

Quote:

* what transaction settings apply for finders if there is no "outer" transaction?

Default DataSource transactions will apply.

Quote:

* JPA 2 support ?

Unplanned until Spring itself supports JPA 2. We're in the same team, so when we know they're working on it in a major new Spring version we'll concurrently make Roo support it.

Quote:

* what about rich client support / (Swing) and for instance Restlet integration?

Restlet is unplanned, but could be a good example of a third-party add-on (see https://jira.springsource.org/browse/ROO-287 for details on how to write these in RC3 and above). Rich web clients (Flex/GWT) are on the Roo 2.0.0 roadmap (second half 2010).

Cheers
Ben

Now this I call real support! Ben, I really like your way of managing this project and I'm looking very forward to the future of roo, especially for the 2.0.0 with rich web clients because it often is so cumbersome to write goog AJAX UIs due to the rapidly changing UI libs and versions.

Fireball