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

Create a "core" artifact #845

Open
jimschubert opened this issue Aug 18, 2018 · 5 comments
Open

Create a "core" artifact #845

jimschubert opened this issue Aug 18, 2018 · 5 comments

Comments

@jimschubert
Copy link
Member

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:

image

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.

@jmini
Copy link
Member

jmini commented Aug 23, 2018

I am not sure how I can add an idea to the list, but I think we should remove using System.setProperty(..) from our code.

It is ok to read them (requested for backward compatibility), but setting the values is a bad practice.
At the end they are some inputs options for the DefaultGenerator

Related issue: I have described how System properties are set by CodegenConfigurator.setSystemProperties() here: #811 (comment)

Should I open a new issue for this task?

@jimschubert
Copy link
Member Author

@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.

@jmini
Copy link
Member

jmini commented Dec 4, 2018

Removal of System.setProperty(..) is now tracked in #1597

jimschubert added a commit that referenced this issue May 4, 2019
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).
jimschubert added a commit that referenced this issue May 5, 2019
* [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
@jimschubert
Copy link
Member Author

Template Engine component is done via #6357

@jimschubert
Copy link
Member Author

"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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants