I'm evaluating whether to use Ant or Maven to automate my build process for Android development. I've been trying to read online to make an informed decision, but haven't found many specifics that relate to Android development. Based on your experience:
What are the main differences ?
I've read some people saying they have different purposes ? What would those be ?
What would make you pick one over the other ?
What are the strong points and weaknesses of each ?
Which is easier to setup and maintain ?
Is there one that is proffered/most used in the community ?
I found a similar question What benefits does Maven give (over ant) for building android projects?, but he was asking about the
benefits of Maven over Ant and, first, I don't even know the Ant benefits and, second, he just got one answer that didn't make things clear for me.
I use Intellij, just in case it makes any difference though I hope it doesn't.
If you can use Maven, go with Maven. And, don't you dare try to change the standard directories! Heck, even when we use Ant, I insist we setup the directories like Maven. That way, new developers know where things are, or have to trace through the build.xml to find where things are located. The other things is that if you do use Ant, you should also use Ivy. That way, you get the Maven dependency handling within Ant.
The big irony is that once we use Ant and Ivy, and stick to the standard Maven directory structure, moving from Ant to Maven is a cinch. But, the need to move to Maven is lessened too. Our build.xml is clean and simple to understand. All the files are in the right place. Builds are quick, simple, and easy to maintain. Who needs Maven?
The problem is once we've reach this state of Nirvana, is to keep the project from heading back to the State of New Jersey. Developers start carving out exceptions in our build.xml. Don't compile this *.java file. Move this *.xml into our java directory, put test code under the main directory, but we'll put the name test in the file, so we know it's test code... New and complex things are done. And, somehow, we're back in Secaucus.
So, once I've got my Ant project clean and neat enough to move to Maven, I make the leap.
One more thing: Maven makes it very, very simple to copy a project from one computer to another. Maven handles all the dependencies stuff -- even the build stuff. No more, you need AntContrib, or you need to download the hibernate Ant tasks. If you need something, it'll download itself. It's one of the big reasons Maven is so popular with many open source sites.
My big complaint about Maven is that it's so poorly documented. There's a Wiki, but almost no content, and very few manuals.
I've not used Ant or Maven much for Java recently, but I can tell you the main differences between them -- it basically boils down to automated conventions (Maven) vs. absolute flexibility (Ant).
Maven will do almost everything for you, but it's much easier to use if you arrange your projects to suit it. It'll handle dependency tracking and resolution, building, packaging and storing the built packages, while also helping with branch maintenance and release engineering. I find it an awful lot easier to release my (flex) projects that are built with Maven.
Ant is much more flexible. You can do whatever you want, build in whichever way you want. If you have pre-existing projects, you can automate much of what your IDE is doing without changing anything else. It doesn't hand-hold as much as Maven, which also makes it easier to diagnose when things go wrong... You're on your own for dependencies, branches and releases, though. Where we use ant, we use it because we had a project set up which we wanted to automate, and Maven wouldn't adapt to fit it. If you need to do something not supported by Maven, Ant may be your only hope.
Personally, I'd use Maven over Ant if possible, but I'd admit that it's not always possible.
Consider using Gradle!
It combines the best from Maven (convention over configuration) with the best from Ant (the flexibility and the huge library of pre-made tasks).
A Gradle build is written in Groovy, so you have the full power of a scripting language at your fingertips!
There is an Android plugin for Gradle. I haven't used it though, so I cannot tell if it's good or not.
See http://www.gradle.org
I agree with Andrew's answer in its entirety. However, I would note that the maven support is not supplied by the android SDK team. It's provided by a third party. Now, they are an active participant, but it still means that there may be a delay in getting support for the very latest features.
That said, I don't particularly like the ant support provided by the android SDK team. If you run android create project you'll end up with a build.xml that recommends you copy paste chunks of XML in order to customise it. This makes it burdensome to move to a new version of the Android SDK.
Overall, I suspect that moving to maven will be easier to maintain over the long run.
Related
I'm a beginner in Android programing, and I'm working with android studio...now i wander what is the best way for installing open sources libraries from gitHub.
my question is from organization principles point of view-
should i create a new package for every library and put all the library source code as is in that package? should the package be in the source.main.java folder?? (the one that the android studio creates automaticly).
sorry for the dumb question...it's just that im taking my first baby steps in a big scale program and i don't want to loose my head in the future because of bad organization practices.
There's no right answer to this question. A few wrong ways to do it, but common sense will guide you.
My advice:
Start by having the source of this open source code checked into your company's source control system somewhere and capable of being built or re-built as needed. Not necessarily in your project, but just getting the code checked in so it can't be lost or confused with the original author's ever evolving changes on GitHub.
As to how you consume it, you have several options.
Build the open source in it's own project (checked into source control, but separate from your main project). Then just take the drop of compiled files (.class, .jar, .lib, etc...) and check that into your main project. This is the most flexible option if you don't think you are ever going to need to change the open source code that often. Has the side benefit of being managed for several projects.
Drop the source code as-is directly into your project. This means you will always be rebuilding the code. This gives the most flexibility with evolving and changing the the code specific to your project needs.
There's probably hybrid solutions of these options as well.
The bottom line is that whatever you use needs to be copied and building in your own system. Because the code you pulled down from GitHub could go away or change significantly at any time.
A simple solution would be to use JitPack to import those GitHub projects into your gradle build.
First you need to add the repository:
repositories {
maven { url "https://jitpack.io" }
}
and then all the GitHub repositories as dependencies:
dependencies {
compile 'com.github.RepoOwner:Repo:Version'
// more dependencies...
}
Behind the scenes JitPack will check out the code and compile it.
I think you are looking for this. If you are using eclipse, you should check this
If you are looking for adding jar file to your lib, you can simply create a lib folder in your project and add jar file into the library and you must add the line compile files('jarfile.jar') in the build file(gradle build). If you are using eclipse you can follow this
By the way, creating a package for each library and putting all library source codes doesn't look sane to me. It is almost equivalent to recreating the project. I'm sure that it is not the proper approach.
If the third-party code is packaged as a .jar or a .aar and made available in public-facing maven repository (e.g. maven central), then you should add the library as a dependency in your build.gradle file.
If it is not available as a maven/gradle dependency, you could add the library's code to your project as suggested in other answers here. I have never liked that solution at all.
You could also build the .jar or .aar and add that to your project's lib directory, as also suggested by other answers here. For a small, simple project with few dependencies, that might make sense.
What I like to do for larger, longer-lived projects, is to set up my own Nexus server (a Maven repo server), and put the third-party dependencies there.
I would like built a closed source android library using the Gradle. My library has some dependencies to open source projects. How should I structure my library? Can I use gradle?
Can I use gradle?
Short answer:
Yes.
Long answer:
I would assume that your library is packaged as aar (contains resources and compiled bytecode).
First thing you need to know is that at the moment of writing this post there is no way to create fat-aar libraries, which means that you'll have to distribute dependencies of your library separately. The most convenient way to do that, in my opinion, is to generate pom.xml file and publish your library on Maven repository (maven plugin can do all of that), so clients will just fetch all dependencies themselves. Since it is a "private" library, that could be your company's closed repo by access rights (in simple words - create special user for your repo and share password with interested parties).
One downside here is that all dependencies will be exposed in pom.xml and you won't be able to obfuscate them. Personally, I don't think that this is an issue.
Moreover, you get the huge advantage of being able to deploy build automatically and let clients use snapshot versions of the library. This is extremely helpful when you're trying to fix issues and want to deliver them to users fast. On client's side, all they need to do is either just update version in their build.gradle or just re-sync project in case if they were using snapshot.
Second thing. Since your library is closed source, you need to run proguard to obfuscate everything but public interface of your library (all public methods which are exposed to end user).
Remember, that even after obfuscation your code still can be decompiled and all string literals are still there. So, although it was said million times already, avoid storing any critical data in the library (such as passwords, keys, etc.). It is not as hard to extract it as you might think it is: https://www.youtube.com/watch?v=X28Oogg2Q3k
Third thing. I highly suggest you to create internal test project (as a gradle submodule) which will use your library, so you will be sure that you're not making any breaking changes.
Hopefully this answer made things at least a bit easier for you.
I want to organize all my java, C and Android projects with Git.
I have several folders:
something_like_gdlib
example_library1
example_library2
...
example_project1
example_project2
...
In each of those projects I use some of those libraries. But if I update a library, I want all projects to get the changes for that library.
Usually I work alone on those projects and I just want to have a change history.
Now I want to work together with another programmer, that should get access to only one project and the corresponding libraries.
How should I set up git? I heard of subtrees or submodules? Or is there a better solution?
Submodules or subtrees could indeed be a solution.
On the other hand you could keep the repos totally independent from a git point of view, and publish your libraries.
Eg: Assuming you're working with Maven in Java, when you want to upgrade example_library1 in example_project1 you could:
Build a new version of the library (and tag the corresponding commit)
Put this binary either in a local or shared maven repository
Update the version of the library in the pom.xml of your project
An advantage of this approach would be that there are no need to do anything complicated with Git
Drawbacks would be:
It may be cumbersome if you want to upgrade in your application every time you commit in your library
If you don't already have a "package architecture", you may need to set it up first
I'm currently using ant to build Android projects but it simply doesn't cut it for larger projects and maintaining different deliverables is becoming a pain.
Two alternatives I'm looking at are Facebook's Buck (http://facebook.github.io/buck/) and Gradle that Google is backing with Android studio (http://tools.android.com/tech-docs/new-build-system/user-guide).
Besides trying them out and reading up on their coverage I would like to ask you fine Stackoverflow people for your recommendations. Preferably if you've used either tool for a while, with bonus points for Buck since it didn't get that much coverage.
Important points are
build speed, specifically for dev builds
multiple deliverables from same code base
ease of use
I'm open to other alternatives as well. What do you suggest and why?
As I put front and center in the Buck documentation: "Buck is a build system for Android that encourages the creation of small, reusable modules consisting of code and resources."
By design, Buck encourages you to create small modules so that you can easily compose a new app out of your existing building blocks. This means that maintaining multiple deliverables is straightforward: it eliminates boilerplate without requiring you to organize your repository into a predefined structure. You can also create ad-hoc build steps to suit your needs with Buck via macros and genrules. (A more formalized extension system is in the works.)
We also care a lot about speed, particularly the speed of incremental builds. Because Buck has a strong concept of dependencies, we can often avoid rebuilding intermediate artifacts. Other build systems also try to do this (like Ant), but frequently sacrifice correctness, as a result. We don't.
We recognize that IDE support is important. Certainly Google's collaboration with Gradle gives them a leg up there. However, Buck has a command to generate an IntelliJ project from the dependency graph defined in Buck build files, and we have broken ground on our own IntelliJ plugin, so this is something that we also care deeply about.
Finally, bear in mind that Buck is used to build Facebook, Facebook Messenger, and Instagram for Android. Buck is not going away. Further, the code for all three apps (and reduced versions of the apps, for even faster development cycles) lives in one Git repository at Facebook, so those of us working on Buck internally are sensitive to the needs of large codebases that support multiple deliverables.
Long-term, the new Gradle build system will be the standard, and it looks very good.
However, it looks like it's not quite ready for use in non-trival projects yet. For instance, it looks like it doesn't support apklib dependencies yet.
This is understandable, and reflected in the fact that the current version is 0.3
I'm looking forward to seeing it evolve.
For a project that needs to be build today, I'd use Maven. Actually, I'm in the process of moving a client's build from Eclipse-only to Maven right now, so that they can have a repeatable build process, good dependency management, and CI.
The new Gradle build looks like it will be more flexible, but right now Maven handles apklibs. Since Gradle can use Maven dependencies, I'm expecting that we'll be able to move from Maven to Gradle easily in the future.
I don't know anything about Buck. However, that in itself is a red flag. I'd hesitate to use a build system that few people know anything about. That doesn't mean that it's not good - it may be great. But using it now is probably a gamble.
Here is a gradle plugin OkBuck which can let you start using BUCK base on your current Android Studio + Gradle build system with only 10 lines of configuration. Check it out.
OkBuck can let you build your project both with gradle and buck, with all advantages of gradle and buck.
I would add the following advantages of Buck:
Exopackage, i.e. incremental apk build; just check the table with build time on that page
Network cache. If you have several developers working with an app, you won't need to rebuild components which are already built by other developers.
As you can see from my passed 3 questions I am having major problems with my project setup. I am getting lots of very specific errors that seems like nobody can answer them. I am getting hugely frustrated. So I am going to try a fresh approach. I will describe how I would like my project set up and if somebody could give me some brief steps to follow I would be very grateful. After messing around with this for around a week I believe I have some knowledge but maven seems to be incredibly difficult to understand.
I am writing a library which will be used in 2 projects. The major libraries I would like to use are roboguice, robolectric and jackson(json library). I would like to have a way to test the library but I am unsure if this should be in a different module or not. Robolectric seems to suggest it should be in the same module. I am unsure how I should use this library in the other 2 projects. I have been looking at this http://code.google.com/p/maven-android-plugin/wiki/ApkLib but unfortunately the website tells me next to nothing about how I should create the apklib.
If it is possible I would also like the other 2 projects to have a dependency on that library and build it automatically.
I have been using this site to create the maven project http://stand.spree.de/wiki_details_maven_archetypes
But I have been running into issue after issue. If anybody can point me in the right direction I will be very appreicative
Even if maven is (almost) a foreign country to me, I had some moderate success setting up a maven project and interacting with it using intellij. I wanted to use it because it looked the easiest way to have robolectric working with intellij.
I wrote a blogpost you can find here
What you need is:
Maven android sdk deployer https://github.com/mosabua/maven-android-sdk-deployer
Maven android plugin http://code.google.com/p/maven-android-plugin/wiki/GettingStarted (using android archetypes is just fine)
If you want to build an apk lib instead of an apk, just specify apklib in the packaging tag
PS: I also saw this a while ago, but never gave it a try.