Clarify migration-only intent in Jackson migration Javadocs and documentation (before GA) #1550
Description
Context
In #1539 we introduced Jackson 2 to Jackson 3 migration wiring for SQS. The migration types are transitional (@deprecated(forRemoval = true)) and should not be treated as end-user extension points.
SQS acceptance criteria for the migration:
• CNFE/classpath risks are mitigated
• No new long-term supported user-facing APIs or extension points are introduced as part of the migration
• No loss of existing user functionality
Problem
Some Javadocs and reference documentation currently read like a supported long-term customization/extension surface, for example suggesting users should implement or provide migration types as part of normal configuration. This is at odds with the second acceptance criterion above and risks confusing users about the intended supported API surface.
Scope
Documentation only (Javadocs and reference docs). No behavioral or functional changes.
Acceptance criteria for this issue
• Javadocs on migration types explicitly communicate “migration-only / transitional / scheduled for removal” intent.
• Wording does not imply a long-term supported extension point or encourage user implementation.
• Method-level Javadocs are concise and match intent.
• Reference documentation describes migration guidance primarily in terms of the long-term supported configuration surface (for example MessagingMessageConverter, where applicable), and treats migration types as internal/transitional wiring.
• Documentation avoids prescribing patterns that could become a de facto long-term contract.
Links
• PR: #1539
• Relevant migration types: JacksonMessageConverterMigration, JacksonJsonMessageConverterMigration, LegacyJackson2MessageConverterMigration (and related)
Plan
Docs-only refinement before GA.