Update gradle documentation, split it into two pages.

[HerbertsVaadin]

Solves #4222

Changes:

• Removed the "Developing in Eclipse IDE" section - unnecessary, not Vaadin specific information, if you use Gradle, and have chosen to use Gradle, and use Eclipse, you probably know how to import and run gradle application in Eclipse IDE.
• Reduced requirements section to a note - unecessary to have so much detail.
• Reduced starter project contents to only gradle-related files
• Reduced section "The most important files and folders are as follows" to only reference gradle related files, since the rest is the same between other build tools.
• Simplified compile section, referenced configuration page
• Removed warning about Gretty + jcenter, as it is no longer relevant.
• Created new page under flow/configuration specific to Gradle configuration properties.
• Refactored Configuring repositories section, removed focus from pre-releases.
• Removed the build file "Other Configuration" section, as its no longer valid.

[github-actions]

AI Language Review

The updated document streamlines content by removing some detailed sections and focusing on essential tasks for creating, compiling, and running a Vaadin project with Gradle. It simplifies the requirements section, improves consistency in describing Gradle tasks, and updates Gradle and plugin versions.

1. "Requirements" Section:

   • The opening paragraph of the "Requirements" section now uses a note block, but still lists installation instructions for Gradle even if these are essentially optional due to the Gradle wrapper. It could be clearer by emphasizing the installation approach only for custom environments or situations not utilizing starter projects.

2. Removal of Detailed Sections:

   • The sections regarding incremental builds, developing in Eclipse IDE, and plugin configuration options have been removed in the new version. While this improves focus, there could be a benefit to maintaining access to some specific guidance within the document or linking to detailed configurations, especially for beginner users who might not be familiar with these resources.

3. Code Sample Updates:

   • The version numbers for plugins have been updated (org.gretty version '3.0.3' to 4.1.1, and com.vaadin version '20.0.0' to '24.9.0'), reflecting potential updates. Ensure users are clear that these are example versions and that they should verify the correct latest stable version.

4. Links to Detailed Documentation:

   • The old document provides more direct information on how large concepts, like Vaadin tasks, function. While perhaps overwhelming, these provided additional details for advanced users or specific use cases. Adding explicit links or footnotes to detailed sections in the Gradle or Vaadin documentation could help bridge this gap.

Overall, the revisions provide a more user-friendly guide but ensure that readers can easily find detailed references as needed, especially when specific configurations are omitted.

[HerbertsVaadin]

I think the remaining AI Language Review suggestions can be ignored, I think it's unaware that the original document has been split into two, and more focused / less-verbose approach of the document is desired.

[mcollovati]

Looking at the Vaadin 24.8 and 24.9 release notes, the minimum Gradle version is 8.7

Suggested change

	The Vaadin Gradle plugin requires Java SDK 17 or later, Gradle 8.5 or later.
	The Vaadin Gradle plugin requires Java SDK 17 or later, Gradle 8.7 or later.

[mcollovati]

It could be worth it adding that install happens only if Node is not already installed or if it does not match the minimum version required by Vaadin.

[mcollovati]

I'm not sure this option is needed for development. Ideally, for development there should be no need for any configuration.
What about changing the For development, the block is usually like this with something like An example configuration could be like this and use frontendHotdeploy = true in the snippet?

[mcollovati]

optimizeBundle is to enable the byte code scanner and make the bundle only contain frontend stuff that is actually used in the application. It has nothing to do with browser optimizations.

[mcollovati]

What about also mention mavenLocal() for artifact published only locally? However, this would probably make sense only when working on projects with mixed Maven and Gradle build tools.

[mcollovati]

nit: I'm not sure if we should suggest using an unpinned version. IMO, from a security point of view, I would always pin the exact version I want to use.

But this is not a blocker.

[mcollovati]

It looks like the Javadoc for Maven and Gradle prepare frontend task is outdated.

Looking at the prepare fronted code I can see the following

.createMissingPackageJson(true).enableImportsUpdate(false)
.enablePackagesUpdate(false).withRunNpmInstall(false)

So it seems that prepare frontend:

• creates package.json is necessary but does not update it
• resources inside JAR files are copied into src/main/frontend/generated/jar-resources, not in node_modules

[mcollovati]

I'm not so skilled in Gradle, but at least our starter seems to provide a different plugin configuration.

It has the version pinned in settings file (https://github.com/vaadin/base-starter-gradle/blob/9a8284e07d02e0f6f346b49accbebd902e50865a/settings.gradle#L7) and only definition in the build script (https://github.com/vaadin/base-starter-gradle/blob/9a8284e07d02e0f6f346b49accbebd902e50865a/build.gradle#L15), no apply at all.

So the question is if it would be enough to set the snapshot version in settings in combination with the configuration of the pre-release repository.

I'm not sure what we should suggest in the docs. Maybe @mvysny can provide some insight