So 0.9.0 version remains the API unchanged. What about upcoming AS 0.5.0?
Can we expect the API support?
On Monday, 17 February 2014 18:03:48 UTC+2, Brian Parent wrote:
>
> Is this supported by Android Studio yet? I couldn't find anything in the
> release notes about it for .0.4.1+
>
> The lack of unit test support in the IDE is really the only thing
> stopping us from moving over. I think this could bridge that gap for us in
> the interim.
>
> On Wednesday, January 29, 2014 4:41:17 AM UTC-6, Roman Mazur wrote:
>>
>> Ah, and last question :)
>> Is support of this model in Studio implemented in 0.4.3 or only planned?
>> I see that model builder invoked by Studio accesses registered provider
>> since the mentioned exception is not thrown when I run gradle from cmd
>> line, but within Studio only.
>>
>> Caused by: java.lang.IllegalAccessError: Shouldn't access manifest from
>> SourceSetSourceProviderWrapper
>> at
>> com.android.build.gradle.internal.SourceSetSourceProviderWrapper.getManifestFile(SourceSetSourceProviderWrapper.java:45)
>> at
>> com.android.build.gradle.internal.model.SourceProviderImpl.cloneProvider(SourceProviderImpl.java:48)
>> at
>> com.android.build.gradle.internal.model.JavaArtifactImpl.clone(JavaArtifactImpl.java:38)
>> at
>> com.android.build.gradle.internal.model.JavaArtifactImpl$clone.call(Unknown
>> Source)
>> at
>> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:42)
>> at
>> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:108)
>> at
>> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:116)
>> at
>> com.android.build.gradle.internal.model.ModelBuilder.createVariant(ModelBuilder.groovy:200)
>>
>> However, after replacing wrapper with a custom provider which does not
>> fail I do not see any affect on iml files.
>> So what are the plans regarding studio support?
>>
>> On Wednesday, 29 January 2014 11:21:33 UTC+2, Roman Mazur wrote:
>>>
>>> As for artifact type name
>>> >The name is a unique name, and will show up in the UI.
>>> Where exactly this name is expected to appear?
>>>
>>> Also wrapping standard sourceSet with wrapJavaSourceSet does not work,
>>> it throws
>>> IllegalAccessError("Shouldn't access manifest from
>>> SourceSetSourceProviderWrapper").
>>>
>>> When using registerProductFlavor/BuildTypeSourceProvider, should I add
>>> default sources directory to each provider?
>>>
>>> I mean having a structure like
>>> src/something/java
>>> src/somethingDebug/java
>>> src/somethingRelease/java
>>>
>>> and using registerBuildTypeSourceProvider for both debug and release,
>>> how src/something/java is supposed to be known to the IDE?
>>> Should build type source provider return this directory in
>>> getJavaDirectories
>>> as well as the specific build type directory?
>>>
>>> On Thursday, 9 January 2014 18:39:32 UTC+2, Xavier Ducrohet wrote:
>>>>
>>>> No update. I realize that I had forgotten to file a bug for it, so here
>>>> it is: https://code.google.com/p/android/issues/detail?id=64635
>>>>
>>>>
>>>> On Thu, Jan 9, 2014 at 5:54 AM, Roman Mazur <[email protected]> wrote:
>>>>
>>>>> How is it going with dependencies information?
>>>>> Can we expect them in the nearest releases?
>>>>>
>>>>>
>>>>> On Thursday, 19 December 2013 23:51:54 UTC+2, Xavier Ducrohet wrote:
>>>>>>
>>>>>> Sorry for the lack of documentation in this area. Things are also
>>>>>> very much subject to changes based on feedback.
>>>>>>
>>>>>> First of all you need to understand that this API is only about
>>>>>> updating the model that the IDE sees. It has no impact on the generated
>>>>>> APK.
>>>>>>
>>>>>> the idea is to do the following:
>>>>>> - register a new type of artifact
>>>>>> - for each variant, register a new artifact of this type, with source
>>>>>> sets, and associated task.
>>>>>> Then Studio (not 0.4 yet, but hopefully 0.4.1) will allow you to
>>>>>> switch between the existing artifacts (main, instrumentTest) and the new
>>>>>> one.
>>>>>>
>>>>>> Let's look at the API.
>>>>>>
>>>>>> First to register the artifact:
>>>>>>
>>>>>> void registerArtifactType(@NonNull String name, boolean isTest, int
>>>>>> artifactType);
>>>>>>
>>>>>> The name is a unique name, and will show up in the UI. For your
>>>>>> example "robolectric" is fine.
>>>>>> if isTest is true then the source folders of the artifact will setup
>>>>>> as test source folder, extending the main artifact source folders. If
>>>>>> false, they'll replace the main artifact as "main" source folders.
>>>>>> the artifact type is Java or Android (only Java supported now), so
>>>>>> use com.android.builder.model.ArtifactMetaData.TYPE_JAVA
>>>>>>
>>>>>> Then you register source folders.Look at the sample.
>>>>>>
>>>>>> You can register folders specific to build types and flavors, but
>>>>>> strangely not a common one (usually src/test). This is stupid! more on
>>>>>> this
>>>>>> later.
>>>>>>
>>>>>> Then you add an actual artifact. You need to associate it with a
>>>>>> variant. The source folder associated earlier are automatically
>>>>>> associated
>>>>>> with variants that use those build types or flavors.
>>>>>> When registering an artifact you can also specify a variant-specific
>>>>>> source folder.
>>>>>>
>>>>>> public void registerJavaArtifact(
>>>>>> @NonNull String name,
>>>>>> @NonNull BaseVariant variant,
>>>>>> @NonNull String assembleTaskName,
>>>>>> @NonNull String javaCompileTaskName,
>>>>>> @NonNull File classesFolder,
>>>>>> @Nullable SourceProvider sourceProvider);
>>>>>>
>>>>>>
>>>>>> When I designed this I looked at Jake Wharton's robolectric plugin
>>>>>> (there are too many different robolectric plugins out there! </rant>),
>>>>>> and
>>>>>> realized that he's creating a single source folders with multiple path
>>>>>> (src/test/java, src/debugTest/java, etc...), so in this case you'd use
>>>>>> this
>>>>>> source folder as the variant specific one.
>>>>>> Note that the build type/flavor specific folders can't really be used
>>>>>> now because Gradle doesn't like combining multiple source sets into a
>>>>>> single binary yet (they are working on fixing this which will allow us
>>>>>> to
>>>>>> start using their default source sets instead of custom ones).
>>>>>>
>>>>>> Your comment about the SourceProvider is expected. We need this to be
>>>>>> generic Java/Android so it contains everything. If you use a default
>>>>>> Gradle
>>>>>> sourceSet you can use android.wrapJavaSourceSet(theSourceSet) to get
>>>>>> a SourceProvider from a java source set.
>>>>>>
>>>>>> Stupidly (again), the dependency information is missing. I'll add
>>>>>> this shortly. Note that again you can't really use this before Studio is
>>>>>> updated to use this new model. I wanted to get this out of the door to
>>>>>> get
>>>>>> feedback. I intend to rev quickly to address issues.
>>>>>>
>>>>>> hope this helps.
>>>>>> Xav
>>>>>>
>>>>>> --
>>>>> 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/groups/opt_out.
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Xavier Ducrohet
>>>> Android SDK Tech Lead
>>>> Google Inc.
>>>> http://developer.android.com | http://tools.android.com
>>>>
>>>> Please do not send me questions directly. Thanks!
>>>>
>>>
--
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/groups/opt_out.
