I've been thinking about the case sensitivity issue for a while, and I think we'll do this:
- default to use folders of classes. This is better for incremental support. - have a project wide setting for overriding this, pushing everything to use jars. As a developer of a transform, this means: - you won't choose whether to use Jar or folders, it's imposed on you. - you have to support both modes. thoughts? On Sun, Sep 20, 2015 at 11:54 PM, Ariel Cattan <[email protected]> wrote: > 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. > -- 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.
