Upgrading from 2.2

Change the version, nothing else

build.gradle

- implementation      'io.elasticore:elasticore-base:2.2.260703'
+ implementation      'io.elasticore:elasticore-base:3.0.261022-rc1'

Leave env.yml, build.gradle and the model files as they are. The generated sources do not change - apart from a few places where 2.x had a defect, listed in the history. Every new 3.0 capability (DDD, hexagonal, Kotlin, TypeScript) is switched on only when declared; a project that declares nothing goes down the same code path as 2.x.

This is checked on every pull request: the rule engine's output for the 2.x reference project is compared with 2.x's over all 229 files (0 differ / 0 missing / 0 extra, the four files a 2.x bug fix changes accepted by name, one more differing only in import order).

What still changes (all bug fixes)

	2.x	3.0	What to do
schema.yml	at the repository root, platform encoding (MS949 on Korean Windows)	next to its blueprint, UTF-8	delete the old one at the root - it is no longer updated
generated code in some multi-module builds	leaked to the repository root	in the module that holds the model	delete the stray files at the root
DTOUtils.getMetaInfo(Class)	raw type warning	getMetaInfo(Class<T>)	nothing - the same binary signature
new DSL validation	-	only for DDD syntax (domainService, uses:)	nothing: a 2.x model has none, so -Pmode=valid does not start failing

Hand-edited generated files stay protected as in 2.x: a change is recognised by the content hash, and a file with // Initially generated by ElastiCORE; no longer managed is not rewritten after its first generation.

Using 3.0 features (optional)

Only when you want them - a domain at a time if you like:

1. Add the elasticore { } block to build.gradle with an architecture (and language), which switches the build to the rule engine (elcore3):

   elasticore {
       architecture = 'hexagonal'    // or 'ddd'
       language     = 'java'
   }

2. To give one domain other rules, name them in its env.yml. They take effect only when the build runs the rule engine - an elasticore { } block with architecture, language or rules, or ./gradlew elcore3; the 2.x generator ignores them:

   elasticore:
     config:
       publisher:
         rules: [ddd-springboot]

Bundle	Gives
jpa-springboot	the same as before (as if nothing were declared)
ddd-springboot	aggregate boundaries, invariants, domain events, value objects
hexagonal-springboot	the above + inbound ports and the hexagonal package layout
*-kt	the Kotlin editions
ts-model	DTOs, enums and a typed REST client for the browser

like ignores case on v3

In the v3 bundles (hexagonal, DDD, -Pv3, every Kotlin build) @search(like) on text is case-insensitive (%__%). To keep 2.x's case-sensitive search, write @search(%_%).

Going back is removing the publisher.rules line (or the block). 3.0 leaves no state behind - only the old files removed above would be generated in the wrong place again on 2.x.

Spring Boot 4

3.0 supports Spring Boot 4 and Spring AI 2.0 (2.2 stops at Spring Boot 3). Switch the runtime from elasticore-springboot3 to elasticore-springboot4 and the Boot plugin to 4.x; ElastiCORE reads the version and writes enums and the outbox for Jackson 3. See Spring Boot 3 and 4.

FAQ

• All at once? No - publisher.rules is per domain.
• Multi-module? Yes: elasticore.modules works with both entry points, and module:// namespace redirects stay.
• Rolling back? Change the version back.

The 2.2 documentation stays available: ElastiCORE 2.2.