Hello, guys, another newbie seeking for an advice here. The project I’m involved in uses some funky GNU Make + custom Perl scripting + additional shell scripts in order to support a multi-project setup for a large Java codebase (on Linux/Mac/Windows). I decided to give Gradle a shot to see if there is a sane way out of the Make swamp. I’d like to ask for a high level opinion whether I’m on the right track or should better just give it up. This is how the multi-project structure looks like:
[dim@localhost fnord-project]$ tree
.
├── build.gradle
├── network
│ └── service
│
└── fnord
│
└── network
│
└── service
│
└── common
│
├── bar
│
│ ├── Bar.java
│
│ ├── build.gradle
│
│ └── tests
│
│
└── BarTest.java
│
├── charly
│
│ ├── build.gradle
│
│ └── Charly.java
│
└── foo
│
├── build.gradle
│
└── Foo.java
└── settings.gradle
It’s a simplified excerpt as it could be nested on several such levels. In the actual codebase, the child “build.gradle” files are in fact “project.mk” module descriptors (somewhat similar to pom.xml) and thus “foo”, “bar” and “charly” are separate modules. The parent “build.gradle” is a Makefile which lists each sub-module, defines tasks and imports various scripts. Child module file structure is flat, i.e. most of the files are directly under the module root (i.e. siblings of “Foo.java”, “Bar.java” and “Charly.java”). The folders named “tests” are where the test classes go. And the sweetest part - Java classes’ package definition is like this (mind the previous snippet):
---->package fnord.network.service.common.bar;<----
public class Bar {
// beautiful code here
}
Given all this, could Gradle match such a (wacky) project layout? Without porting the whole black magic thing to Groovy, that is.
I’ve tried a bit and was actually able to package a jar-file for each sub-module in the example but then added unit tests and figured out that testCompile dependencies are not being downloaded at all.
Thank you in advance!
) build?