Announcement Announcement Module
Collapse
No announcement yet.
No controllers, services etc after SVN checkout Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • No controllers, services etc after SVN checkout

    Hi folks,

    I just tried out the grails tools for eclipse, and checked out an existing Grails project to my workspace. The problem is that the tools can't seem to find the services, controllers etc, so they're not listed in the Project Explorer. It does however find the views. Can anyone give any hints on what I've done wrong?

  • #2
    I wouldn't automatically assume you've done anything wrong.

    When projects get imported into STS, depending on the state of their configuration and the workspace, sometimes projects don't get configured quite correctly. I've been working hard lately to try to make this more reliable. However, I'm certain there are cases when this doesn't yet work right. There are just so many cases depending on the state a project is in when it first gets imported. Different versions of grails in the workspace and the project, whether or not eclipse related configuration files where present in the imported project, whether these files where broken in a number of different ways etc.

    I certainly don't think this is something you 'did wrong'. More likely it is just "some case" we should try better to handle correctly.

    I'd really need to know more about the specifics of your situation to be able to help.

    What version of STS are you using, what version of the grails tooling? Are you already using STS 2.5.2. This is the version that has most of the fixes I put in recently for these types of issues.

    What version of Grails was the project made with? (version shown in "application.properties")
    What version of Grails have you configure in your workspace? (If you open Grails preferences from "Windows >> Preferences", which version of Grails is selected as the 'default').
    Did the project get committed to version management with the Eclipse related files included (stuff like .project, .classpath, .settings/)?

    The answers to each of these questions all influence what may happen when a project gets imported, and the precise contents of those files does as well.

    I think it is very important for us (STS devs) to try and make a user's experience when importing a project for the first time as smooth as possible. So I really want to work with you on figuring out why your project is having issues. Hopefully we can figure this out, fix your problem, and avoid other users having the same problem in the future.

    If you are not yet using 2.5.2 release of STS and the grails tooling, I suggest you start with that, a clean workspace and reimport your project. If you already on 2.5.2, or it doesn't solve your problem. We'll have to delve deeper into the details.

    Comment


    • #3
      Would you be able to share the project with me? E.g. you could zip it up and send me the zipfile by email ([email protected]) or attach it to this issue.

      If yes, please use external zip command from comandline. When people use the Eclipse-base 'export wizard' I have noticed that it seems to omit empty directories from the archive so the restored project isn't identical to the original.

      Comment


      • #4
        Sorry for not answering quickly, got tangled up in other stuff at work. I very much appreciate you taking the time to help me.

        I don't know if I can share the code unfortunately (business logic), but it's done with Grails 1.3.4. I downloaded the STS last week, and it seems to be 2.5.2. Selected Grails version in Eclipse is also 1.3.4.

        It was also committed to SVN with the .project and .classpath files, as far as I can see.

        Comment


        • #5
          Same here, maybe because of different grails versions?

          I have similar issues, even though my Project Explorer is not showing anything... I can only work with the Package Explorer.

          The Project we have is grails-1.3.4 with all the .project etc. included in the SVN. I tried this today with sts-2.5.2 (64bit jdk on vista 64bit). But I observed this earlier when is switched to 2.5.1.

          I am not sure whether this is related to the grails version shipping with sts, but i think the problem was not present, when I used the milestone releases of sts-2.5.

          Also, i realized, that (due to a fresh workspace) grails-1.3.4 was configured before checkout. Then I configured it, set it as default and checked the same project out into a different project. But this didn't help either...

          Since we have quite some custom plugins, that we usually install manually, maybe it could be the errors in the first workspace build from missing plugins?

          At first I suspeced a corrupted .project or any of theres files, but they looked OK, after manual inspection (and a refresh, since I haven been able to get the projectname in the dependencyURIs, so those are usually wrong, since every developer has it's own workspace structure).

          I could send you our project file if necessary... or give you a temporary SVN access so you could try it yourself? It is really annoying viewing everything in the package explorer, so I'd love to help you find out what is missing here.

          Comment


          • #6
            I have the same problem. I can share the project or do anything it takes to resolve this, This is a HUGE stumbling block for developers. And it does not seem to be an edge case at all. I fight this every time I import an existing project.

            Comment


            • #7
              Adrian 0CG,

              Sorry for not responding to your message earlier. It slipped by me. If you are willing to work with me (e.g. you proposed letting me access the SVN repo) I'd be interested.

              You can contact me directly at [email protected] or skype kdvolder.

              It should be noted that many of the improvements I made to STS in this area are very recent and only available in the nightly and milestone builds. So if you feel up to it, you could try upgrading from the nightly update site

              http://dist.springsource.com/snapsho.../nightly/e3.6/

              See if that makes things better for you. If it doesn't I'm definitely interested in learning more about what in your setup is causing it to fail.

              Kris -- SpringSource STS Developer

              Comment


              • #8
                Mohadib,

                I agree with you wholeheartedly. You shouldn't have to 'fight' with STS every time you import a Grails project from STS. Have you tried a nightly update? If that doesn't improve things for you. I would be very interested in learning more about your setup and what is causing it to break. You'll have to provide more details however, because it is hard to fix problems that I cannot reproduce.

                Kris

                Comment


                • #9
                  Kris,
                  Thanks for the reply. Im downloading 2.6.0m1 right now. Ill update here.

                  Thanks!

                  Comment


                  • #10
                    My employee said that checking out as grails did not work, same result, no domains or anything else checked out.

                    However checking out as groovy then converting to grails now works.

                    Thanks

                    Comment


                    • #11
                      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

                      Comment


                      • #12
                        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

                        Comment


                        • #13
                          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

                          Comment

                          Working...
                          X