I've been migrating to Gradle and I've encountered an awkward issue.
Using Intellij IDEA I found two ways to add a dependency, please see the pictures attached:
As I can see these two way are not interchangeable. But the way B is obviously equivalent to
dependencies {
compile project(':xx-manager-shared')
}
Could anyone explain to me that's the exact difference between these two methods of adding dependencies?
And how should I organise "cross dependencies" in Gradle when
A module depends on B module,
B depends on C
and C depends on A?
It seems in A the dependencies are for the Android module, and in B it is the dependencies required by the Gradle plugin for building, e.g. Annotation processing?
I would recommend you download and try out Android Studio, it looks a lot simpler since it is purpose built for Android development, and you get a simple list of modules, without the tree hierarchy above.
I generally add dependencies by hand, as it doesn't mess up the build.gradle files.
In answering your other question, you are defining circular dependencies, so if you can find a way around it it's best, otherwise you can try adding them, syncing with Gradle and seeing if it works.
Related
I have an Android project with the following dependencies:
-- Android App
---> MySDK.Jar
------> 'org.apache.commons:commons-lang3:3.5'
This is MySDK.jar that has a dependency on commons-lang3.
I'm working on Android Studio and I'm thus using Gradle.
Here is my problem:
I have shared "MySDK.Jar" to someone and he has built his own Android App on top of it.
It works but we have seen that the compiler doesn't notice the missing dependency on 'org.apache.commons:commons-lang3:3.5'. At run-time there will be a crash if the code using 'org.apache.commons:commons-lang3:3.5' is called. One may not notice the problem if he doesn't call the code using this library.
I know that we can solve this issue by adding the following line to Android App build.gradle file:
compile 'org.apache.commons:commons-lang3:3.5'
I'm wondering if there is a way to get a compile error indicating such missing dependencies? It is indeed better to see the dependency problem at compilation time rather than at runtime.
What are the recommended good practices for this?
Thanks!
commons-lang3 is a transitive dependency of Android App. As such, it is often not needed for compilation - there are exceptions, especially regarding multiple levels of inheritance. So at compile time you (usually) do not know whether you miss a transitive dependency that you need at runtime.
This is where Gradle comes in. Gradle can (as Maven) resolve dependencies transitively from a Maven repository (as MavenCentral). If you put MySDK into a Maven repository (like Nexus or Artifactory, which have open source versions), everyone using MySDK will automatically draw commons-lang3 so you will not miss anything at runtime.
If you are just adding the jar file in your project you can't warning about the missing dependencies.
To do it you have to publish the jar file in a maven repo.
In this way you have a pom file which describes the dependencies that gradle has to download.
Provide a method like MySDK.init() int your MySDK.jar,call a method whe is belong to org.apache.commons:commons-lang3:3.5' in the MySDK.init() method, then put init() into onCreate() of your Application,
Another way is，putorg.apache.commons:commons-lang3:3.5 into MySDK.jar，
Hope it helps you :)
I am building an Android Library that I am trying to publish to a Nexus Maven Repository. What leaves me puzzled is that there seems to be no clean way of publishing my project through gradle with the maven-publish plugin.
I found a number of answers, which don't really satisfy me:
This plugin only works okay-ish and it is not currently maintained.
Modifying the generated POM in my build.gradle works, I just don't feel like this is the way it should be done - it seems to common of a problem to be solved in each and every android library's build.gradle.
Google even mentions the maven-publish plugin in their documentation but they don't really show how to use it.
Please tell me what I am missing: Is the problem less trivial than I think? I am just trying to publish an AAR with a pom stating it's dependency, I am trying to build the most standard and default solution I can.
Thanks in advance.
I'm building some Android apps using Android Studio. Adding dependencies/libraries is really easy by going to file -> project structure -> app -> Dependencies.
But this got me thinking, what exactly is the different between dependencies and libraries and how do they compare? (what's better)
Library is a dependency. Dependency means things that your app depends on. Dependency can be a module, library or a file.
I have an Android project which (unfortunately) uses Maven as a building manager. The thing is that I have a lot of standard java .jar dependencies.
The first issue I am facing is the following :
1) These jar have other dependencies, and sometimes are redundant. The problem is that the removeDuplicates functionality of the android-maven-plugin does not seem to work as intended and I encounter the classic "multiple dex files define class X". I have resolved this issue by excluding the redundant dependencies one by one, which is very tedious and provides me with a pom which can only be qualified as disgusting. So here is my question : is there any way to easily manage transitive dependencies with android-maven-plugin and avoid the "class defined in multiple dex files" error ? Does Gradle handle this kind of stuff in a better way ? Or am I doomed to use "*" in every dependency exclusions and basically remove the transitive dependency feature from Maven ?
The second issue is about compilation time and the behavior of IDEA when using Maven dependencies in an Android project :
2) First, having to dex that many dependencies is obviously very time consuming. Is there any way to avoid pre-dexing all the jars everytime ? If I understand things correctly, if the jar does not change between 2 builds, then it should not be dexed again. I guess it is because I call mvn clean everytime, however if I do not the "class defined in multiple dex files" error shows up again. The temporary workaround for me was to adequatly declare dependencies in my pom using Maven and use the "Make" function of IDEA, which I guess calls the android tools and build the stuff appropriately. It worked for some time, and it was actually great. The pre-dexing worked as I expected and did not re-dex everything at each compile command. However, I hit the same wall all over again, the "Make" command produces "class defined in multiple dex files", I guess that removing duplicates here does not work either (just in case I was not clear, the same project, with the same pom, builds successfully with Maven but encounters the error when using "Make").
Basically, what I really would like is to declare and manage my dependencies using Maven (actually I do not really have a choice in the matter) and build by calling "Make" in IDEA. The ideal case would be to have the same behavior as "Make" when invoking "mvn clean install". Just in case, I would like to point out the fact that using parallel building is a noticeable improvement but it is quite far from what I would expect.
I am switching from Eclipse to Android Studio. I have couple of 3rd party libraries that I have added features or modified a little bit. Since the libraries in Eclipse are also projects and we can access the code, I had no problem.
In Android Studio compile tag in dependencies is great but in my case I cannot use it unfortunately.
I fork the project and made necessary changes and add the project as a module in Android Studio. Since the library project already has settings.gradle and example and library modules, there is a mess in my project and it does not compile at all.
Has anybody experienced such a problem? What to do and what is the correct way to forked libraries?
What we've done in my project is create gradle scripts for our dependencies that don't have them, and modify the gradle scripts for dependencies that do have them. Gradle does not play very well with modular dependencies, unfortunately: Each sub-project must know its place in the larger overall project. Since you've already forked the github project, modifying it further shouldn't be a problem.