enhancement/bento-35: Use Gradle convention script plugins.#36
enhancement/bento-35: Use Gradle convention script plugins.#36philliplbryant wants to merge 8 commits into
Conversation
There was a problem hiding this comment.
Registers a task for compiling classes for all test types.
There was a problem hiding this comment.
In a simpler gradle build, you have gradlew test which compiles the necessary classes compileTestJava then runs them test. What's the difference / use-case here?
There was a problem hiding this comment.
I apologize for not clarifying this sooner. In hindsight, I should have waited to include this until I had pushed the code containing the tests I’ve written for the persistence framework, as they will ultimately depend on this setup. To streamline this review, I intentionally removed several unused components, but I mistakenly overlooked this one — my apologies for the oversight.
To provide more context, my approach is to organize tests into "suites" based on their specific purposes and execution requirements. For instance, some tests are designed to run in parallel, while others are not. Similarly, certain tests require a graphics environment or other specialized configurations. Each suite is paired with its own convention scripts, which define the necessary test tasks and configurations for that suite. Lifecycle tasks — such as allClasses (ALL_CLASSES_TASK_NAME) in bento.project.build-lifecycle.gradle — are used to aggregate these individual tasks, enabling all related tasks to be executed with a single command. In a similar vein, a checkAll task is planned to execute a series of check*** tasks, running all tests across all test suites (and optionally gathering reports such as JaCoCo, if desired).
At this stage, I understand that this structure may not appear entirely necessary yet. However, as I continue to incorporate additional code for the persistence framework — which introduces four distinct types of test suites/tasks — I believe this approach will become increasingly valuable.
Given this context, would you prefer that I remove this for now and reintroduce it later, once the relevant tests and test suite conventions are fully integrated? I’d be happy to adjust based on your preference.
philliplbryant
left a comment
philliplbryant
left a comment
There was a problem hiding this comment.
@Col-E, do you have any feedback for this pull request?
|
Hectic week on my end, sorry for the lack of attention |
|
No worries; just making sure the review |
|
Took a look locally and made some changes to fit repo style a bit closer: changes.patch Gist is mostly stylistic changes. I'll pull a few comments out from here that are noteworthy. |
| // Name JARs using full project name, based on the project path. | ||
| // Otherwise, we might get JARs with the same names that will collide | ||
| // when aggregated by tasks like an installer task. | ||
| def jarBaseName = | ||
| project.path | ||
| // Delete the leading ':' | ||
| .substring(1) | ||
| // Replace the remaining ':' with '.' | ||
| .replace(':', '.') |
There was a problem hiding this comment.
Can be more succinctly described: Extract artifact Id from directory name.
There was a problem hiding this comment.
I 'm not clear what you have in mind. I could set the artifact ID (I think we might have to actually do so for multiple IDs if we also publish source and JavaDoc JARs)?
This is a carry-over from a much larger project my team manages. We have a legacy project (30+ years in the making) and change is a lot slower than we'd like. We have 450 modules and we have frequently encounter issues aggregating those JARs to obfuscate and deploy them. That is not (and hopefully will not ever be) an issue with a smaller project like this - which is being developed using best practices unknow to us at the time much of our codebase was written.
Would you prefer I just use the module name without changing it, refactor it to use this convention but use it elsewhere, or do you have something else in mind?
2 participants
These changes modify Gradle files to use convention script plugins (in lieu of
allprojectsandsubprojectsblocks). This is done in preparation for adding modules for docking layout persistence.