How to exclude libs provided inside of aar dependency?

[Vyacheslav Blinov]

Hi! I have a library, which has libs/android-support-v4.jar inside of its aar, as one of my dependency, and obviously proguard and dex both will not let that happen that duplicated class appear in my build. How can I exclude such bundled library from dependency aar? Standard exclude does not helps (and if you think about it it shouldn't because that lib is not added as an explicit transitive dependency with explicit descriptor).

[Jake Wharton]

Why are you using the jar instead of declaring a normal dependency on the support library?

On Fri Nov 28 2014 at 8:05:26 AM Vyacheslav Blinov <blinov.v...@gmail.com> wrote:

Hi! I have a library, which has libs/android-support-v4.jar inside of its aar, as one of my dependency, and obviously proguard and dex both will not let that happen that duplicated class appear in my build. How can I exclude such bundled library from dependency aar? Standard exclude does not helps (and if you think about it it shouldn't because that lib is not added as an explicit transitive dependency with explicit descriptor).

--
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/d/optout.

[Vyacheslav Blinov]

1. It's not me who doing that, but some external library (I don't think it's important which project it is), that was just published.
2. Why is that criminal given that aar format supports that? Given it lies in design of aar there were about to be some kind of support for that situation. I suppose many people just migrated their ant builds blindly like that. If it is something unsupported why make aar support that?

суббота, 29 ноября 2014 г., 5:12:03 UTC+3 пользователь Jake Wharton написал:

[John Frey]

It's been a long standing issue it seems... https://groups.google.com/forum/#!topic/adt-dev/l1gELhPSSkM

[Tom Billiet]

I believe this is what you're looking for. Eg for actionbarsherlock:

//actionbarsherlock
compile ('com.actionbarsherlock:actionbarsherlock:4.4.0@aar') {
    transitive = true
    exclude (group: "com.google.android") //conflicts with support-v4 from gradle
}


Op zondag 30 november 2014 03:34:06 UTC+1 schreef John Frey:

[Vyacheslav Blinov]

Unfortunately this was my first try and it does not helps. I can’t see this library in dependency tree as well so I believe it can’t be excluded this way.

Regards,
Vyacheslav Blinov
https://github.com/dant3

[Xavier Ducrohet]

It's not possible at the moment to ignore a dependency that's in the libs/ folder of an aar.

The publisher of that library should not have done this. I'd contact them and ask them to publish it properly. If it's open source, you can do it yourself if needed.

Xavier Ducrohet
Android SDK Tech Lead
Google Inc.
http://developer.android.com | http://tools.android.com

Please do not send me questions directly. Thanks!

[William Ferguson]

Xavier I 100% agree.

Can we expect the same behaviour from the AARs that ship as part of the Android SDK?

William

[Xavier Ducrohet]

By "should not have done this", I meant "should not have included support-v4 in its libs folder".

Including your own jar files in libs/ is fine, but it should be considered internal implementation that's hidden from the developer. It should never be an existing published artifact.

[William Ferguson]

Bit if they are internal implementation of the AAR then why not include them in classes.jar?

ᐧ

--
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+u...@googlegroups.com.

[Vyacheslav Blinov]

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?

вторник, 2 декабря 2014 г., 22:22:53 UTC+3 пользователь Xavier Ducrohet написал:

[Mark Murphy]

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!

[Xavier Ducrohet]

What Mark said.

--
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/d/optout.

[William Ferguson]

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

ᐧ

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+u...@googlegroups.com.

[Xavier Ducrohet]

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.

[William Ferguson]

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.

ᐧ

[Avram Lyon]

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

[William Ferguson]

@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.

ᐧ