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

Improve gradle docs by adding kotlin snippets #45344

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

Malandril
Copy link
Contributor

@Malandril Malandril commented Jan 3, 2025

Improve the quarkus gradle docs by adding kotlin code snippets next to the groovy ones where appropriate.
Also use version attributes instead of hard coded versions in some cases.

We could also improve by switching the first language on display docs from groovy to kotlin as now it is the default for new gradle projects since Gradle 8.2 .

Copy link

quarkus-bot bot commented Jan 3, 2025

Thanks for your pull request!

Your pull request does not follow our editorial rules. Could you have a look?

  • title should preferably start with an uppercase character (if it makes sense!)
  • title should not start with chore/docs/feat/fix/refactor but be a proper sentence

This message is automatically generated by a bot.

@quarkus-bot quarkus-bot bot added area/docstyle issues related for manual docstyle review area/documentation labels Jan 3, 2025
@Malandril Malandril changed the title docs: Improve gradle docs by adding kotlin snippets Improve gradle docs by adding kotlin snippets Jan 3, 2025
@Malandril Malandril marked this pull request as ready for review January 3, 2025 01:00
Copy link

github-actions bot commented Jan 3, 2025

🎊 PR Preview 0d6a99e has been successfully built and deployed to https://quarkus-pr-main-45344-preview.surge.sh/version/main/guides/

  • Images of blog posts older than 3 months are not available.
  • Newsletters older than 3 months are not available.

This comment has been minimized.

This comment has been minimized.

Copy link
Member

@gsmet gsmet left a comment

Choose a reason for hiding this comment

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

Sorry for not replying earlier. I was skeptical at first as it requires more maintenance but given they are switching to Kotlin first, it's probably a good idea to consider this, or at least a version of this.

You will see some comments inline: the thing is that if we can reduce the number of alternatives by using the same approach we had for the extension in guides (https://quarkus.io/guides/validation#creating-the-maven-project), it would have my preference.

Also, can you clarify when kts became the default? If it's in a current Gradle version, I think I'm fine with making it the first alternative.

docs/src/main/asciidoc/aws-lambda.adoc Show resolved Hide resolved
----
pluginManagement {
repositories {
mavenCentral()
gradlePluginPortal()
}
plugins {
id 'io.quarkus.extension' version "${quarkus.version}" <1>
id 'io.quarkus.extension' version "{quarkus-version}" <1>
Copy link
Member

Choose a reason for hiding this comment

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

The variable is not available here? I think we are supposed to have a variable in the generated project?

Copy link
Contributor Author

@Malandril Malandril Jan 9, 2025

Choose a reason for hiding this comment

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

There is no project generation available for an extension using gradle with quarkus cli, that's why i used the quarkus version variable from the ascii doc here.
We could add to the page a gradle.properties to have the same behaviour as a non extension quarkus application and reuse the same variables.

docs/src/main/asciidoc/building-my-first-extension.adoc Outdated Show resolved Hide resolved
docs/src/main/asciidoc/building-my-first-extension.adoc Outdated Show resolved Hide resolved
gradlePluginPortal()
}
plugins {
id("io.quarkus.extension") version "{quarkus-version}" <1>
Copy link
Member

Choose a reason for hiding this comment

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

Same question here about the variable?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Same answer as previous one, and with kotlin it would have to be renamed to quarkusVersion

docs/src/main/asciidoc/building-my-first-extension.adoc Outdated Show resolved Hide resolved
implementation platform("io.quarkus:quarkus-bom:${quarkus.version}")

implementation 'io.quarkus:quarkus-arc-deployment'
implementation platform("{quarkus-platform-groupid}:quarkus-bom:{quarkus-version}")
Copy link
Member

Choose a reason for hiding this comment

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

Same here about the variable?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Same answer as previous one. Would need a new file gradle.properties file in the doc.

@Malandril
Copy link
Contributor Author

You will see some comments inline: the thing is that if we can reduce the number of alternatives by using the same approach we had for the extension in guides (https://quarkus.io/guides/validation#creating-the-maven-project), it would have my preference.

I don't really understand, you mean to avoid having two versions of the gradle build, and keep only one ?

Also, can you clarify when kts became the default? If it's in a current Gradle version, I think I'm fine with making it the first alternative.

It became the default since gradle 8.2: https://blog.gradle.org/kotlin-dsl-is-now-the-default-for-new-gradle-builds

Starting with Gradle 8.2, creating new builds using gradle init defaults to generating Gradle builds using Kotlin DSL

Copy link

quarkus-bot bot commented Jan 9, 2025

Status for workflow Quarkus Documentation CI

This is the status report for running Quarkus Documentation CI on commit e24d597.

✅ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/docstyle issues related for manual docstyle review area/documentation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants