There isn't a better way but we're doing a lot of work in dependency
management so we should improve this soon.
On Tue, Dec 30, 2014 at 1:17 PM, <jared.blunt...@usaa.com> wrote:
> I think I would prefer a strategy that uses the same-named build type, if
> it exists, else use the library's defaultPublishConfig... As is, we
> followed the mapping route (if I understand your post correctly), with
> type-specific dependencies in our app build.gradle. With our custom build
> type of preview, this is what we ended up with:
>
> dependencies {
> debugCompile project(path: ':myLib', configuration: 'debug')
> previewCompile project(path: ':myLib', configuration: 'preview')
> releaseCompile project(path: ':myLib', configuration: 'release')
>
> compile (
> 'com.foo:extLib1:1.0'
> 'com.bar:extLib2:1.0'
> )
>
> }
>
> Even with this, we had to set 'publishNonDefault true' in our library's
> build.gradle to make Studio happy, which causes any build of any type of
> our app to check on all build types of our library; most of the time,
> everything's up to date, but it seems unnecessary. Is there a better way?
>
>
>
> On Saturday, May 4, 2013 12:27:40 PM UTC-5, Xavier Ducrohet wrote:
>>
>> The library thing is normal. For now.
>>
>> For library project, "debug" and "release" are misnomer really (as I was
>> preparing my I/O talk, I really wanted to rename them for 0.4, but so far I
>> haven't)
>>
>> "debug" is used only for testing the library itself (so the test apk
>> inside the library project uses this), and "release" is used to package the
>> library for use by other projects (in a multi-project setup) or for upload
>> to a repository.
>>
>> I think once we add NDK support we're going to want to change this and
>> have possibly more than 2 built-in Build Types in Library Projects, but we
>> have to figure out exactly what it's going to look like.
>>
>> For instance, do we enforce that Library Projects have exactly matching
>> Build Types (in name) as the App Projects using them? This could become
>> overly complex every time you add a new build type to your app, as you'd
>> need to update all the Library Projects.
>>
>> Or we could have some mapping in the App project indicating (for each
>> Build Type of the app!) which Build Type to use (for each library!). This
>> could become unwieldy if you have many libraries (some developers have told
>> me they were using 10, 20 library projects!).
>>
>> Ideas welcome.
>>
>> I'll check the assemble->bundleRelease extra dependency on Monday.
>>
>> thanks
>> Xav
>>
>>
>> On Sat, May 4, 2013 at 9:22 AM, Szabolcs Berecz <szabolc...@gmail.com>
>> wrote:
>>
>>> Hi!
>>>
>>> I just noticed that assembleDebug creates an apk which contains the
>>> release version of android-library projects, not the debug version. The
>>> debug versions are also compiled for these library projects but only after
>>> creating the apk, so there is no way to include the debug version of the
>>> libraries in the apk.
>>>
>>> Is this intentional? Or maybe my build scripts are broken?
>>>
>>> I created a graph of the dependencies between all the tasks in my build
>>> and this is what I see:
>>> - in an 'android' project, the prepareReleaseDependencies and the
>>> prepareDebugDependencies tasks depend on the same prepare*Library tasks
>>> which in turn depend on bundleRelease tasks
>>> - bundleDebug tasks are only depended on by assembleDebug which are only
>>> depended on by assemble. So, nothing uses the results of a debug build of
>>> an android-library project. Or if something uses it, it does not show in
>>> the task dependencies.
>>>
>>> I also noticed that there is an unnecessary dependency between assemble
>>> and bundleRelease. Assemble also depends on assembleRelease which depends
>>> on bundleRelease, therefore the assemble->bundleRelease dependency is
>>> unnecessary.
>>>
>>> I can minimize my build if that helps. Let me know if you need it.
>>>
>>> Thanks,
>>> Szabolcs
>>>
>>> --
>>> 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 adt-dev+u...@googlegroups.com.
>>> 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 adt-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
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 adt-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
