On Tue, Sep 22, 2015 at 3:07 AM, Ariel Cattan <[email protected]> wrote:
> Hi Xavier, > > I think it's fine to support both modes. However i'm concerned with > existing libraries that cannot be extracted due to case sensitivity, and a > global flag can damage these jars. I'm not sure what you mean by damage them? > Moreover developers may not be aware of that flag and won't understand why > their build fails. This would be handled automatically. We can detect during extraction that there are conflicting class filenames and output a proper error message indicating how to fix this (and this would happen only on File system without case sensitivity) > If i may, i would suggest to go by the origin, i.e. if a library comes as > a jar, leave it as a jar, and have the transformation generate its output > as a jar. If the origin are class files (like in the Project itself), then > leave extracted. This way 3rd party jars will not get damaged, and we will > also provide good support for incremental builds, which usually involve > only changing of class files in the Project. > What do you think? > There are a few problems. Even though a library may come as a jar, a transform could touch only a subset of it. If you have another transform behind that also touches only a few classes, then you really want to deal with class files in order to have proper incremental support. Worse, if a transform manipulates class files and you get a modified jar files where the only changed file inside is a non-class file, you really want to handle this. Yes, transform could do this themselves, but it's cumbersome. There's also the cost of compressing/extracting the content at every step. It just doesn't make a lot of sense. We did intend to do this originally though, until we realize that proguard really doesn't like this if you are trying to have a folder output (which is important if you want to do some pre-dexing behind proguard (when doing shrinking only). > -- > 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 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.
