Can Gradle support custom gnu Make-based project structure (for Java codebase)?


(the.dreadful.hours) #1

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!


(Peter Niederwieser) #2

Gradle can cope with pretty much any directory layout. The bigger question is why you’d want to layer Gradle on top of this legacy build, and whether it’s worth it.


(the.dreadful.hours) #3

Thank you for the reply, Peter!

The project itself, for good or bad, is far from dead and is actually actively developed. If I manage to push Gradle successfully inside my team, maybe we could gain momentum and, who knows, some C-person will pull their head out of the sand and the story would have a happy ending : )

What would you suggest instead? Would it be an overkill to adapt Gradle to such a legacy (they use “tradition” :slight_smile: ) build?


(Peter Niederwieser) #4

It’s hard to say without knowing the specifics of your situation, but in general, I’d try to fully replace (parts of) the build, rather than only using Gradle to stich together legacy builds.