Hi Xavier, Yes, I agree this is a more complex use case. The way we do it today is by running our transform as a task after the java compile task. We analyze the entire code including all dependencies, and identify which jars or classes are of interest to us. We then process them and the rest we leave untouched. After that, we manipulate the inputs of various tasks - the pre-dex task, the dex task, the jar-merging task so that they take our new processed jars where relevant. The problem with our current approach is that it's very much dependent on the internal implementation of your plugin, and in fact 1.4.0-beta2 it broke our code... The Transform API is a great feature for us, it will allow us to use official APIs. However I'm still looking for ways to make sure we don't increase build times significantly, and that's why I was looking for a way to tell your plugin which jars we need to process and which we don't.
Thanks, Ariel On Friday, September 18, 2015 at 4:00:10 AM UTC+3, Xavier Ducrohet wrote: > > I'm curious, how do you go around this problem right now? > > TBH this is not something we're going to be able to fix in 1.4, as it > seems beyond the scope of this API. It's also a very narrow use case. > > This would probably need some sort of fork scope transform (similar to the > forkTransform though this one fork on type, not scope), and this is not > really planned for now and is more complicated (this would require the > ability to create new scopes for instance). > > On Wed, Sep 16, 2015 at 5:21 AM, Ariel Cattan <[email protected] > <javascript:>> wrote: > >> Hi guys, >> >> I started evaluating the new Transform API in Android Gradle Plugin >> 1.4.0-beta2, and I'm seeing a limitation which I wanted to consult with you >> about: >> >> We at SafeDK are performing transformation on SDKs, as well as on the >> project's classes. For this we provide our Gradle plugin which developers >> need to use. Since SDKs could be anywhere (in the project lib, in source >> code, in external projects or external libs), we need to request a >> transform on all "scopes". Moreover, for other reasons, we need to output a >> single jar containing all SDKs. >> Therefore, as far as I could understand the new API, I need to use a >> CombinedTransform. >> However, using a CombinedTransform has quite a few downsides: >> >> 1. We will need to process jar files which normally we have no interest >> in (not all jars we consider as "SDKs") >> 2. We lose pre-dex capabilities, which would normally be done on all jars >> which are not SDKs. >> 3. Other plugins requesting transforms may request a limited scope, in >> which case they will fail. >> >> It would be great if there was an option in the API to return a list of >> jars and folders which are of interest to us, and the rest keep in the >> normal flow. Something like a "preTransform" method allowing us to evaluate >> the inputs and return a list of jars and folders which we are going to >> perform the transform on. >> >> Please let me know what you think, and whether there's a better way to >> achieve what I'm trying to do. >> >> 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] <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.
