问题
I am migrating to Gradle as my build tool for a Java project. My main project (A) has a dependency on other projects (B and C).
At the moment each of these projects are in CVS individually and when I want to compile A I have to check out A, make a subdir in A called B in which I check out B. Same goes for C.
Im going to migrate to repository manager (nexus) in which B and C can be published to. When this happens, module A can just have a dependency on B and C which it can get from nexus.
However, the difficulty arises if I do not want to publish B and C (for testing purposes) and I want to build A with my latest code from B and C without committing it to nexus.
My initial thoughts on this are to build the jar for B and C and pull it into the "lib" folder for A. However Im sure there is a better way.
In maven I could do a "mvn clean install" which would install B and C in my local maven cache. A would then look there for the appropriate jars.
But Im still not sure this is the best way. I had a look into gradle subprojects but I dont fully understand them. How would the submodules handle in an SCM (would I also need to use git submodules?)
I would appreciate some guidance as to best practices for this situation. Thanks
EDIT:
The reply below from Vyacheslav Shvets is the most accurate answer I have found so far. There is one other way of switching out a gradle project dependency with maven-style dependency. This involves dependency substitution as described at https://docs.gradle.org/current/userguide/dependency_management.html#sec:project_to_module_substitution
This can be wrapped around a:
if(project.hasProperty("someSwitch")){
configurations.all{.....
....
}
}
Usage of this method would be:
gradle build -Psomeswitch
回答1:
The old (classical) way
The same approach as for Maven:
- Apply
maven
plugin on projectB
Run
gradle clean install
on projectB
Actually, you don't have to
clean
every time if your build correctly uses task inputs and outputsIn project
A
, addmavenLocal()
repository and run build
The new way (experemental) - Composite build
A composite build allows you to combine multiple Gradle builds and replace external binary dependencies with project dependencies as if you were using a single multi-project build https://docs.gradle.org/2.13/release-notes
This is not fully available yet. Since 2.13 you can use it via Tooling API (for example, Buildship 2.0 plugin for Eclipse IDE). The common usage will be available in 3.1, but you can try it now using nightly builds of 3.1
If you download and execute demo build from Gradle's github with latest nightly build you will see the following:
$ gradle build
[composite-build] Configuring build: C:\Users\Shvets\repos\composite\projectB
[composite-build] Configuring build: C:\Users\Shvets\repos\composite\projectC
:compileJava
:projectB:b1:compileJava
:projectB:b1:processResources UP-TO-DATE
:projectB:b1:classes
:projectB:b1:jar
:projectB:b2:compileJava
:projectC:compileJava
:projectC:processResources UP-TO-DATE
:projectC:classes
:projectC:jar
:projectB:b2:processResources UP-TO-DATE
:projectB:b2:classes
:projectB:b2:jar
:processResources UP-TO-DATE
:classes
:jar
:assemble
:compileTestJava UP-TO-DATE
:processTestResources UP-TO-DATE
:testClasses UP-TO-DATE
:test UP-TO-DATE
:check UP-TO-DATE
:build
BUILD SUCCESSFUL
Total time: 4.497 secs
For deep understanding, see demo video of both approaches.
来源:https://stackoverflow.com/questions/38932548/gradle-multiproject-with-scm