Skip to content

(wip) refactor(optimizer-analyzer): split AnalyzerApplication into apps/optimizer/analyzerapp#602

Merged
mkuchenbecker merged 1 commit into
mkuchenb/optimizer-3from
mkuchenb/optimizer-3-app-split
May 27, 2026
Merged

(wip) refactor(optimizer-analyzer): split AnalyzerApplication into apps/optimizer/analyzerapp#602
mkuchenbecker merged 1 commit into
mkuchenb/optimizer-3from
mkuchenb/optimizer-3-app-split

Conversation

@mkuchenbecker
Copy link
Copy Markdown
Collaborator

Status

(WIP) — inspection branch on top of mkuchenb/optimizer-3 (PR #533). Splits the analyzer into library + deployable.

Summary

Library/deployable split:

  • services/optimizer/analyzer/ — library (analysis logic; AnalyzerRunner, OperationAnalyzer, CadencePolicy, CadenceBasedOrphanFilesDeletionAnalyzer)
  • apps/optimizer/analyzerapp/ — deployable Spring Boot wrapper (just AnalyzerApplication + application.properties)

The analysis code stays in services/; only the @SpringBootApplication entry point moves to apps/.

Why analyzerapp and not analyzer as the leaf name

Two Gradle leaf projects both named analyzer — one at :services:optimizer:analyzer, one at :apps:optimizer:analyzer — produced a self-referential compileJava → compileJava cycle. Disambiguating the apps leaf to analyzerapp avoids it. The exact Gradle mechanism wasn't pinned down (could be the leaf collision, could be the also-colliding implicit parent at :apps:optimizer vs explicit :services:optimizer), but the rename is the smallest change that makes it build.

Build changes

services/optimizer/analyzer/build.gradle:

  • api project(':services:optimizer') so OperationTypeDto, repos, etc. are visible on consumers' compile classpath.
  • bootJar { enabled = false } — no @SpringBootApplication here anymore.
  • jar.archiveClassifier = '' so the library publishes analyzer.jar.

apps/optimizer/analyzerapp/build.gradle (new):

  • openhouse.springboot-ext-conventions + Spring Boot 2.7.8 plugins.
  • implementation project(':services:optimizer:analyzer') + Spring Boot starter + JPA + MySQL driver.

settings.gradle: include ':apps:optimizer:analyzerapp'.

Testing

  • ./gradlew :services:optimizer:analyzer:test — 20 tests green.
  • ./gradlew :apps:optimizer:analyzerapp:bootJar — produces build/analyzerapp/libs/analyzerapp.jar.

What does NOT change

  • Package: every class keeps com.linkedin.openhouse.optimizer.analyzer. AnalyzerApplication's @SpringBootApplication component-scan picks up the library classes because they sit in the same package, just in a different module on the classpath.
  • The scheduler (opt-4) is unchanged in this PR.

🤖 Generated with Claude Code

…imizer/analyzerapp

Library/deployable split:
- services/optimizer/analyzer/    — library (analysis logic, no main class)
- apps/optimizer/analyzerapp/     — deployable Spring Boot wrapper (only
                                    AnalyzerApplication + application.properties)

Why "analyzerapp" instead of "analyzer" as the leaf name: two Gradle leaf
projects both named "analyzer" (one at :services:optimizer:analyzer, one at
:apps:optimizer:analyzer) produce a self-referential compileJava cycle.
Disambiguating the leaf name avoids it.

Build changes:
- services/optimizer/analyzer/build.gradle:
  - 'api project(:services:optimizer)' so OperationTypeDto / Repository
    types in the analyzer's public API are visible to consumers.
  - bootJar disabled — no @SpringBootApplication here anymore.
  - jar.archiveClassifier = '' so the lib produces a plain analyzer.jar.
- apps/optimizer/analyzerapp/build.gradle (new):
  - springboot-ext-conventions + boot 2.7.8 plugins.
  - implementation project(:services:optimizer:analyzer) + minimal Spring
    Boot deps + MySQL driver.
- settings.gradle: include ':apps:optimizer:analyzerapp'.

Tests pass: ./gradlew :services:optimizer:analyzer:test (all 20 green).
bootJar produced: build/analyzerapp/libs/analyzerapp.jar.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
@mkuchenbecker mkuchenbecker force-pushed the mkuchenb/optimizer-3-app-split branch from 2875d6b to acc6bb9 Compare May 27, 2026 04:46
@mkuchenbecker mkuchenbecker marked this pull request as ready for review May 27, 2026 04:47
@mkuchenbecker mkuchenbecker merged commit adbff95 into mkuchenb/optimizer-3 May 27, 2026
mkuchenbecker added a commit that referenced this pull request May 27, 2026
Brings PR #602's analyzer library/deployable split:
- services/optimizer/analyzer/   (library)
- apps/optimizer/analyzerapp/    (deployable)

Plus the pagination removal in AnalyzerRunner (all three pre-load reads
now use Pageable.unpaged() — aligned per-page pagination was incorrect).

Settings.gradle resolved to include the three relevant lines:
  :services:optimizer:analyzer
  :apps:optimizer:analyzerapp
  :apps:optimizer:scheduler   (will be split similarly in the next commit)
mkuchenbecker added a commit that referenced this pull request May 27, 2026
…r + apps/optimizer/schedulerapp; drop pagination

Mirrors the analyzer's library/deployable split (PR #602) on the scheduler:

- services/optimizer/scheduler/   (library; bootJar disabled, jar.classifier='')
- apps/optimizer/schedulerapp/    (deployable: SchedulerApplication + application.properties)

settings.gradle:
- drop  ':apps:optimizer:scheduler'
- add   ':services:optimizer:scheduler'
- add   ':apps:optimizer:schedulerapp'

Package unchanged: com.linkedin.openhouse.optimizer.scheduler.

Substantive change in SchedulerRunner.schedule():
- Drop @value("\${optimizer.repo.default-limit:10000}") + defaultLimit field.
- Switch both reads to Pageable.unpaged():
  - the PENDING-load operationsRepo.find(...)
  - the post-claim re-query for SCHEDULING rows tagged with this cycle's
    scheduledAt watermark
- The previous PageRequest.of(0, defaultLimit) pattern was the same bug we
  fixed on the analyzer: a single page is fetched and anything past it is
  silently dropped. Correctness requires the full set per cycle; working
  set bounded by count(matching rows in this cycle), tracked in BDP-102738.

application.properties drops optimizer.repo.default-limit (no longer used).

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant