Create a "core" artifact #845
Comments
|
I am not sure how I can add an idea to the list, but I think we should remove using It is ok to read them (requested for backward compatibility), but setting the values is a bad practice. Related issue: I have described how System properties are set by Should I open a new issue for this task? |
|
@jmini yeah I think that should be another card. Work from this card will be a breaking change, but removing setProperty should be done as soon as possible, imho. I would append that setProperty is used in the Gradle plugin, I think it's fine in this case. It shouldn't exist in the generator packages, though, because these can be consumed by other artifacts or tools. |
|
Removal of |
GeneratorMetadata offers an immutable object created via Builder pattern which allows generators to explicitly define their stability (stable, beta, experimental, deprecated) as well as a message to be shown during generation. This is a step toward: * Fleshing out the "Core" artifact (#845) * Providing a place to encapsulate feature-oriented metadata (#840) * Providing a means to communicate end of life scheduling (#116) This new structure, specifically the Stability property, allows us to offer future enhancements such as allowing users to filter down to only "Stable" generators via CLI, and eventually any compat table (see #503).
* [feat] Intro GeneratorMetadata (stability index) GeneratorMetadata offers an immutable object created via Builder pattern which allows generators to explicitly define their stability (stable, beta, experimental, deprecated) as well as a message to be shown during generation. This is a step toward: * Fleshing out the "Core" artifact (#845) * Providing a place to encapsulate feature-oriented metadata (#840) * Providing a means to communicate end of life scheduling (#116) This new structure, specifically the Stability property, allows us to offer future enhancements such as allowing users to filter down to only "Stable" generators via CLI, and eventually any compat table (see #503). * Mark deprecated generators as deprecated in-code * Re-export docs/generators.md
|
Template Engine component is done via #6357 |
|
"Global Options" and "Generation Options" components are completed via #2946. I'd updated these terms to "Workflow Settings" (rather than Global Options) and "Generator Settings" rather than "Generation Options" to better differentiate between the touch points. |
Description
There's currently no clearly defined "interface" between templates, extension points, or code generation.
If we extract model definitions and interfaces to a "core" artifact, this would reduce noise for those who want to extend and/or contribute to the project.
This would ideally be done after other work in the Separation of Concerns project in this repo.
Related PRs
Suggest a fix/enhancement
From #503:
In the above diagram, we'd include any models (codegen, options, template) or interfaces which may be consumed by users for creating custom generators or plugins. NOTE Template Definition above refers to a strongly-typed model that would replace the current
Map<String, Object>(not the resources defining templates); work for this is already started in #837.The text was updated successfully, but these errors were encountered: