Hey Kevin, see my answer to Xavier for how this will impact on non HE users (especially in a shared repo environment).
The fact that the HoloEverywhere project has 2196 stars and 794 forks indicates that it very widely used. That means that as a disease vector it is highly contagious. My point about Google publishing strategy is (to use the disease analogy again) that if Google were following the standard publishing mechanism and publishing it's artifacts in Maven central then we would be somewhat inoculated from this rogue vector because 1) Maven central is the first point of call when resolving dependencies. So you will get the official artifacts ahead of the HE artifacts. 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. 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. William On Fri, Aug 8, 2014 at 12:02 AM, Kevin Schultz <[email protected]> wrote: > William, > > That definitely seems like a major problem with HoloEverywhere and I > wouldn't use it. But is he actually publishing artifacts that impact > non-HoloEverywhere users? I'm not sure I understand the connection between > his misconfiguration & Google's publishing strategy? > > > On Thursday, August 7, 2014 7:41:31 AM UTC-4, William Ferguson wrote: >> >> What's the Android team's stance on the non-official versions of the >> Android support libraries? >> >> Eg https://github.com/Prototik/HoloEverywhere/issues/842#issuecomment- >> 49746122 >> >> These libraries have the same GAV (groupId, artifactId, version) as the >> official versions but have totally different contents. This means that the >> same project built on 2 different machines can produce radically different >> outputs (unbeknownst to the developers). Or even 2 libraries both listing >> the same dependency having very different needs and producing some >> nightmare when combined (again unbeknownst to the developer doing the >> combining). >> >> These libraries are being published in the com.android.* namespace, so >> appear to be official Android team libraries which means developers are >> going to start coming to you guys for support as things start to break down >> at the edges. If the Android team were actually publishing these artifacts >> into a public repository there wouldn't be a vacuum for incidents like this >> to occur. >> >> So what's the plan to stop this hole getting bigger and deeper? >> >> William >> >> >> >> -- > You received this message because you are subscribed to a topic in the > Google Groups "adt-dev" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/adt-dev/2hPuSUYttbg/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- 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.
