Skip to content

Guard the deliberately colliding artifact pairs with enforcer rules #384

Description

@zantvoort

Several artifact pairs deliberately ship classes with identical fully qualified names, one per classpath: storm-java21/storm-kotlin (26 types in st.orm.template and st.orm.repository), the two Spring Boot starters (the auto-configuration classes), storm-jackson2/storm-jackson3 (StormModule, the converter SPI), and the two metamodel processors. The design is intentional (storm-spring/src/main/java/st/orm/spring/impl/RepositoryProxyingPostProcessor.java:30-32 says so), but the only guard anywhere is one hand-written exclusion in storm-kotlin-spring/pom.xml, and only docs/json.md documents any pair.

What a user sees when both halves land on one classpath: on the module path, a hard LayerInstantiationException from the twin exports st.orm.template; on the classpath, a mixed Java+Kotlin Boot app gets whichever jar wins ordering and dies with a ClassCastException or NoSuchMethodError at first repository use, with nothing pointing at the cause.

Fix: add a maven-enforcer bannedDependencies rule to each member of each pair so the build fails with a sentence naming the conflict, and document the pairing rule centrally (installation docs), not just for Jackson.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions