--
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 adt-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
On Wed, Jun 5, 2013 at 12:27 PM, Manfred Moser <mos...@gmail.com> wrote:This presumes the existence of a team. Is being the member of a team a
> If you really insist on a cludge you can install the aar into a local
> repository (either a gradle/ivy one or the maven one and declare it to be
> used) but that way it only work for you only on your machine and not for
> everybody on your team so you force everyone to build everything..
requirement for Android development?
Install a repository manager like Sonatype Nexus in your network or on a hosted VM and deploy to it.
--
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 adt-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
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 adt-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
local aar are not yet supported. I want to add support for it (it's fairly trivial) but I want to figure out the impact of it.Having a local aar means that this aar cannot have any other dependencies besides local jar. This is because, unlike jars, the order of the aar dependency is important.Let's imagine if you have lib1 and lib2 with a project dependency that is app -> lib1 -> lib2.Publishing lib1 and lib2 to a repo keeps the lib1->lib2 dependency. Adding lib1 as a dependency to app will ensure the order is kept.Now going the local way, you would have to generate both aar and manually add both as dependencies to app. At this point there's nothing to guarantee that lib1 and lib2 are added in the right order.It almost sound simple to ensure lib1 and lib2 are properly ordered. But if you have more dependencies, in a complex graph (ie not just lib1->lib2->lib3...->lib(n)...) computing the order is non trivial.
local aar are not yet supported. I want to add support for it (it's fairly trivial) but I want to figure out the impact of it.
Having a local aar means that this aar cannot have any other dependencies besides local jar. This is because, unlike jars, the order of the aar dependency is important.Let's imagine if you have lib1 and lib2 with a project dependency that is app -> lib1 -> lib2.Publishing lib1 and lib2 to a repo keeps the lib1->lib2 dependency. Adding lib1 as a dependency to app will ensure the order is kept.Now going the local way, you would have to generate both aar and manually add both as dependencies to app. At this point there's nothing to guarantee that lib1 and lib2 are added in the right order.It almost sound simple to ensure lib1 and lib2 are properly ordered. But if you have more dependencies, in a complex graph (ie not just lib1->lib2->lib3...->lib(n)...) computing the order is non trivial.Local dependencies are possible because sometimes developers have to use them. But it can make things very very tricky, and I want to see how we can mitigate this.
Currently your best bet, if you don't have a network) is to actually generate a local repository with all the dependencies and to ship it as a zip to the developers would need them. This way they get a configured repository with all the dependencies setup (ie they don't have to publish them manually to their local repo).It's ugly (I can hear Manfred groan already ;)), but if you really don't want to use a network, that's kinda the best solution IMO.
subprojects { subProject -> apply plugin: 'maven-publish' // according to // this is a workaround to make it create bundleRelease object that I export below // but it fail to solve it apparently. subProject.android.libraryVariants publishing { publications { maven(MavenPublication) { artifact bundleRelease } } repositories { maven { url "file:///tmp/myRepo" } } } }
repositories { mavenCentral() } buildscript { repositories { mavenCentral() } dependencies { classpath 'com.android.tools.build:gradle:0.4' } } apply plugin: 'android-library' dependencies { // compile fileTree(dir: 'libs', include: '*.jar') compile 'com.android.support:support-v4:13.0.0' compile 'com.fasterxml.jackson.core:jackson-core:2.1.4' compile 'com.fasterxml.jackson.core:jackson-databind:2.1.4' compile 'com.fasterxml.jackson.core:jackson-annotations:2.1.4' compile project(':libs:facebook-android-sdk:facebook') compile project(':libs:another_lib') } android { compileSdkVersion 17 buildToolsVersion "17.0.0" sourceSets { main { manifest.srcFile 'AndroidManifest.xml' java.srcDirs = ['src'] resources.srcDirs = ['src'] aidl.srcDirs = ['src'] renderscript.srcDirs = ['src'] res.srcDirs = ['res'] assets.srcDirs = ['assets'] } instrumentTest.setRoot('tests') } }
./gradlew build publish
Caused by: org.gradle.api.InvalidUserDataException: Cannot create a Publication named 'bundleRelease' because this container does not support creating elements by name alone. Please specify which subtype of Publication to create. Known subtypes are: MavenPublication
* What went wrong:A problem occurred configuring project ':engage_lib'.> Cannot create a Publication named 'bundleRelease' because this container does not support creating elements by name alone. Please specify which subtype of Publication to create. Known subtypes are: MavenPublication
Daniele--
use the uploadarchives command .. more details are on the gradle docs
--
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 adt-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Daniele--
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 adt-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
the current convention is (maybe) driven by the fact that the Jar file is not just used by the toolchain but at runtime as well. This is not the case for aar files.
If we want to support local aar (not in a repository) then having the source/doc inside just makes more sense.