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.

Reply via email to