Announcement Announcement Module
Collapse
No announcement yet.
Some remarks about Roo Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Some remarks about Roo

    Hi,

    I've tested roo and here are some remarks:

    1) I suggest to rename roo.sh to roo. This way I can simply add $ROO_HOME/bin to the path and type roo to start it.

    2) Why using non standard dependencies? I mean something like
    Code:
                    <dependency>
    			<groupId>org.junit</groupId>
    			<artifactId>com.springsource.org.junit</artifactId>
    			<version>4.5.0</version>
    			<scope>test</scope>
    		</dependency>
    it may be useful for some unreleased dependencies, but why JUnit, log4j, apache commons??? One purpose of Maven is to standardize dependencies. Also if every framework duplicates all standard dependencies, users local repository will become huge and network traffic will be increased. It may also be a additional work to configure repository managers like Archiva in corporate environment. So my wish is: use central as much as possible.

    3) What is the logic on roo command line concerning xxxx and -xxxx syntax. When I see something like:
    Code:
    list finders for -class ~.domain.Rsvp -filter code,equ
    I wondered why we could not have:
    Code:
    list finders for class ~.domain.Rsvp filter code,equ
    Anyway, it sound very promising.

    Regards

    Julien

  • #2
    Thanks for the feedback.

    We default to using SpringSource Enterprise Bundle Repository JARs because these have been quality control reviewed and enhanced to include proper manifests. We are finding increasing numbers of people are looking to deploy modular applications and the work done by SpringSource on maintaining these OSGi manifest-managed JARs is therefore of great use and we default Roo to use these as a result.

    Naturally you are able to edit the POM to use non-quality controller JARs if preferred. But just be aware they won't work very well if you're trying to deploy into an OSGi-based environment.

    Regarding the use of a hyphen (dash) to separate command options, this is necessary because of the way parsers work. As a matter of fact at present I am working on a LALR grammar for Spring Shell and they will be retained due to parsing optimization reasons.

    Hope this helps.

    Comment


    • #3
      Thanks for the explanations Ben.

      Comment


      • #4
        Spring Shell???

        What is Spring Shell???

        Comment

        Working...
        X