Turning default rules off and choosing a bundle

Team rules do not only add. There are three ways to leave out what ElastiCORE makes that does not fit your team.

What you want	How
Turn one default rule off entirely (e.g. every @Comment)	suppress: [rule id]
Not make a kind of file at all	suppress every rule of that target, or ctx(e).dontMake() in a team rule
Leave out just one thing a rule does (e.g. only @DynamicUpdate)	removeClassAnnotation, field(f).removeAnnotation, removeField in a team rule
A different bundle for one domain	publisher.rules in env.yml

1. Finding the rule id

./gradlew elcore3 -PlistRules

This makes no files; it shows, per domain, the rules that run now, per kind of file (target), in the order they run.

  entity
        5 head  v3-class-annotations                 JpaEntityAnnotationRules
        5 field jpa-field-desc                       JpaEntityBaseRules
        …
  apiErrors
       10 once  spring-api-errors                    ApiErrorRules

Column	Means
entity, apiErrors …	the target - the kind of file the rule writes. The same as the first word of each line of the generation log
5, 10	order
head / field / tail / once	the phase. once is per domain, enum or port
spring-api-errors	the rule id - the name you use in suppress
ApiErrorRules	the class that holds the rule

2. suppress - turning a rule off

In one domain only:

blueprint/petstore/env.yml

elasticore:
  config:
    publisher:
      suppress: [jpa-comment]     # no more @Comment on entity fields

In every domain (combined with the suppress in each env.yml):

build.gradle

elasticore {
    suppress = ['jpa-comment']
}

• suppress accumulates. What the build lists and what the domain lists are all turned off.
• Turn off every rule of one kind of file and that file is not made (SKIP(dontMake) in the generation log).
• Developer's files already made (controllers, error handlers and so on) are not deleted. Delete them yourself if you do not need them.

Turning off that changes behavior

For example, if a company-wide @RestControllerAdvice makes you turn off spring-api-errors (the XxxApiErrors made per domain), the responses that file decided - 404 for a missing target, 409 for a duplicate or a state conflict, 422 for a business rule violation - must be decided by the company handler (500 otherwise). The refusals before the controller (a body that is not JSON, a value of the wrong type) go with it, so put @Import(io.elasticore.springboot3.validation.RequestShapeErrors.class) on the company handler.

What you must not turn off

The rules that fill a file's skeleton - the *-vars and *-file rules that fill slots such as ${packageName}, ${className} and ${importList} (v3-file-vars, v3-dto-file, controller-vars …, usually 90 tail in -PlistRules). Turn only some of them off and the slots stay empty and the file breaks. Use suppress to turn off a rule that "adds something more", or to turn off every rule of a file and leave the whole file out.

3. Leaving out just one thing a rule does

suppress works per rule. v3-class-annotations adds @Entity, @Table, @DynamicUpdate … together, so it cannot be turned off. In that case a team rule removes just one afterwards. Team rules run after the default rules have finished, so what was removed does not come back.

    /** Takes one annotation the built-in rules put on every entity back off. */
    @Rule("ps-no-dynamic-update")
    void noDynamicUpdate(EntitySpec e) {
        ctx(e).removeClassAnnotation("org.hibernate.annotations.DynamicUpdate");
    }

In the same way: ctx(e).field(f).removeAnnotation("…"), ctx(e).removeField(f), ctx(e).dontMake(). (@DynamicUpdate can also be left out in the DSL: @dynamicupdate(false) in the entity's meta. For one entity, use the DSL; for every entity, a rule.)

4. Choosing a bundle per domain - publisher.rules

Most projects do not need this. architecture and language in build.gradle choose the bundle, and rules = [...] adds team rules after it. Write it in env.yml when one domain is to be generated differently.

blueprint/legacy/env.yml

elasticore:
  config:
    publisher:
      rules: [jpa-springboot-v3, com.example.rules.PetstoreRules]

	rules in build.gradle	publisher.rules in env.yml
Bundle	kept, and added after	replaced - the bundle name must be written too
Scope	every domain	that domain only
Kotlin	the bundle for the language, automatically	write the -kt bundle yourself, or publisher.rules.kt
TypeScript	not affected	publisher.rules.ts, separately

A name is one of three: a bundle (hexagonal-springboot), a rule set (ossie-export), or the full class name of a CodeRules. A domain's publisher.rules replaces that domain's bundle, and the build's rules = [...] is added after it either way - in the example above, if PetstoreRules is also in the build, it can be left out of env.yml. The list of bundles is in The rule engine.

If the hexagonal files disappeared after you wrote rules: in env.yml, you left out the bundle name. Put team rules meant for every domain in the build's rules - there is nothing to get wrong.