Configure GEARS generator - XLRIT/gears GitHub Wiki
- 1. Table of content
- 2. gears.json
- 3. resources/application.yml
- 4. Override configuration just before runtime
Part of the configuration is done in the gears.json
which should be in the root of your project folder. This file contains the options you give to the GEARS development tools, e.g. the generator and the test scenario runner. Below is an example followed by some explanation:
{
"groupId": "nl.some_client",
"projectName": "some_tool",
"projectVersion": "0.12.0-SNAPSHOT",
"generatorVersion": "0.79",
"files": {
"specs": ["specs/*.sn"],
"scenarios": ["scenarios/*.scenario", "scenarios/**/*.scenario"],
"data": ["data/*.sql"]
},
"generatorOptions": {
"tableNamePrefix": "GPT"
},
"runtimeVersion": "0.79",
"frontendVersion": "0.50.0",
"runnerVersion": "0.16",
"plugins": [
"com.xlrit.gears.runtime:gears-runtime-plugin-jasper",
"com.xlrit.gears.runtime:gears-runtime-plugin-scim",
"com.xlrit.gears.runtime:gears-runtime-plugin-mail"
]
}
In the below table all the options are explained:
Option | Explanation |
---|---|
groupId: | The groupId in pom.xml file. See maven for more info on maven pom.xml files. |
projectName: | The generated target/<projectName> and the artifactId in pom.xml file.. |
projectVersion: | The version in pom.xml file. |
generatorVersion: | Version of the GEARS generator that should be used. |
files: | Optional paths to were specs files, (test) scenario files and data files are located. paths are absolute or relative to the project folder. You can use wildcards such as * for file patterns. The pattern ** indicates any folder path no matter how deep. TODO: add default values. |
generatorOptions: | Optional options you can give the GEARS generator. Being checkAttributes (whether attributes in the specifications are used correctly; default true ). strictExists (whether exists in the specifications is used correctly; default true ). tableNameQuote (whether generated table names are surrounded by quotes which allows for table names that match SQL keywords, such as ORDER ; default false ). tableNamePrefix (prefixes all generated tables with this prefix; default empty string "" ) |
runtimeVersion: | Version of the Runtime used. |
frontendVersion: | Optional version of the frontend used. By default the most recent frontend in the runtime is used. |
runnerVersion: | Version of the test scenario runner (which is also used to load data). Must be provided if you use the runner. |
plugins: | plugins your application needs. Each plugin your application needs must be provided. They will be added as dependencies in the pom.xml file. Well known plugins are: mail to enable mail sending jasper to enable generating reports, scim to enable SCIM for syncing users and rights from an identity provider such as Azure Active Directory
|
This file configures the application that you are going to generate. It will be its default configuration. Below is an example application.yml
followed by an explanation:
gears:
init:
create-demo-users: true
frontend:
name: Some Tool
theme: some_client
menu-overrides: '{ "messages": false, "search": false, "admin": false, "reports": false }'
document:
output-dir: C:\tmp
#mail:
# enabled: true
# cron: 0/10 * * ? * * *
testing:
enabled: true
spring:
banner:
location: classpath:banner-sometool.txt
datasource:
url: 'jdbc:h2:mem:gears;DB_CLOSE_ON_EXIT=FALSE'
# url: 'jdbc:postgresql://localhost:5432/databasename?user=postgres&password=secret'
h2:
console:
enabled: true
graphql:
servlet:
async-timeout: 120000
In the below table the most relevant options are explained:
Property | Explanation |
---|---|
gears.init.create-demo-users |
When true a set of users for demonstration purposes are created. Now having user names: admin , system , anonymous , demo , having passwords that match the user names and email addresses <user name>@xlrit.local . Should be set to false for production systems. |
gears.frontend.name |
Title of the Web application (as displayed in the browser). |
gears.frontend.theme |
Name of the theme used. |
gears.frontend.menu-overrides |
Defines which menus should not be displayed. |
gears.document.output-dir |
the full path to the folder where output documents (e.g. reports) will be placed. |
gears.testing.enabled |
when true the test scenario runner can be used. This also opens up the GraphQL API to the whole world. Because that would pose a security risk for productional systems, the default value is false . |
spring.banner.location |
a ASCII art banner that will be placed in the log when you start your application. You can create nice ASCII art banners here. |
spring.datasource.url |
Database URL. The in memory H2 DB is enabled. The disabled one below it is an example of a local postgres DB. This is often used for data migration purposes. |
spring.h2.console.enabled |
When true the default in memory DB console can be used. For JDBC URL use the default value jdbc:h2:mem:gears . |
graphql.servlet.async-timeout |
Set max timeout of any graphql API call in milliseconds. When not set the default is 30 seconds. |
The default configuration can be found here: server/src/main/resources/application.yaml.
All configurations in application.yml
can be overridden providing the options when starting the application. Either by setting environment variables or starting it with the command line.
You can override the default options by setting environment variables. As an example we use the option gears.document.output-dir
. You could simply add an environment variable called GEARS_DOCUMENT_OUTPUT-DIR (replace the dots with underscores) and fill its value with what you like.
Don't forget: when using VS Code, all instances of VS code must be restarted before changes to environment variables will take effect.
You can override the default options by adding options when starting up the application from the command line. As an example we use the option gears.document.output-dir
. You could simply start up the application like this:
`java -jar target\order_products-0.1-SNAPSHOT.jar --gears.document.output-dir=C:\Windows\Temp`
Configuration profiles are used to group together common configuration options. They are passed to the application upon start
mvn spring-boot:run -Dspring-boot.run.profiles=local,mail
To enable support for sending e-mails, you need two things:
- Add the mail-plugin (
com.xlrit.gears.runtime:gears-runtime-plugin-mail
) as shown in paragraph 2. - Activate the "mail" configuration profile. This will set the property
gears.mail.enabled
to true.
The mail plugin supports two modes: "direct" and "batch".
In "direct" mode, which is the default, mails are sent immediately when they are published. This is well suites for simple applications and demos.
In "batch" mode the system regularly checks for the presence of published mails using an interval configured using the property gears.mail.cron
, which is set to "0 10 * * * ?" by default, meaning every 10 minutes. This is better suited for larger applications.
All available configuration properties for the mail plugin are shown below:
Property | Default | Explanation |
---|---|---|
gears.mail.enabled |
false | When true the application will actually send mail using a SMTP server. If false all mail will not be sent and simply stay in the SYS_MAIL table. |
gears.mail.mode |
direct | Whether to send mails immediately upon publish or scheduled in batches using the following two configuration properties. |
gears.mail.batch-size |
10 | The maximum number of mails that are sent in each batch in batch mode. |
gears.mail.cron |
0 0/10 * * * ? | A cron schedule expression that tells with what schedule the mails will be sent. A cron expression consists of 6 items seperated by spaces. The 1st defines seconds, the 2nd minutes, the 3rd hours, the 4th days, the 5th months, the 6th day of week). See CRON expression generator to understand a CRON expression or create one. Note that: by default the runtime cannot have an interval of less than 10 seconds. This can be overridden, but requires reconfiguring the process engine that the runtimes uses (currently "Flowable"). |