After playing some more with the Transform API I was able to use the AsInputTransform which is the preferred one. The only change I need is to have inputs as jars instead of extracted jars because of the case-sensitivity issue, and to be able to output a jar file (classes.jar) for each scope instead of a directory of classes (again for case-sensitivity). Btw today when creating an AsInputTransform, and returning in getOutputFormat() a Format.JAR - it seems the API ignores it, and still expects the output to be a directory of files.
Thanks, Ariel On Saturday, September 19, 2015 at 1:14:24 AM UTC+3, Ariel Cattan wrote: > > 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]> 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]. >>> 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.
