We would also be happy to get away from jars, but the case sensitivity issue imposes a limitation. When you say you can fix this issue - what do you plan to do? What other way is there other than keeping those jars as jars? Btw we have another limitation with a 3rd party tool we are using - it can process entire directories or jars, but it cannot accept single files spread across some directory tree. Therefore if, say, only com/a/b.class has changed, we can either reprocess the entire 'com' tree, or we should create a new empty tree, copy b.class into that tree, then reprocess the tree and copy the processed b.class back into the original tree, which is pretty cumbersome. I hope we manage to improve this in the future, but at the moment we are not fully "incremental" at the class level. Still we can be "partially incremental" if we are allowed to output multiple jars and directories.
On Friday, September 18, 2015 at 9:02:21 PM UTC+3, Xavier Ducrohet wrote: > > Actually one of the reason we want to get away from jars is for > incremental reasons (And also speed, why pack/unpack jars between > transforms when files work fine). There is the issue of case-sensitive > conflicts in obfuscated jars but we can fix that. > > The Transform API tell you which file changed (getting the information > from Gradle), all you need to do is just reprocess only this one (and > whatever else is impacted by this change) and that's it. It's a LOT easier, > and more efficient to deal with incremental transforms at the class level > than at the jar level. > > The reason we do unarchive all the jars is because of ProGuard. Giving it > a mix of jar and classes inputs with a folder output make it output a > similar mix of classes and jars instead of just jars, which is not what we > want. We may fix that in the future, but for now this is simpler (and a > small up-front cost in non-incremental builds only.) > > On Fri, Sep 18, 2015 at 6:01 AM, Ariel Cattan <[email protected] > <javascript:>> wrote: > >> Hi Xavier, >> >> I would like to output multiple jars for incremental builds. If our code >> identifies a change that affects only one of the jars - it can rebuild only >> that one. It will allow us to generate several jars per our internal logic >> and constrains with the tools we use. It it complex to allow that? >> >> Thanks, >> Ariel >> >> On Friday, September 18, 2015 at 4:31:01 AM UTC+3, Xavier Ducrohet wrote: >>> >>> Good point about the case sensitivity of the extracted classes. We'll >>> fix this. >>> >>> Why do you want to output into multiple jars? >>> >>> On Wed, Sep 16, 2015 at 8:47 AM, Ariel Cattan <[email protected]> wrote: >>> >>>> Hey guys, >>>> >>>> Apparently the new Transform API in Android Plugin 1.4.0-beta2 does not >>>> work well in Windows, as it extracts all jars into folders. However, some >>>> jars (especially SDKs which are obfuscated) come with class files that >>>> have >>>> case sensitive names, such as A.class and a.class in the same jar. >>>> Extracting these jars causes one file to overwrite the other. >>>> I would suggest to separately provide to the transform() method a list >>>> of jars (not extracted), and a list of folders for already extracted >>>> classes. >>>> >>>> In addition, and from similar reasons, I think the output of the >>>> transform() (in a CombinedTransform) should provide a folder name (not a >>>> jar name), and allow the output of multiple jars in that folder, as it's >>>> not always easy to manipulate existing jars on Windows (e.g. two jars >>>> cannot be extracted and recombined on Windows). >>>> >>>> Thanks! >>>> Ariel Cattan >>>> >>>> -- >>>> 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] <javascript:>. >> 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.
