Would it be fair to reopen this discussion now that .aar libraries are 
becoming more popular?

I have a situation where I am building a library with 2 flavors that have 
the same functionality, but differ in how they do their REST communication. 
 This has lead to a couple classes that differ.  It seems to make very good 
sense for these to be 2 flavors.  I could be wrong, but that's for another 
thread.

Currently, I am struggling with how to distribute these separate flavors. 
 Should they be different artifacts?  Classifiers?  I've been searching for 
days and finally found this thread which seems fairly appropriate? 
 Thoughts?  Advice?  Thanks.

- Kevin

On Wednesday, October 24, 2012 6:46:31 PM UTC-4, Manfred Moser wrote:
>
> You can put any arbitrary property into the pom. E.g. we put branch 
> and commit number into the pom for lint when I deployed the r16 sdk 
> artifacts.. 
>
> See 
> http://search.maven.org/#artifactdetails%7Ccom.android.tools.lint%7Clint%7Cr16%7Cjar
>  
> which uses 
> <properties> 
>         <branch>ics-mr0</branch> 
>         <commit>fa8fa3cb242095a83542292da9a17881b664e92a</commit> 
> </properties> 
>
> hth 
>
> manfred 
>
>
> On Wed, Oct 24, 2012 at 3:35 PM, Xavier Ducrohet <[email protected] 
> <javascript:>> wrote: 
> > My only point was that there's no dependency here, but we can make it 
> work, 
> > that's not a big deal. 
> > 
> > Is there a way to put build information in the POM? Like the git sha1 
> that 
> > was built? (or more than one if you use multiple git projects?) 
> > 
> > The version that is used for Maven deployment is just a project property 
> so 
> > you can actually build is manually from whatever info you want. You 
> could 
> > put the git sha1 in there if you wanted. 
> > 
> > But we need to intercept this ourselves so that you can have one per 
> > artifact in the case we are generating more than one. 
> > 
> > 
> > On Wed, Oct 24, 2012 at 3:07 PM, Manfred Moser <[email protected] 
> <javascript:>> wrote: 
> >> 
> >> On Wed, Oct 24, 2012 at 2:53 PM, Xavier Ducrohet <[email protected] 
> <javascript:>> wrote: 
> >> > I think it's perfectly fine to deploy the build result somewhere. I'm 
> >> > just 
> >> > not sure a Maven repository is best for non-Jar output, but I'm sure 
> we 
> >> > can 
> >> > make it work. 
> >> 
> >> Maven repositories just define the coordinates used 
> >> group id, artifact id and version for directory 
> >> artifactid-version-classifier.packaging for the file names 
> >> 
> >> and contain the dependencies declared in a pom.xml format with the 
> >> file named artifactid-version.pom 
> >> 
> >> But they are completely agnostic to what the file is and in fact are 
> >> used for all sorts of stuff including jar, war, ear, apk, apklib, zip, 
> >> tar.gz, osgi bundles and so on and so on. 
> >> 
> >> it is a widely understood format and with repo server like Nexus 
> >> providing a REST API as well as allowing wget/curl access are very 
> >> easy to integrate. 
> >> 
> >> 
> >> > We might need special packaging for the case where an app is made of 
> >> > several 
> >> > APKs. 
> >> 
> >> maybe and apb (android package bundle ;-) 
> >> 
> >> > I think the coordinate should include the app package name for 
> groupId, 
> >> > and 
> >> > the version code (not the versionName) combined with a build number 
> >> > (date 
> >> > would be fine. Maybe "<version-code>-yyyymmdd-hhmm". Not sure about 
> the 
> >> > artifactId. 
> >> 
> >> Or you could do versioncode-versionname. I am not sure how versioning 
> >> schemes work in Gradle and how or if they can be automated. 
> >> 
> >> And artifact id should probably be the identifier for the project or 
> >> something .. however that is done in gradle. 
> >> 
> >> > We could make it configurable of course. 
> >> 
> >> That would be good. 
> >> 
> >> manfred 
> > 
> > 
> > 
> > 
> > -- 
> > Xavier Ducrohet 
> > Android SDK Tech Lead 
> > Google Inc. 
> > http://developer.android.com | http://tools.android.com 
> > 
> > Please do not send me questions directly. Thanks! 
>

-- 
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.

Reply via email to