On Thu, Aug 7, 2014 at 8:46 PM, William Ferguson < [email protected]> wrote:
> Do *you* have the official Android support artefacts in your corporate > repository? > No. > Are you sure? > Yes. > Did you personally check? For each and every version version of each > artefact? > I don't need to check. 1. They're in the SDK. The SDK's m2 repos are enabled by default in builds and can only be populated from the SDK manager. Safe. 2. Gradle doesn't use the local .m2 repo. Even if someone is dealing with a Maven project on the same machine, they don't share a local artifact cache. Safe. 3. They'll never be there since no artifacts exist at the same coordinates in central to populate them by on a cache miss. Google controls the groupId in which they would be deployed if they ever do show up. Safe. I fought the (losing) Maven battle for four years. I contributed to the maven-android-plugin. I contributed to the maven-android-sdk-deployer. I built the r7 support-v4 library artifact that is sitting in Maven central right now. I've published tens of libraries in apklib and jar format using Maven (and continue to do so). The right way forward is delegating to the SDK. Manfred even once said that this was what the plugin would do in the future. I'm surprised to learn it doesn't yet. I would welcome the artifacts in central. Until that time, the SDK is the canonical source of truth and should be respected as such. It is trivial to change the maven-android-plugin to support it as such and it would alleviate this concern completely and in a manner that is actually endorsed by Google. -- 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.
