@Avram but we are no longer talking about AAR dependencies. Once they are packaged within the AAR they are actually part of the AAR and can't be excised without hacking. When they are no longer defined using dependency management you can't just exclude them.
And you may not be able to exclude that same dependency defined elsewhere in your build because 1) Either it has been included using the same mechanism 2) It requires a more recent version of the jar And yes, you are correct about uberjars. That's why they are so painful to work with and are best avoided. Shouldn't we try to stop another beast being unleashed on the world? The crux of the issue is that an AAR is an atomic build input like other dependencies. If it is being constructed correctly then you shouldn't have to crack it open and extract some but not all parts just to build your project successfully. But the direction/impetus from the Android build tools seems to be that this isn't a problem because no-one builds anything other than a trivial Android app that never runs into this issue. But that is clearly untrue. ᐧ On Thu, Dec 4, 2014 at 10:06 AM, Avram Lyon <[email protected]> wrote: > It is possible to make your buildscript re-pack misconfigured AAR > dependencies to exclude the errant JARs. That should be a perfectly > workable solution for those of us who encounter broken AARs. Same thing can > happen with misbuilt JARs that include non-shadowed dependencies > ("uberjars") if those get any distribution. > > *Avram Lyon* > Android wrangler | Scopely, Inc. > > Refer The Smartest Person You Know And Pocket $7,000! > *Learn more: scopely.com/referrals > <http://www.scopely.com/referrals/?page=4>* > > On Wed, Dec 3, 2014 at 2:51 PM, William Ferguson < > [email protected]> wrote: > >> I think you are missing the point. >> >> If the generated AAR is entirely for in house consumption then I totally >> agree with you. But as soon as the AAR is made available publicly then it >> pushes that problem onto all consumers of it. And let's face it, AARs are >> libraries that are publicly shared. >> >> > we are not in business to tell people how to organize their projects >> >> By specifying the AAR format you are. Choice in AAR structure and >> semantic, enable or limit what can/can't be done with an AAR and how >> effectively. >> >> Keeping local implementation contained within classes jar ensures there >> is a clear semantic on the responsibilities of classes jar, and removes >> potential conflict from the libs folder. >> >> A simple example: >> classes.jar >> libs/libraryA.jar >> >> A consumer of that AAR has to includes classes from both jars because >> there is no information to decide otherwise. The best an AAR consumer can >> do is to warn users that libraryA is an unknown dependency that is being >> explicitly included from AAR\libs which is what the android-maven-plugin >> does. >> >> If libraryA is a publicly available dependency then >> 1) the APK construction will mysteriously fail if that dep is used >> elsewhere within the APK project. >> 2) the dependency on libraryA is not visible to the end user constructing >> the APK unless they crack open each and every AAR to inspect the libs >> folder AND can determine that libs/libraryA is the cause of the fault. >> >> If libraryA was actually an internal library then it contents could be >> included within classes jar. In which case the AAR consumer can infer that >> the AAR only contains internal classes. >> >> So including the local/implementation jar inside the main classes.jar >> does provide a solution to this issue. >> >> >> >> ᐧ >> >> On Thu, Dec 4, 2014 at 8:05 AM, Xavier Ducrohet <[email protected]> wrote: >> >>> 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 < >>> [email protected]> 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 <[email protected]> >>>> wrote: >>>> >>>>> What Mark said. >>>>> >>>>> On Wed, Dec 3, 2014 at 3:42 AM, Mark Murphy <[email protected]> >>>>> 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 [email protected]. >>>>>> 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 >>>>> [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. >>>> >>> >>> >>> >>> -- >>> 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 >>> [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. >> > > -- > 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 > [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.
