How to include another project with gradle

I have a project A and B. Project B have sub projects B1, B2 and B3.

I would like to use B3 in project A. And project A and B are in different folder.

How should I do?

https://gradle.org/docs/2.4-rc-1/userguide/tutorial_java_projects.html#sec:examples

Think my case is different. My project folder path is not this easy.

Consider project A is on C drive, project B is on D drive.

Why is so? Can’t you check them out in a logical structure?

Otherwise, to answer your question, you’d want to customize your settings.xml as follows:

include 'A', 'B', 'C'

project('A').projectDir = new File("$rootDir/../../foobar/A")
project('B').projectDir = new File("D:/bax/qux/BBQ")
// project C will be resolved by convention (i.e. a directory under the rootDir)

For more in the API’s you can use ther, see the Settings DSL.

While it’s not working for me.

The syntax has to be

project(':B').projectDir = new File("D:/bax/qux/BBQ")

And even so it dosen’t add it to my dependencies list. For my case I need to use the submodule B1 only.

Thanks for the correction on the syntax.
Of course it doesn’t add it to your dependencies automatically - read the link in my first reply.

After fighting with gradle for half a day, I think I could’t make it work for me in my case.

You are not giving me a lot to work with, so I am out of generic advice. You may want to consider teh Build Migration service provided by Gradleware (may be cheaper than spending many days in unproductive direction).

PS. If you find something that works for you better than Gradle, please let us know.

We have a similar but not exact same project setup. We check out 5 different repositories, each having multiple projects.
From the main project we are working with I create a dynamic task generator that will build each of those projects (if they exist using a remote build context using the GradleBuild task type.
Then the dependencies in the main project are resolved from those remote builds by either mavenLocal or file based dependencies (again if that project exists).
Our CI jobs will upload all the individual project artifacts to our maven/nexus repository. This way we can either use those uploaded maven dependencies if the source projects don’t exist or use file based dependencies if they do.
This allows anyone to either checkout only the main source project or any combination of the other 4 source projects as well, and to seamlessly build the main project, regardless.
Not sure if that idea gives you something to work with? To give you some idea here is some skeleton code:

task rebuild {
  description="Rebuilds the project"
  group="Development"
}
//Root project extra dependencies
rebuild.dependsOn (
  allprojects.clean,
  allprojects.build,
  linkModule,
  eclipseAll,
)
//Create a container task to rebuild all dependency projects
task rebuildAll {
  description="Runs rebuild tasks from all dependent source projects"
  group='Development'
}
List dependencyProjects=['projectB','projectC','projectD','projectE']
List dependencyProjectTasks=[]
//For all participating projects create a remote build task
dependencyProjects.each { prj->
  File workingDir = file("${workspaceDir}/${prj}")
  if (workingDir?.list()?.toList()) {
    def taskName="rebuild${prj.toString().capitalize()}"
    task "${taskName}"(type:GradleBuild) {
      description="Runs the ${prj} project's rebuild task"
      group="Development"
      dir = workingDir
      tasks = ['rebuild']
    }
    dependencyProjectTasks << taskName
    rebuildAll.dependsOn "${taskName}"
    configureEclipse.mustRunAfter "${taskName}"
  }
}

In this example, each source project has a rebuild task which does whatever it needs to do. In this main project it also has a rebuild task and a rebuildAll task. So now each other source project, if it exists, gets built first and in doing so creates its artifacts ready for the subsequent projects. ProjectC might use ProjectB, ProjectD might use ProjectC, etc. The main project can use any artifact from any of the other source projects. Each of those can have as many sub-projects as they need.
In this example they are all at the same level. If for instance your projects can be scattered all over different locations, you could use a map instead of a List to hold the location if its a feasible solution.