Repository navigation
Move generic classes into codegen + codegen-roaster modules (phase 1) #349
Description
Subtask of #233 — the history-preserving extraction itself.
- New Maven artifacts:
codegen(framework-agnostic processing/codegen layer, package rootorg.javahelpers.codegen) andcodegen-roaster(Roaster backend implementingClassCodeGenerator). git mvof the decoupled generic classes (classgen/*,analysis/*,processing/logging/*,processing/CompilerOption, model types) into their final packages/modules — one move per commit where practical so Git rename detection andgit log --followkeep months-old history.BuilderExceptionbecomesCodeGenerationExceptionat the boundary.- Missing builder-side DTOs/enums/wrappers are created on the builder side rather than introducing backwards dependencies.
- POMs, imports,
META-INF/services, tests, CI, release config, coverage and example dependencies updated. - Acceptance:
simple-buildersbehavior and generated output byte-identical.
Activity
igel-devin-ai commentedon Oct 22, 2026
Package-layout candidate for the move:
processor.processing.logging(ProcessingLogger, PerformanceTracker, ActivePerformanceTracker, NoOpPerformanceTracker, PhaseHierarchy) may belong atprocessor.logginginstead — deferred from #299 review since it is an upstream package rename that is better collected here.poms: repoint model coverage exclusions to codegen.model (java-helper…
ci: allow ECL-2.0 and except codegen build plugins in dependency revi…
poms: exclude exception classes by *Exception.java pattern for covera…
build: drop explicit codegen dep, it arrives transitively via process…
poms: use *Exception.* glob for coverage exclusions (java-helpers#349)
[-]Move generic classes into simple-codegen + simple-codegen-roaster modules (phase 1)[/-][+]Move generic classes into codegen + codegen-roaster modules (phase 1)[/+]build: rename codegen artifacts to io.github.java-helpers.codegen:cod…
igel-devin-ai commentedon Oct 25, 2026
Scope note: before this move lands, #378 (PR #379) generalizes
BuilderProcessor's machinery into a reusable annotation-processing driver inside theprocessormodule (AbstractCodegenProcessor+AnnotationElementSpec/ProcessorOptionRegistry/CodegenTask/ProcessingTarget/SourceFormatterResolver, underorg.javahelpers.codegen.processing).Once that merges, this move will carry three artifacts instead of two, split at the
javax.lang.modelboundary (verified: only 7 codegen files touch JSR-269):io.github.java-helpers.codegen:codegen-core— javax-free: model, enums,ClassCodeGenerator/SourceFormatterSPI,GenerationPhases,GenerationIssueReporter,CodeGenerationException,ImportCollectorio.github.java-helpers.codegen:annotation-processing— everything JSR-269-bound:AnnotationProcessingContext/options/analysis + the new driver machineryio.github.java-helpers.codegen:codegen-roaster— backend on codegen-core, as beforeOpen boundary question tracked on #378:
GenerationEnvironmentwrapsProcessingEnvironment— (a) move the SPI pair intoannotation-processing, or (b) neutral env contract in codegen-core +ProcessingEnvironmentimpl in annotation-processing.