I managed to figure out what was causing this in our build.
We had a method in settings.gradle to create projects and remap them.
Projects that were set up using this method worked fine on command line but
Android Studio could not handle it.
Method was:
def setup(String projectName, String path)
and essentially just did:
include (projectName)
project(":$projectName").projectDir = new File(settingsDir, path)
That was enough to confuse IDEA on import. When I unwrapped all of the
invocations it was able to import the projects correctly.
On Tuesday, July 29, 2014 12:17:12 PM UTC-7, Benjamin Cooley wrote:
>
> Command line builds have been running fine (for a long time now).
>
> We have modules are imported without updating the path and some (a
> majority) that update the path. Lets call them regular and repathed
> projects. When trying to import, the regular projects are listed in Project
> Structure as modules and the repathed ones are not. The classes in the
> repathed projects are shown as missing (red highlighting on the class) when
> you look at classes in the regular projects that depend on them. Since this
> indicates that the classes can't be found, I'm assuming that all related
> functionality is similarly impacted, I can test if needed.
>
> Under "Gradle Sync" warnings I get a lot of "A top-level dependencies
> block should only appear in build files that correspond to a module", also
> somewhat expected. At the bottom there is a "Failed to set up dependencies"
> on one of the repathed projects with "Unable to find Module". It only shows
> one of the repathed projects here, I'm assuming because that error stops
> execution/parsing of the rest...
>
> Also to note: We do have both Java and Android projects in the same build.
> I don't know if that matters.
>
> - Ben
>
> On Tuesday, July 29, 2014 11:31:07 AM UTC-7, sbarta wrote:
>>
>> In general, we support path remapping in the settings.gradle file. If
>> there are bugs in there, we should definitely fix them. There are a few
>> different areas that touch on this, so it would be good to have more
>> details.
>>
>> Do the problems reproduce from command-line builds or is it only in
>> Android Studio? That tells us if it's a problem with the Gradle plugin or
>> if it's Studio-specific?
>>
>> Does it affect project import and the ability to navigate the project?
>> Does it cause problems with syntax highlighting, error underlining, code
>> navigation, refactoring, that sort of thing?
>>
>> Does it cause problems with the Project Structure dialog?
>>
>> If you can answer those three categories of questions and file detailed
>> bug reports (including full error messages and output from builds) with
>> simple reproducible test cases, it would help us a lot. I know it's kind of
>> a pain to put together a test project for this sort of thing and write up a
>> comprehensive bug report, but if you can do it, it's really helpful.
>>
>> Thanks!
>>
>>
>> On Tue, Jul 29, 2014 at 11:10 AM, Benjamin Cooley <[email protected]>
>> wrote:
>>
>>> A while back (a few versions ago), we had an issue with projects with
>>> the same name (last value in the path). I asked on the gradle forum and
>>> they don't have any restriction for unique name. To get around it we did
>>> the project renaming trick
>>>
>>> include "someUniqueName"
>>> project(":someUniqueName").path = path/with/nonunique/name
>>>
>>> This worked for a time, but recently I wanted to try out android studio
>>> and apparently android studio doesn't play nice with moved paths :/
>>>
>>> So i tried setting them back to standard includes, with the non-unique
>>> names. This ended up with a project that depended on a library with the
>>> same name, and we get the "depends on libraries but is not a library" error
>>>
>>> An example of a project structure that would run into this:
>>> libraries/feature1/android
>>> libraries/feature2/android
>>> apps/simpleApp/android
>>>
>>> The errors print out what looks like <package>.<name> when identifying
>>> themselves instead of using the guaranteed unique path.
>>>
>>> My best guess at the moment is that the android plugin has a data
>>> structure somewhere which is keying off name (or <package>.<name>) instead
>>> of path....?
>>>
>>> Is having unique names (which maps out to unique project directories,
>>> wherever they appear in your folder hierarchy) an intended precondition for
>>> the android plugin?
>>>
>>> - Ben
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "adt-dev" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to [email protected].
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
--
You received this message because you are subscribed to the Google Groups
"adt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
