Change projects organization

[KarenBaliero]

Analysis of the Demo Repository Structure

Context

This PR establishes the directory architecture for the demonstration projects. An analysis was performed to define the best approach for organizing multiple demos in a single repository, considering the following goals:

• Ease of use for devs: The target audience needs a clear and straightforward experience.
• Maintainability: The structure must be easy to manage.
• Future flexibility: It must allow new demos, potentially in other languages, to be added without difficulty.

Options Considered

Three main approaches for organizing the Gradle projects were analyzed:

1. Simple Folders : Each demo is a 100% independent and autonomous project in its own folder.
2. Gradle Multi-Project Build: A single root Gradle build that manages all demos as subprojects, centralizing the build logic.
3. Gradle Composite Builds: A hybrid model that allows independent builds to share logic explicitly (includeBuild).

Comparative Analysis

Criteria	Simple Folders	Multi-Project Build	Composite Builds
Simplicity (Student)	✅ Excellent	⚠️ Fair	👍 Good
Project Isolation	✅ Total	❌ Low	✅ High
Future Flexibility	✅ Total	❌ Low	👍 Good
Centralized Maintenance	❌ Low (duplication)	✅ High	✅ High (with higher complexity)

Decision

The chosen approach is Simple Folders.

Justification

The decision was made by prioritizing the student experience and long-term flexibility:

• Simplified Student Experience: This is the most intuitive structure. A student can clone the repository, navigate to a demo's folder, and open it as a standard, self-contained project without worrying about parent builds or inherited configurations.
• Future-Proof: It perfectly meets the requirement that future demos might be in other languages (e.g., Python, JavaScript), as each folder is completely technology-agnostic from the others.
• Total Independence: An error, dependency, or specific configuration in one demo does not affect any other, ensuring that each example works reliably in isolation.

While this approach results in some configuration duplication in the build.gradle.kts files, the gain in simplicity, flexibility, and robustness for the target audience (students) far outweighs this maintenance cost.

References

• Official Gradle Documentation on Multi-Project Builds
• Official Gradle Documentation on Composite Builds