maven-many-repo-to-gradle-monorepo-tutorial

# Working w/ Gradle: A Practical Guide 

## Maven Status
- not incremental in practice
- no remote caching
- snapshot handling/updating
- installing
- slow, why it's slow
- plugin dependency hell
- fairly simple/standard
- why builds are slow today

## Gradle Structure

Check out the gradle demo on the `identity` monorepo:
```
git clone git@github.com:LiveRamp/identity.git
cd identity
git checkout gradle_demo
```

Create a branch with your name so your build doesn't conflict with anyone else.
```
new_branch -r gradle_<your_name>
```

Make a PR for your branch: https://github.com/LiveRamp/identity
Find your PR build and keep it on hand: https://jenkins.liveramp.net/job/LiveRamp/job/identity/view/change-requests/

Now let's look at our gradle-related files:
```
find java | grep "gradlew\|gradle\.properties\|\.gradle$"
```

### Gradle Wrapper

### settings.gradle

### gradle.properties

### build.gradle files 

#### uberjar vs libjar

#### hadoop vs java

## Try building

- `clean`, `build`, `publish`, output levels, `--dry-run`, `--refresh-dependencies`, `gradle :prj:build`

## Set up IntelliJ project for Gradle monorepo

- install Gradle and Groovy plugins if you don't already have it

- create new project with identity root 
   - new empty project
   - add module to the new project from from existing sources for the java direcotry
   - import from existing model (gradle)
   - use default gradle wrapper (this makes sure we're using the same build version, talk about how to upgrade)
   - decide where to put your ideaprojects metadata
   - use explicit names
   - check auto-import

- talk about syncing projects

- `mvn liveramp-build:init-db` (talk about implications)

- run some tests locally

## Adding an app from scratch

- add directories 
```
mkdir -p example/src/main/java/com/liveramp/example
mkdir -p example/src/test/java/com/liveramp/example
```

- create a gradle.build file & add to the settings.gradle
   - explain naming and module/submodules
- create a class and a test
- build and look at local outputs
- build & publish and look at outputs
- change to uberjar
- build and look at local outputs
- build & publish and look at outputs

## Adding an app from another repo

- need to preserve git history
- need to use updated file path
- need to use internal dependencies not dependencies on snapshots!
- can't use clojure! -> masked by using previous snapshot

### Steps
- @rgeorge says:
```
cd ~/code/oi_dsc_external
mkdir oi_dsc_external
git co -b monoize # make a branch
git mv * oi_dsc_external/ # it'll auto-fail to move the directory to itself
git commit -m "MONOIZE" #commit to the branch

# switch to the other project
cd ~/code/identity
git co -b mybranch # make a branch
git remote add mono ../oi_dsc_external # you're making the other git repo a possible upstream repo
git fetch mono
git merge mono/monoize --allow-unrelated-histories # upstreamname/upstreambranch
```
- resolve merge conflicts
- add build.gradle file 
- fix internal file paths (DISCUSS THIS)
- register docker images
- move kube manifests to correct directories
- create, review, and merge PR
- remove old builds
- remove old deploys
- enjoy the benefits

## Decision Time

How do we want to move to the monorepo?
- One at a time as after we containerize
- One at a time as we move to GCP
- Containerize -> Move all at once
- Containerize -> GCP -> Move all at once

Current personal preference:
- Move over all library projects/fully containerized projects now
- Then one by one as we're containerizing, as soon as there are no legacy deploys
- Will only help turnaround with GCP but seems like less room for error


How do we like the file structure?
- where should docs go?