Page 2 of 2 FirstFirst 12
Results 11 to 13 of 13

Thread: No controllers, services etc after SVN checkout

  1. #11
    Join Date
    May 2010
    Posts
    398

    Default

    Mohadib,

    I'll really need more details on what you mean by 'checking out as Grails'. I take it you are talking about getting a project out of some version managament system, like SVN or CVS.

    Would need to know details about what version management system and which Eclipse tools are used for this. For example with subversion there is subclipse and subversive to choose from, and people using one or the other are having different experiences.

    Also, I'd need to know how the project was shared and exactly which steps the user/developer is taking to import them. One thing that can cause a lot of trouble is if developers decide not to put Eclipse configuration files under version control, having these files missing confuses Eclipse / STS since those files configure how your project works in STS.

    The recent improvements I made are related to this. I try to detect missing / broken configurations when new projects are added to the workspace. Unfortunately, this tricky, because projects can get broken in many ways, so I'm sure I'm missing come cases that need better handling.

    An example (maybe happening for your developer, but I'm just guessing). If the user is explicitly not versioning files like (.project, .classpath and .settings) and then later on using some broken import wizard that creates new Grails configs that are incorrect (some SVN tools are known to do that!) then it would make sense why 'import as Grails' doesn't work and 'import as Groovy' does. Because when you call 'Convert to Grails' the correct configs will be recreated. But if you start by restoring an incorrect configuration, then we don't get the opportunity to fix them (the configs are there, so it looks 'ok' but they are in fact corrupt).

    Anyway, please tell me what version management system is being used, and I can probably provide help in how to share / import projects reliably.

    Kris
    Kris De Volder -- SpringSource

  2. #12
    Join Date
    May 2010
    Posts
    26

    Default

    Hey Kris,
    I checked the project out using subclipse in STS 2.6.0m1. The project was shared via the command line svn app. No eclipse files are in the repository.
    We are ok with having the eclipse files in the repo as it doesnt bother the one non-sts user.

    If you could advise on how I should share/checkout in the future I would be very grateful.

    Thanks
    Jason

  3. #13
    Join Date
    May 2010
    Posts
    398

    Default

    Hi Jason,

    You will typically have a better experience if you do share the Eclipse configuration files.

    However, if you don't, or perhaps the project wasn't originally an Eclipse based project, then using subversive to 'Checkout as an existing' project should work well with the recent fixes I put in. What will happen is a 'vanilla' project with no grails specific settings appears in the workspace, and STS will detect that this new project actually 'looks like a Grails project' but isn't conigured as one. It will popup some dialogs that recommend some fixes... if you click 'yes' on those the project should be setup correctly.

    I prefer subversive, but you can use subclipse also. If you use subclipse, make sure not to use the 'checkout with wizard' option which is the default when you import projects with no Eclipse settings. Instead, check it out with 'check out as project in the workspace". This is the second option just below the default. If you do this, you end up with the same kind of scenario. The problem with the subclipse method of using the Grails wizard is that subclipse is trying to use our wizard to create an empty project and then fill that empty project with your files. But the settings created for an empty project will seldom be correct for your particular project (unless it was pretty much empty :-)

    After you've turned your project into an Eclipse project, you should share the eclipse specific files (otherwise if one user makes changes that cause those files to change other users may end up having problems).

    Please try this, and, if you still have problems, please don't hesitate to ask more questions.

    Kris
    Kris De Volder -- SpringSource

Posting Permissions

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