On Thu, Aug 7, 2014 at 4:45 PM, William Ferguson < [email protected]> wrote:
> Correct, but I never claimed they were. My point is that because their > artifacts are published to a publicly accessible web address their > artifacts are more accessible than those being provided by the Android team. > But not Maven central, therefore not a problem. A) Before you can consume any of the artefacts you need to start SDK > manager, choose the appropriate versions of the required artifacts and then > download them. > Every developer does this. You need the API level you are compiling against. This isn't a problem > B) You then need to take those artifacts and deploy them to your local (or > shared repo). > Not for Gradle nor Ant, therefore not a problem for Google to worry about. > Most developers don't use the SDK Manager to download the latest artifacts > on a daily basis, they do it at irregular intervals. This means that there > is a latency between when the artifacts become available and when the > developer first has access to the official artifacts. > I agree. I wrote a Gradle plugin to address this: https://github.com/JakeWharton/sdk-manager-plugin. I'd love for the first-party plugin to do this some day. Ant users copy jars so they don't matter. And Maven isn't supported so it's not Google's concern. That gap provides an opportunity for the developers local/shared repo to > become polluted with non-official artifacts (potentially without the > developer becoming aware of it). > No, because nobody is publishing these artifacts to central. > As an aside this also means that you can't just fork an Android project > and build and expect to be able to build it because the Android > dependencies that it relies upon may not yet have been downloaded to your > repo. This is a real pain for open source an example projects. > See above plugin. > Yes, but com.google.android has been dormant since August 2012 aside for 2 > example apps. And nature abhors a vacuum to quote Aristotle. > Because those artifacts weren't sanctioned. In fact, they should be removed. > If you are telling me that the support libraries can provide the Holo look > and feel without need for HE that's great and I can ditch it from any of my > projects that rely on it *directly*. > AppCompat. Again, HoloEverywhere and Maven are not Google's concern. > This is not true. Any Gradle build or Ant build using dep management is at > risk of this even if they haven't used HoloEverywhere directly themselves. > Neither uses the local .m2 so no they aren't! -- 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.
