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 < william.fergu...@xandar.com.au> 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 <x...@android.com> 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 < >> 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 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. > -- 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.
