The "libs" folder in the aar has never been about JNI libraries.
The problem with including the local/implementation jar inside the main
classes.jar is that it solves absolutely nothing.
Face it, some people want to use local jars. We allow them to use them, as
we are not in business to tell people how to organize their projects. We
offer a better alternative but if people have a bunch of jars they have to
use, they can use them.
After that it's up to them to figure out what works best for them. There's
only so much we can do.
On Wed, Dec 3, 2014 at 1:52 PM, William Ferguson <
william.fergu...@xandar.com.au> wrote:
> Where the community is finding problems is that as it stands now, the AAR
> format contains a "libs" folder that was originally used to ship internal
> ndk libs but is now being promoted and used to ship any old jar you want to
> lump into your AAR.
>
> See the recent comments/requests and issues raised on this list alone.
>
> That change in usage is a problem for consumers of the AAR as there is no
> meta-data for the contents of the libs folder. So a build tool that is
> including the AAR cannot discriminate and has to include all of the jars.
>
> Where this becomes a serious issue (as Mr Murphy points out) is when the
> AAR includes publicly available libraries in the libs folder. At that point
> the AAR will be in conflict with any APK or AAR that already contains some
> version of those libs either in their own libs folder, or more generally
> and appropriately as listed dependencies.
>
> Please don't encourage the inclusion of jars in the AAR libs folder. If
> they are private libraries then their contents could readily be included in
> the classes jar that is already contained within every AAR. If they are
> public libs, then they should be included via dependency management so that
> the build tool can make appropriate decisions during consumption of the AAR.
>
> Dependency management is one of the tools that has pulled software
> development out of some of the mire that it was in 20 years ago. Please
> don't push us all back into that swamp.
>
> William
>
>
> ᐧ
>
> On Thu, Dec 4, 2014 at 3:34 AM, Xavier Ducrohet <x...@android.com> wrote:
>
>> What Mark said.
>>
>> On Wed, Dec 3, 2014 at 3:42 AM, Mark Murphy <mmur...@commonsware.com>
>> wrote:
>>
>>> On Wed, Dec 3, 2014, at 03:45, Vyacheslav Blinov wrote:
>>> > Thanks for the answer. Having this in mind I'm curious why then make
>>> > support of such thing as including jar inside of aar if this is not the
>>> > right thing to do. Just wonder why this was done at stage of desiging
>>> aar
>>> > format?
>>>
>>> There is nothing strictly wrong with having a JAR in an AAR. The problem
>>> is in having a *publicly-distributed* JAR in an AAR, where external
>>> developers might be independently depending upon the JAR, perhaps some
>>> other version of the JAR than is in the AAR.
>>>
>>> If I publish an AAR, and it made sense for me, with my code
>>> organization, to have some of the AAR's code in JARs within the AAR,
>>> that's perfectly fine... so long as those JARs are not available
>>> separately from the AAR. This is what Xav referred on on this thread as
>>> internal implementation. In this case, it should not matter to the
>>> consumer of the AAR where the code is coming from. To get to Mr.
>>> Ferguson's question ("if they are internal implementation of the AAR
>>> then why not include them in classes.jar?"), that does not matter,
>>> because it is the classes, not the JAR, that is what gets consumed.
>>>
>>> However, support-v4 and support-v13 are not part of some internal
>>> implementation of an AAR -- they are publicly-distributed JARs, and in
>>> particular are available as first-class artifacts in their own right.
>>> Packaging one of *those* in an AAR is bad form, for the very reasons
>>> this thread gets into. And, to return to Mr. Ferguson's question,
>>> whether classes like android.support.v4.view.ViewPager are in
>>> classes.jar or android-support-v4.jar will not affect consumers of the
>>> AAR containing those classes, as they will be equally screwed in either
>>> case.
>>>
>>> A simple (and simplistic) way to look at it is: everything inside an AAR
>>> that *you* publish should be *written by you*. The reality is more
>>> nuanced than that, of course, but IMHO it's not a bad basic rule of
>>> thumb.
>>>
>>> --
>>> Mark Murphy (a Commons Guy)
>>> http://commonsware.com | http://github.com/commonsguy
>>> http://commonsware.com/blog | http://twitter.com/commonsguy
>>>
>>> _The Busy Coder's Guide to Android Development_ Version 6.2: Lollipop!
>>>
>>> --
>>> 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 a topic in the
>> Google Groups "adt-dev" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/adt-dev/g1AiJM7PeVs/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> adt-dev+unsubscr...@googlegroups.com.
>> 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 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.
