Results 1 to 8 of 8

Thread: Missing WEB-INF folder on create

  1. #1
    Join Date
    Jul 2007
    Posts
    25

    Default Missing WEB-INF folder on create

    I've just successfully run the rsvp sample detailed in the blog.
    http://blog.springsource.com/2009/05/27/roo-part-2/

    Then I decided to create a new roo project.

    roo>create project -topLevelPackage com.myproject

    Created c:/myproject/pom.xml
    Created SRC_MAIN_JAVA
    Created SRC_MAIN_RESOURCES
    Created SRC_TEST_JAVA
    Created SRC_TEST_RESOURCES
    Created SRC_MAIN_WEBAPP
    Created SRC_MAIN_RESOURCES/applicationContext.xml

    ---------------------------------------------------
    The following is not created as stated in the blog

    Created SRC_MAIN_WEBAPP/WEB-INF
    Created SRC_MAIN_WEBAPP/WEB-INF/myproject-servlet.xml
    Created SRC_MAIN_WEBAPP/WEB-INF/web.xml
    Created SRC_MAIN_WEBAPP/WEB-INF/jsp
    Created SRC_MAIN_WEBAPP/WEB-INF/jsp/index.jsp
    Created SRC_MAIN_WEBAPP/WEB-INF/urlrewrite.xml


    I'm using version 1.0.0.M2 [rev 138]

    I'm I missing something?

  2. #2
    Join Date
    Mar 2008
    Location
    Sydney, AU
    Posts
    974

    Default

    Hi,

    We have made some changes to the 'create project' command as of the Roo M2 release. The blog post uses Roo M1 and therefore exhibits the behavior before the change was made.

    Basically, the create project command will now just create a bare-bones Spring application (no Spring MVC, or persistence) artifacts. This is because some applications will not need a Web layer at all. This change is documented in the ROO-26 jira ticket.

    Essentially, Roo will emit all web related artifacts the first time you issue the 'new controller' command which implies that you actually want a Web layer in your application.

    So there is no error or problem. Only the creation of the Web artifacts in your application is now delayed until you tell Roo to create Web-specific artifacts such as MVC controllers.

    Regards,
    Stefan

  3. #3

    Exclamation

    Quote Originally Posted by Stefan Schmidt View Post
    Hi,

    We have made some changes to the 'create project' command as of the Roo M2 release. The blog post uses Roo M1 and therefore exhibits the behavior before the change was made.

    Basically, the create project command will now just create a bare-bones Spring application (no Spring MVC, or persistence) artifacts. This is because some applications will not need a Web layer at all. This change is documented in the ROO-26 jira ticket.

    Essentially, Roo will emit all web related artifacts the first time you issue the 'new controller' command which implies that you actually want a Web layer in your application.

    So there is no error or problem. Only the creation of the Web artifacts in your application is now delayed until you tell Roo to create Web-specific artifacts such as MVC controllers.

    Regards,
    Stefan
    I realise this is only M2, but when docs and code are out of sync, it *is* a problem.

    For anyone else who was on the verge of giving up on Roo when the very first command failed to reproduce the documented behaviour, you need to do

    new controller [...]

    to create the MVC controller that Stefan refers to above, for example:

    new controller automatic -name MyController -formBackingObject MyFormModel
    Welcome to alpha.

  4. #4
    Join Date
    Mar 2008
    Location
    Sydney, AU
    Posts
    974

    Default

    @lateralcoder,

    As you know, Spring Roo is currently in milestone release (pre 1.0) and therefore things like this can change. This specific change of behavior was actually requested by a Roo user through a Jira enhancement request and we thought it makes sense to handle Web artifact creation only when the user actually indicates that he wants a Web-based project.

    The sample scripts we deliver actually provide a good starting point for you to learn about functionalities provided by roo. So for example if you would run the clinic.roo script and take a look at the messages it displays while running the script you would have noticed that the web artifacts are now generated as soon as the first controller (a web artifact) command is issued.

    But I take your point, Roo is missing a proper manual where these things are documented. This is currently work in progress and if you take a look into the Roo trunk you will notice that we now have docbook integration available and the work on the documentation is starting very soon.

    Regards,
    Stefan

  5. #5

    Default

    Stefan, I understand the motivation for the change, but I don't think it makes sense to "break" it for everyone just to fix it for one user.

    Nobody expects a manual just yet (a few pointers and runnable code is just fine), but it would be great if that the limited docs that are currently available could be kept in sync with the implementation.
    Welcome to alpha.

  6. #6
    Join Date
    Mar 2008
    Location
    Sydney, AU
    Posts
    974

    Default

    @lateralcoder,

    Besides good reason for the change (as described before), it actually did break applications the way we initially implemented it (see http://jira.springframework.org/browse/ROO-26). The change does not break anything now as far as I can see. So when you say it now 'breaks' for everyone I am a little lost. Can you elaborate?

    As for the documentation, you should be able to see the first few chapters appear during the next week.

    Regards,
    Stefan

  7. #7

    Smile

    Stefan, the change broke the creation of WEB-INF (as described in the blog post), and this led to other problems because of dependencies on those artifacts.

    From these issues and your response, I suspect that managing the dependencies from plugins to artifacts that are assumed to pre-exist will be an ongoing challenge for Roo - good luck with that.
    Welcome to alpha.

  8. #8
    Join Date
    May 2005
    Location
    Sydney, Australia
    Posts
    667

    Lightbulb

    Quote Originally Posted by lateralcoder View Post
    Nobody expects a manual just yet (a few pointers and runnable code is just fine), but it would be great if that the limited docs that are currently available could be kept in sync with the implementation.
    +1. Maybe Ben could update the relevant blog entry to reflect the actual output from RC1 when creating a project.
    Andrew Swan
    "Now is the EJB of our discontent made glorious Spring"

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •