Separate gradle build logic (and other features)

[atomfrede]

Overview of the feature request

I think our gradle part could have little make over for v8. In particular I am thinking of using some (precompiled) conventions, which reside in buildSrc directory. Having this the generated build.gradle file would in an optimal case just apply a few plugins and thats it.

Furthermore I would like to introduce gradle version catalogs to centralize the versions in an idiomatic gradle way.

Motivation for or Use Case

When talking to the gradle guys in the last couple of years they always suggested to have specific jhipster plugins. We (or me specific me) have always rejected this, because it would have created huge maintenance burden I was not willing to take. Moreover with everything generated we could easily provide workarounds for our users. Compared to having really dedicated plugins we would require both a release of the plugin and the generator.

With using convention plugins in buildSrc directory we can have best of both approaches. We clearly separate specific build logic, dependencies and plugins for specific jhipster configurations and as all is generated users can see everything and opt-out or replace stuff if needed.

This would also simplify our templates as we would try to have e.g. frontend specific stuff inside a dedicated conventions plugin and not different if/else switches inside the main build.gradle template file.

This requires also changes to internal apis and needles as such I would consider this a breaking change and would like to do in v8. This will also most likely make a lot of blueprints not compatible with gradle anymore (thinking about the native blueprint), but I hope the required changes are quite small.

I would try to implement a first prototype for first/initial discussion so we know everyone is happy with the outcome/result.

CC @mraible @jdubois @DanielFran @mshima @deepu105 Your view in this is highly appreciated.

[deepu105]

I'm all for simplifying and improving the gradle builds. I think we could go the direction of generating pligins in buildSrc, i personally don't see a big issue

…

On Wed, 31 Aug 2022, 2:35 pm Frederik Hahne, ***@***.***> wrote: *Overview of the feature request* I think our gradle part could have little make over for v8. In particular I am thinking of using some (precompiled) conventions, which reside in buildSrc directory. Having this the generated build.gradle file would in an optimal case just apply a few plugins and thats it. Furthermore I would like to introduce gradle version catalogs to centralize the versions in an idiomatic gradle way. *Motivation for or Use Case* When talking to the gradle guys in the last couple of years they always suggested to have specific jhipster plugins. We (or me specific me) have always rejected this, because it would have created huge maintenance burden I was not willing to take. Moreover with everything generated we could easily provide workarounds for our users. Compared to having really dedicated plugins we would require both a release of the plugin and the generator. With using convention plugins in buildSrc directory we can have best of both approaches. We clearly separate specific build logic, dependencies and plugins for specific jhipster configurations and as all is generated users can see everything and opt-out or replace stuff if needed. This would also simplify our templates as we would try to have e.g. frontend specific stuff inside a dedicated conventions plugin and not different if/else switches inside the main build.gradle template file. This requires also changes to internal apis and needles as such I would consider this a breaking change and would like to do in v8. This will also most likely make a lot of blueprints not compatible with gradle anymore (thinking about the native blueprint), but I hope the required changes are quite small. I would try to implement a first prototype for first/initial discussion so we know everyone is happy with the outcome/result. CC @mraible <https://github.com/mraible> @jdubois <https://github.com/jdubois> @DanielFran <https://github.com/DanielFran> @mshima <https://github.com/mshima> @deepu105 <https://github.com/deepu105> Your view in this is highly appreciated. — Reply to this email directly, view it on GitHub <#19615>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIOKF27JWSIP3VRLDEYSSLV35GQ7ANCNFSM6AAAAAAQBKTP4A> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[thetric]

Further documentation to the mentions Gradle features:

• conventions: https://docs.gradle.org/current/samples/sample_convention_plugins.html#compiling_convention_plugins
• version catalog: https://docs.gradle.org/current/userguide/platforms.html
  ** might be in TOML format instead residing inside settings.gradle: https://docs.gradle.org/current/userguide/platforms.html#sub::toml-dependencies-format

[atomfrede]

@mshima @DanielFran I would start with extracting the versions into a version catalog. I hope we can reuse the existing toml file which we use for dependabot already and generate it for an application. With regards to convention plugins I think we might start by creating a convention plugin for gatling for example.

[mshima]

I don't know how a convention plugin looks like but sounds ok.
The toml file can be built from scratch using an external lib

generator-jhipster/generators/server/support/dependabot-gradle.mts

Line 19 in 0a8150c

import { parse } from '@iarna/toml';

[atomfrede]

@mshima I guess it makes sense to create a sub gen for gradle like you've done for maven? It looks pretty cool the current modularization of the generators

[mshima]

@atomfrede we already have a grade sub-gen, but it's quite different of maven due to design.
We are mostly writing a gradle script file for each tech and injecting it.
Gradle needles are:

generator-jhipster/generators/gradle/generator.mts

Lines 70 to 75 in 433413f

	source.applyFromGradle = script => this.editFile('build.gradle', applyFromGradleCallback(script));
	source.addGradleDependency = dependency => this.editFile('build.gradle', addGradleDependencyCallback(dependency));
	source.addGradlePlugin = plugin => this.editFile('build.gradle', addGradlePluginCallback(plugin));
	source.addGradleMavenRepository = repository => this.editFile('build.gradle', addGradleMavenRepositoryCallback(repository));
	source.addGradlePluginManagement = plugin => this.editFile('settings.gradle', addGradlePluginManagementCallback(plugin));
	source.addGradleProperty = property => this.editFile('gradle.properties', addGradlePropertyCallback(property));

And dependencies are split in separated files instead of api calls:

• Cache:
  file: https://github.com/jhipster/generator-jhipster/blob/main/generators/spring-cache/templates/gradle/cache.gradle.ejs
  injection:

  generator-jhipster/generators/spring-cache/generator.mts

  Line 102 in 433413f

  source.applyFromGradle?.({ script: 'gradle/cache.gradle' });

• Kafka:
  file: https://github.com/jhipster/generator-jhipster/blob/main/generators/spring-cloud-stream/templates/gradle/kafka.gradle.ejs
  injection:

  generator-jhipster/generators/spring-cloud-stream/generator.mts

  Line 80 in 433413f

  source.applyFromGradle?.({ script: 'gradle/kafka.gradle' });

• Pulsar:
  file: https://github.com/jhipster/generator-jhipster/blob/main/generators/spring-cloud-stream/templates/gradle/pulsar.gradle.ejs
  injection:

  generator-jhipster/generators/spring-cloud-stream/generator.mts

  Line 131 in 433413f

  source.applyFromGradle?.({ script: 'gradle/pulsar.gradle' });

• Liquibase:
  file: https://github.com/jhipster/generator-jhipster/blob/main/generators/liquibase/templates/gradle/liquibase.gradle.ejs
  injection:

  generator-jhipster/generators/liquibase/generator.mts

  Lines 396 to 412 in 433413f

  	injectGradle({ source, application }) {
  	if (!application.buildToolGradle || !this.injectBuildTool) return;
  	if (!application.javaDependencies) {
  	throw new Error('Some application fields are be mandatory');
  	}
  	source.addGradleProperty?.({ property: 'liquibaseTaskPrefix', value: 'liquibase' });
  	source.addGradleProperty?.({ property: 'liquibasePluginVersion', value: application.javaDependencies['gradle-liquibase'] });
  	source.addGradleProperty?.({ property: 'liquibaseVersion', value: application.javaDependencies.liquibase });
  	if (application.databaseTypeSql && !application.reactive) {
  	source.addGradleProperty?.({ property: 'liquibaseHibernate6Version', value: application.javaDependencies.liquibase });
  	}
  	source.applyFromGradle?.({ script: 'gradle/liquibase.gradle' });
  	source.addGradlePlugin?.({ id: 'org.liquibase.gradle' });
  	// eslint-disable-next-line no-template-curly-in-string
  	source.addGradlePluginManagement?.({ id: 'org.liquibase.gradle', version: '${liquibasePluginVersion}' });

Database are not split yet.
I am not a gradle expert, maybe you can improve even further.

[atomfrede]

Nice idea with the injection. Maybe we can use the mentioned gradle plugin mechanism for that. I will try something.

[atomfrede]

@mshima I think we can really leverage the current modularization approach and define and generate convention plugins which are than applied. That looks cleaner and easier to me compared to the apply from approach. Let me try something tonight

[atomfrede]

I really like the thing with the convention plugins. You can have look here. Need to figured out how to proceed with the node stuff and the dev/prod profile right now, but in general it looks very nice (for example)

plugins {
    id "com.github.node-gradle.node"
    id 'jhipster.common-conventions'
    id 'jhipster.gatling-conventions'
    id 'jhipster.cucumber-conventions'
    id 'jhipster.test-conventions'
    id 'jhipster.sonar-conventions'
    id 'jhipster.cache-conventions'
    id 'jhipster.docker-conventions'
    id 'jhipster.code-quality-conventions'
    id 'jhipster.liquibase-conventions'
    // jhipster-needle-gradle-plugins - JHipster will add additional gradle plugins here
}

Will try to create a PR in the next couple of days.

@mshima As we have removed deprecated deployments, can I safely remove the gae "profile" from gradle?

  gae: {
    desc: 'Deploy the current application to Google App Engine',
    removed: removedV8,
  },

[mshima]

@atomfrede I think we can close this.
Not everything migrated to convention plugins but it's enough.
Next step is probably open api generator that can be reused in micronaut blueprint.

[atomfrede]

Yes let's close it and open dedicated issues for the remaining things.