Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Chore/82: Migrate the build tool from maven to gradle #83

Merged
merged 75 commits into from
Jun 3, 2019

Conversation

ursjoss
Copy link
Owner

@ursjoss ursjoss commented May 24, 2019

Resolves #82

@ursjoss
Copy link
Owner Author

ursjoss commented May 24, 2019

As a first introduction, I like that you want to centralize the plugin management in buildSrc. I would, however, use a different style:

In buildSrc I'd create a Plugins.kt file and declare the plugins like this:

import org.gradle.kotlin.dsl.PluginDependenciesSpecScope
import org.gradle.kotlin.dsl.kotlin
import org.gradle.kotlin.dsl.version
import org.gradle.plugin.use.PluginDependencySpec

fun PluginDependenciesSpecScope.kotlinJvmPlugin(): PluginDependencySpec =
        kotlin("jvm") version Lib.kotlinVersion

fun PluginDependenciesSpecScope.kotlinSpringPlugin(): PluginDependencySpec =
        id("plugin.spring") version Lib.kotlinVersion

// etc.

I really like this approach, it's much more concise. However, I did not get it to work. The files in buildSrc don't seem to see the relevant scopes. Maybe we can have another look together next week.

Thanks for the spike review!

I pushed the change that fixes running scipamato-core, by the way.

@jcornaz
Copy link
Collaborator

jcornaz commented May 25, 2019

Arf, Indeed.

My proposed change does not seem possible. The plugins block get a special treatment by gradle and is evaluated very early, even before the import statements of the script (because it defines what can be imported).

It prevents a lot of possible abstraction for applying the plugins. I'll have to play more with it to figure out what's the best solution.

@ursjoss ursjoss force-pushed the master branch 3 times, most recently from 119c0dd to b279023 Compare May 29, 2019 22:53
* code coverage is passed on to sonarcloud, but still, we don't see
  coverage for classes that are tested in other modules (e.g.
  AbstractDefinitionEntity (in common/entity) that is tested by
  AbstractDefinitionEntityTest (in common/test).
…ith maven

* Suspecting that integration test coverage is not included... Need to investigate
* Also tried using the binary exec format instead of the xml report, to no avail
Copy link
Collaborator

@jcornaz jcornaz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks nice to me.

The build seems almost simple compared to the complexity of the project, so I'd call that a success.

It worked also well for me (I tried the tasks check, :core-web:bootRun and :public-web:bootRun)

@ursjoss
Copy link
Owner Author

ursjoss commented Jun 3, 2019

@jcornaz Many thanks for your review!

@ursjoss ursjoss merged commit 561425b into master Jun 3, 2019
@ursjoss ursjoss deleted the chore/82-gradle branch June 3, 2019 22:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Build project with gradle
2 participants