On Fri, Aug 8, 2014 at 7:47 AM, Jake Wharton <[email protected]> wrote:
> On Thu, Aug 7, 2014 at 2:20 PM, William Ferguson < > [email protected]> wrote: >> >> 1) Maven central is the first point of call when resolving dependencies. >> So you will get the official artifacts ahead of the HE artifacts. >> > > This is not true. You can configure this behavior, but it's not Gradle's > default. > Correct, it is configurable. But it is by far the largest artifact repo and it is the default in Maven and the natural default for most projects using other dependency management mechanisms such as Ivy (via Ant for instance). > Moreover, HE isn't publishing these to Maven central because they do not > have the rights to this groupId. > 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. > > >> 2) Publishing in Maven central doesn't require manually downloading and >> deployment of each version of the Android artifacts for each developer. >> They become instantly available as soon as they are published by the >> Android team. So you remove attack via update latency. >> > > This makes no sense to me > OK, let me try and explain. This is really a follow up on my last point. The barriers that are imposed by the SDK Manager being the distribution point for Android artifacts are two fold 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. B) You then need to take those artifacts and deploy them to your local (or shared repo). 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. 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). 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. . > 3) Publishing the Android artifacts in central marks ownership of the >> namespace. It is less likely for someone to attempt to usurp that namespace >> elsewhere as users can see that the namespace is owned and being used. Ie >> its territory communication. >> > > Both com.google.* and com.android.* are already widely used groupIds by > Google for thousands of artifacts in central so this doesn't change > anything. > Yes, but com.google.android has been dormant since August 2012 aside for 2 example apps. And nature abhors a vacuum to quote Aristotle. > > What you are seeing is an old, legacy Maven project doing ugly hacks to > try and make things work. > 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*. It affects neither Gradle nor Ant builds which are the only supported > mechanisms of building Android apps. > 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. William -- 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.
