Re: problem with AAR dependency

Well, at the moment it's the Android SDK team, but in the future it could be anybody. I look at the deployed POMs are as form of contract between the deployed artifact and it's consumers. So when the contract isn't explicit (eg dependency type info) then its open to misinterpretation. Maven conve

Re: problem with AAR dependency

On Jan 20, 2015, at 6:03 PM, William Ferguson wrote: > Been thinking about this a little more. > > The TLDR version: I am suggesting that we provide more information and > place a stricter syntax requirement of the POM *generated* by the build. > This allows the generated POM to be a clear con

Re: problem with AAR dependency

Been thinking about this a little more. The TLDR version: I am suggesting that we provide more information and place a stricter syntax requirement of the POM *generated* by the build. This allows the generated POM to be a clear contract between the deployed artifact and it's consumers, regardless

Re: problem with AAR dependency

It's not the repository layout that Google is not honouring. It's the semantics of the unspecified dependency type in the POMs in that repository. If the POM syntax were changed to require that deps had a type then Maven itself could fail the build because it could determine that the inputs were in

Re: problem with AAR dependency

On 2014-12-19, 17:40, William Ferguson wrote: I'd love to go the first route, but unfortunately Google is only making the Android libraries available via a repository that is downloaded (and updated) via the Android SDK. So they are not visible on Maven Central and Maven Central obviously couldn'

Re: problem with AAR dependency

I'd love to go the first route, but unfortunately Google is only making the Android libraries available via a repository that is downloaded (and updated) via the Android SDK. So they are not visible on Maven Central and Maven Central obviously couldn't vet them. The second option would work, but I

Re: problem with AAR dependency

Ok, I understand the problem now, but I don't think forcing everything to explicitly state dependency type is the right solution here. "Convention over configuration" is one of fundamental Maven principals, and by convention dependencies are assumed to have type=jar. I see two possible ways to im

Re: problem with AAR dependency

4306.html"http://www.wrox.com/ > > Kindle Version: HYPERLINK > "http://www.amazon.com/Professional-Oracle-WebLogic-Server-ebook/dp/B004HD69J2/"http://www.amazon.com/ > >   > >   > > From: William Ferguson [mailto:william.fergu...@xandar.com.au] > Sent: S

Re: problem with AAR dependency

Sorry Igor, I see now I omitted a chunk of context. The reason for the error is that this component : com.android.support support-v13 21.0.2 aar has a dependency upon com.android.support support-v4 21.0.2

RE: problem with AAR dependency

William Ferguson [mailto:william.fergu...@xandar.com.au] Sent: Sunday, December 07, 2014 6:25 PM To: maven-android-develop...@googlegroups.com Cc: Maven Developers List Subject: Re: problem with AAR dependency   ## Cross posting to Maven Dev list   One solution to this would be to change the

Re: problem with AAR dependency

I am not sure I follow. Can you explain what actually happens and how forcing element for all projects dependencies is expected to help the problem? -- Regards, Igor On 2014-12-07, 19:25, William Ferguson wrote: ## Cross posting to Maven Dev list One solution to this would be to change the PO

Re: problem with AAR dependency

## Cross posting to Maven Dev list One solution to this would be to change the POM specification to require the type element for dependencies. That would allow Maven and MavenCentral to immediately fail POMs based upon dependencies that are missing the type element. Yes, it goes against convent