Announcement Announcement Module
Collapse
No announcement yet.
gradle-eclipse: "No project name mapping was defined for project" on import Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • gradle-eclipse: "No project name mapping was defined for project" on import

    Hi all,

    We have converted some of our large multi module Maven projects over to Gradle. These projects build perfectly when using Gradle from a shell however when I try and import them in to STS (3.2.0.M1 using GradleIDE 3.2.0.201211290814-M1) as a Gradle Project I receive the following error:

    "No project name mapping was defined for project :<project-name>"

    I initially thought this might be an error in the settings.xml but all the projects for which I get this error are mentioned in this file. As such I'm unsure how to progress my debugging of this issue. Does anyone know what might cause this? The error appears deterministically (i.e. always for the same projects) and does not affect all projects (i.e some import just fine)

    I'm trying to create a small reproducable example that I can share but so-far have had no luck in being able to reproduce the problem in the new project. Will attach the project as soon as I can reproduce.

    Many thanks.

  • #2
    The error is likely from STS gradle tooling and most likely a bug in the tooling. I think this is where it is coming from:

    https://github.com/SpringSource/ecli...pper.java#L121

    The name mapping referred to here is some computed gradle to Eclipse project name map that is used while importing a Gradle project. All imported projects should get a 'name mapping' automatically computed by the tools.

    Essentially the mapping defines what a gradle project will be called in the Eclipse workspace.

    I would need to be able to reproduce the problem and look around with a debugger to try and see what is causing this.

    One thing you can do is take a look in the Eclipse error log (Window >> show view >> Error log) maybe some other errors got logged there that give clues on what went wrong.

    For accuracy... clear the error log first. Then do whatever it is you do to cause the error, then see if something interesting / new appears in the log at the same time.

    Kris

    PS: One thing comes to mind maybe you have some upper/lower case confusion in project names. That might explain that a name mapping is not being found because its spelled upper/lower in one place and differently another. I've seen weirdness like that happen when people have case-insensitive file systems such as on Mac OS. They have project called 'foobar' and on the file system its directory is called 'fooBar'. The OS considers these the same, but the tools won't. The confusion can cause strange errors / bugs to manifest.

    Comment


    • #3
      Hi Kris,

      Thanks for replying. The stacktrace I get from the error log is:

      java.lang.IllegalArgumentException: No project name mapping was defined for project ':EM3SystemTest/Automation_WorkItems/em3-data-creation-suite'
      at org.eclipse.core.runtime.Assert.isLegal(Assert.jav a:63)
      at org.springsource.ide.eclipse.gradle.core.wizards.P recomputedProjectMapper.get(PrecomputedProjectMapp er.java:121)
      at org.springsource.ide.eclipse.gradle.core.wizards.G radleImportOperation$MissingProjectDependencyExcep tion.<init>(GradleImportOperation.java:398)
      at org.springsource.ide.eclipse.gradle.core.wizards.G radleImportOperation.verify(GradleImportOperation. java:449)
      at org.springsource.ide.eclipse.gradle.core.wizards.G radleImportOperation.verify(GradleImportOperation. java:424)
      at org.springsource.ide.eclipse.gradle.ui.wizards.Gra dleImportWizardPageOne.checkPageComplete(GradleImp ortWizardPageOne.java:359)
      at org.springsource.ide.eclipse.gradle.ui.wizards.Gra dleImportWizardPageOne$1.checkStateChanged(GradleI mportWizar
      dPageOne.java:169)


      As you can see the name of the project being depended upon contains upper and lower case characters, as well as hyphens and underscores (bonkers naming convention I know - I will be fixing this!). I checked all references to the project (from build.gradle, settings.gradle etc) and they all seem to be perfectly typed. I also renamed the project path, stripping out all the hyphens and underscores and lower casing the text. I then updated all references to the project and re-tried the import but unfortunately the problem occurs in exactly the same way with the same stack trace (albeit with the updated project name).

      The project dependency is declared in our build.gradle as follows:

      testCompile project(":EM3SystemTest/Automation_WorkItems/em3-data-creation-suite")


      Could it be that the STS tooling isn't coping with this declaration somehow? Grateful for any further ideas you may have or for anything I can do to provide further info.

      Cheers,

      Edd

      Comment


      • #4
        Not sure the testCompile dependency has anything to do with it. It is possible, but Idoubdt it. If you suspect it might, you can try commenting it out and doing the import again. Missing dependencies like that shouldn't cause the import to fail though you might end-up with an incomplete classpath for your project(s) after import, causing compile errors in the workspace.

        What seems most likely at this point to me, given where the error is coming from is that its some weirdness caused by names with funny characters.

        Not sure how to diagnose it. If I could reproduce it and poke around with a debugger I could probably figure out what's going wrong. But you say you weren't able to reproduce it in a sample project.

        One thing we can try is add more info to that error message (e.g. dump the entire contents of computed name mapping in it, maybe it will reveal something interesting about the suspected name 'funnyness').

        This will require you to update to a snapshot build of gradle tools and then when you get the error again, we may get a bit more info.

        I'll post something here when I got something for you to try later.

        Kris

        Comment


        • #5
          I just pushed a change to add more info to that error message. You can update your gradle tooling from this update site:

          http://dist.springsource.com/snapsho...gradle/nightly

          Error should then dump out the contents of the map as well as the value of the key that was used to look up.
          Somehow there's a mismatch between these two and hopefully the message will help figure out why exactly.

          Kris

          Comment


          • #6
            Hi Kris,

            Sorry for the huge delay in responding, have only just come back to this issue. I'm definitely getting a more informative error back, here's the error in all its glory:

            Code:
            An error has occurred. See error log for more details.
            No project name mapping was defined for project ':EM3SystemTest:AutomationWorkItems:EM3DataCreationSuite'
            Project key is: '/Data/Programming/sts-workspace/em3-parent-trunk/EM3SystemTest/AutomationWorkItems/EM3DataCreationSuite'
            The name map is: 
              '/Data/Programming/sts-workspace/em3-parent-trunk/EM3ServiceGateway/EM3ServiceGatewayTaxI'm definitely getting more infomnomyProject' => P/EM3ServiceGatewayTaxonomyProject
              '/Data/Programming/sts-workspace/em3-parent-trunk/EM3ServiceGateway/EM3SearchGatewayProject/EM3SearchREST' => P/EM3SearchREST
              '/Data/Programming/sts-workspace/em3-parent-trunk/EM3ServiceGateway/RACTEntitiesProject' => P/RACTEntitiesProject
              '/Data/Programming/sts-workspace/em3-parent-trunk/EM3ServiceGateway/EM3ServiceGatewayTaskProject/EM3TaskGateway' => P/EM3TaskGateway
              '/Data/Programming/sts-workspace/em3-parent-trunk/EM3ServiceGateway/EM3ServiceGatewayReferenceDataProject/EM3ReferenceDataREST' => P/EM3ReferenceDataREST
              '/Data/Programming/sts-workspace/em3-parent-trunk/EM3ServiceGateway/EM3ServiceGatewayStockProject/EM3StockGateway' => P/EM3StockGateway
              '/Data/Programming/sts-workspace/em3-parent-trunk/EM3ServiceGateway/EM3ServiceGatewayEntitiesProject/EM3EntitiesGateway' => P/EM3EntitiesGateway
              '/Data/Programming/sts-workspace/em3-parent-trunk/EM3ServiceGateway/EM3ServiceGatewayStorageProject/EM3StoragePersistence' => P/EM3StoragePersistence
              '/Data/Programming/sts-workspace/em3-parent-trunk/EM3ServiceGateway/EM3ServiceGatewayReferenceDataProject' => P/EM3ServiceGatewayReferenceDataProject
              '/Data/Programming/sts-workspace/em3-parent-trunk/EM3ServiceGateway/EM3ServiceGatewayTaskProject' => P/EM3ServiceGatewayTaskProject
              '/Data/Programming/sts-workspace/em3-parent-trunk/EM3ServiceGateway/EM3ServiceGatewayStockProject' => P/EM3ServiceGatewayStockProject
              '/Data/Programming/sts-workspace/em3-parent-trunk/EM3ServiceGateway' => P/EM3ServiceGateway
              '/Data/Programming/sts-workspace/em3-parent-trunk/EM3ServiceGateway/EM3ServiceGatewayStorageProject' => P/EM3ServiceGatewayStorageProject
              '/Data/Programming/sts-workspace/em3-parent-trunk/EM3ServiceGateway/EM3ServiceGatewayTaskProject/EM3TaskREST' => P/EM3TaskREST
              '/Data/Programming/sts-workspace/em3-parent-trunk/EM3ServiceGateway/EM3SearchGatewayProject/EM3SearchGateway' => P/EM3SearchGateway
              '/Data/Programming/sts-workspace/em3-parent-trunk/EM3ServiceGateway/EM3EntitiesPersistence' => P/EM3EntitiesPersistence
              '/Data/Programming/sts-workspace/em3-parent-trunk/EM3ServiceGateway/EM3ServiceGatewayUtil' => P/EM3ServiceGatewayUtil
              '/Data/Programming/sts-workspace/em3-parent-trunk/EM3ServiceGateway/EM3ServiceGatewayStorageProject/EM3StorageGateway' => P/EM3StorageGateway
              '/Data/Programming/sts-workspace/em3-parent-trunk/EM3ServiceGateway/RACTEntitiesProject/RACTEntitiesGateway' => P/RACTEntitiesGateway
              '/Data/Programming/sts-workspace/em3-parent-trunk/EM3ServiceGateway/EM3ServiceGatewayTSPMService' => P/EM3ServiceGatewayTSPMService
              '/Data/Programming/sts-workspace/em3-parent-trunk/EM3ServiceGateway/EM3ServiceGatewayStorageProject/EM3StorageREST' => P/EM3StorageREST
              '/Data/Programming/sts-workspace/em3-parent-trunk/EM3ServiceGateway/RACTEntitiesProject/RACTEntitiesPersistence' => P/RACTEntitiesPersistence
              '/Data/Programming/sts-workspace/em3-parent-trunk/EM3ServiceGateway/EM3ServiceGatewayStockProject/EM3StockREST' => P/EM3StockREST
              '/Data/Programming/sts-workspace/em3-parent-trunk/EM3ServiceGateway/EM3ServiceGatewayEntitiesProject' => P/EM3ServiceGatewayEntitiesProject
              '/Data/Programming/sts-workspace/em3-parent-trunk/EM3ServiceGateway/EM3ServiceGatewayEntitiesProject/EM3EntitiesREST' => P/EM3EntitiesREST
              '/Data/Programming/sts-workspace/em3-parent-trunk/EM3ServiceGateway/EM3ServiceGatewayTaxonomyProject/EM3TaxonomyREST' => P/EM3TaxonomyREST
              '/Data/Programming/sts-workspace/em3-parent-trunk/EM3ServiceGateway/EM3ServiceGatewayEntitiesProject/EM3AdminREST' => P/EM3AdminREST
              '/Data/Programming/sts-workspace/em3-parent-trunk/EM3ServiceGateway/EM3ServiceGatewayTaxonomyProject/EM3TaxonomyGateway' => P/EM3TaxonomyGateway
              '/Data/Programming/sts-workspace/em3-parent-trunk/EM3ServiceGateway/EM3SearchGatewayProject' => P/EM3SearchGatewayProject
              '/Data/Programming/sts-workspace/em3-parent-trunk/EM3ServiceGateway/MoragWSClient' => P/MoragWSClient
              '/Data/Programming/sts-workspace/em3-parent-trunk/EM3ServiceGateway/RACTEntitiesProject/RACTEntitiesREST' => P/RACTEntitiesREST
              '/Data/Programming/sts-workspace/em3-parent-trunk/EM3ServiceGateway/EM3ServiceGatewayReferenceDataProject/EM3ReferenceDataGateway' => P/EM3ReferenceDataGateway

            Does this shed any light on the source of the issue?

            Comment


            • #7
              Sorry, just discovered something more to add in the hope that it's relevant.

              It seems that the Map of project mappings only contains projects which exist within the project that I'm trying to import (i.e. sub-projects). However the map does not contain projects which are depended on by this project but which live outside of its project folder (as they are standalone projects).

              Say we have the following project layout

              Code:
              /rootfolder
                  settings.gradle (contains includes for :proj1, :proj1:subproj1 and :proj2)
                  build.gradle
                  /proj1 (Fails to import in STS due to its dependency on proj2, but if this dependency is removed it imports fine)
                      build.gradle (contains a dependency on proj2)
                      /subproj1 (this imports fine as it's under proj1)
                          build.gradle
                  /proj2
                  build.gradle

              If I try and import proj1 I get the error saying there is no mapping for proj2 (which is a standalone project hence is a sibling of proj1 rather than a submodule). Note that I get no such error for subproj1, presumably because it sits underneath proj1?

              If I then remove the dependency from proj1 to proj2 and try the import again the project imports successfully. Obviously it won't compile as it's now missing a required dependency but in terms of the error above it works fine.

              Realising this made me wonder if the problem might be solved by basing the content of the map on all projects declared in the utilised settings.properties?

              Hope I've explained that clearly enough, give me a shout if it doesn't make sense or if you need any further info.

              Comment


              • #8
                Ed, thanks. I think this definitely is getting us closer to figuring this out.

                Here's a tentative guess based on what you said.

                I take it you are pointing the gradle import wizard directly at project 'proj1' when you try to import it?
                Or are you pointing it at the rootfolder and then only selecting 'proj1'?

                If you are doing the former, can you try doing the latter and see if that works better.

                My guess is that gradle model build is confused / incomplete when you point it at a subproject of a multi-module build directly. If so, then you can avoid the problem by pointing it at the root folder instead. You can still select only one of the projects (although you will be forced to also select dependencies).

                It doesn't really make sense anyway to import just proj1 without proj2 (that it depends on) since you will get compilation errors due to missing dependencies if you would do that.

                Kris

                PS: the output wasn't *terribly* helpful. But I can see the project 'key' is missing. It does clarify that its not some funky upper-lower-case or other name mangling issue. The project isn't there at all not even in a somewhat mangled form (I guess that *is* useful info, as it helps us avoid making some incorrect assumptions / guesses :-)

                Comment


                • #9
                  I've raised this issue here: https://issuetracker.springsource.com/browse/STS-3456
                  I think there's enough info here to look into it further and see if there's a way to fix it.

                  Comment


                  • #10
                    Thanks Kris,

                    Your hunch was right, I was pointing the gradle import wizard directly at proj1 rather than at the root. When I tried your suggestion of pointing the import wizard at the root and then simply selecting 'proj1' the import wizard quite rightly told me that I also needed to import 'proj2'. I clicked on 'select required' and then 'finish' and everything imported correctly.

                    So for the time being that's definitely a good enough work-around for me, I feel rather daft for noth having thought of it myself! In this particular scenario 'proj2' is a library developed by a separate team so as far as I'm concerned it's immutable so I never thought to actually import the project itself.

                    Thanks again - if there's anything you need from me in contribution to the issue you raised just give me a shout.

                    Comment


                    • #11
                      > I feel rather daft ...

                      Not at all. The problem really is with the wizard. It would be rather impossible for you guess based on the
                      internal error message why it happens.

                      When I built it I assumed you'd point it at the root... so it broke with a unexpected and hard to understand 'internal' error.
                      This is really a problem with the wizard not checking its own assumptions.

                      I just committed a fix that detects this case now and opens the root project even if you point directly at a subproject.

                      Comment

                      Working...
                      X