Make the root project a composite build

[martinbonnin]

One more step towards lazy task configuration (#69)

This pull requests moves the samples to a composite build makes the rootProject a composite build that will treat the plugin as an included build.

This allows to do dependency substitution on the plugin artifact and therefore have the sample code in sync with the plugin code from the repo (without having to publish on mavenCentral mavenLocal or jcenter first).

If you're working on the samples, you should open swagger-gradle-codegen/sample in your favorite IDE. Opening the root project in intelliJ is still the recommended way to work on the project as it will include the necessary projects.

[cortinico]

This allows to do dependency substitution on the plugin artifact and therefore have the sample code in sync with the plugin code from the repo (without having to publish on mavenCentral or jcenter first).

You don't need to publish on mavenCentral or jcenter at the moment. You have to publish the plugin to mavenLocal and use it in a subsequent build.

If you're working on the samples, you should open swagger-gradle-codegen/sample in your favorite IDE.

Ideally we want to avoid having to open two separate project to work with samples and/or plugins. The convenience of the current setup is that you open a project and you have everything there.

[martinbonnin]

This allows to do dependency substitution on the plugin artifact and therefore have the sample code in sync with the plugin code from the repo (without having to publish on mavenCentral or jcenter first).

You don't need to publish on mavenCentral or jcenter at the moment. You have to publish the plugin to mavenLocal and use it in a subsequent build.

Sorry, I meant mavenLocal, not mavenCentral 🤦‍♂️ . As I said in the other PR, I'm not a fan of using mavenLocal as it introduces a global state that can have side effects and that needs to be maintained.

Ideally we want to avoid having to open two separate project to work with samples and/or plugins.

Technically, you can do all the work from the composite build and edit the plugin files from there.

The convenience of the current setup is that you open a project and you have everything there.

The drawback being that changing the plugin requires to call publishToMavenLocal for the changes to be seen by the samples. Also when the project is first opened, the samples use the plugin from jcenter and not the one from the repo, which might be confusing if they don't behave exactly the same.

Let me know what you think. I started to work on this while working on lazy configuration because I changed some API in GenerateTaskConfiguration and this broke my gradle sync. But now I know about publishToMavenLocal, I can do the lazy configuration without having composite builds too.

[cortinico]

Sounds like composite build could help us improve the project setup 👍 I'm in for it. I just ask you to unwrap the setup that you're proposing here.

Ideally the base project should be the one in the root folder. From there you should include all the sample modules (as gradle module) and plugin as a composite build.

In other words: in the top level settings.gradle.kts the goal is to have something like.

include(":samples:junit-tests",
        ":samples:kotlin-android",
        ":samples:kotlin-android-moshi-codegen",
        ":samples:kotlin-coroutines",
        ":samples:groovy-android")
includeBuild(":plugin")

This will make sure that by running gradle in the top folder, everything works as expected.

[cortinico]

Awesome! I tested it and it works great! Really looking forward to merge this. I left just a minor comment

[macisamuele]

@martinbonnin I think that #101 caused merge conflicts with this branch. Sorry 😢

Let me know if you need support or you are able to address them by yourself (I don't expect it being very complex)

[martinbonnin]

@macisamuele this branch renames a lot of files so I guess that was expected. I just rebased on master, it should be good now.

[macisamuele]

@martinbonnin ++
Looked like you had @cortinico approval for your changes. So I'll prefer having him taking care of merging this change.
From a quick pass through the changes I see why the conflicts were there and how rebasing fixed all the things, so it should be all good ™️

Thanks a lot for helping in improving our gradle configurations 💯

[macisamuele]

keep the Make+Gradle discussion opened

@cortinico @martinbonnin : I'm the kind of lazy developer ;)
I do usually configure, in each git repo I'm working on, a custom git command (ie. git push-after-tests) that allows me to push to origin only if tests are green.
Said so I don't have a very strong opinion on having Make or Gradle or both, is more about having a single command to run that basically runs all the tests that travis would run.

Having a gradle task that would behave like the current make test would be more than enough on my side 😄

[cortinico]

I'm totally in for nuking the Makefile. @martinbonnin do you want to take this?

[martinbonnin]

👍 I'll open a PR. What's a good name for the gradle task that'll do everything ? test is already taken. Something like ./gradlew buildProject ? ./gradlew makeAll ? Something else ?

[macisamuele]

What about travisTest? At the end the task should be connected to the travis execution as well 😊

[cortinico]

I'd rather go for preMerge or preMergeTest as is CI agnostic and contains all the verification tasks that needs to be executed before integrating a branch