It's hard to change the behavior of tasks after they are setup. I'm looking at a few things right now and we may be able to handle them as jars. I think for third-party dependencies, we should be able to keep them as jars since it's unlikely a single entry in the jar would be updated. It's fine if you have a less incremental build when you update your dependencies.
On Tue, Sep 22, 2015 at 1:47 PM, Ariel Cattan <[email protected]> wrote: > By "damaging jars" i meant extracting jars that cannot be extracted in a > case-sensitive file system. Btw, we also ran into cases where jars could > not be extracted in Windows due to too long file names (happens with > Facebook jars). > If you plan to make sure this is checked before or during extraction then > this is great. So in that case - couldn't the process be fully automatic? > I.e. try to extract jars and if it fails - not extract them? > The reason i'm hesitant on the idea of generating an error message to the > user is because i'm seeing a scenario where users add our plugin (which > registers a transform on a case-sensitive jar), and as a result of that > suddenly their build fails. They may automatically blame our plugin for > that error and remove it. > Do you see what i mean? > Thanks, > Ariel > > -- > 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.
