RFC (Camel 4.10) CAMEL-21080: removing legacy methods

[orpiske]

This is a preview of the changes for the CamelTestSupport class to remove the deprecated methods. It changes the class to use the configuration builders (for the test and the context).

To help with the migration, it introduces 3 new interfaces:

• LegacyBuiltinAssertions
• LegacyDebug
• LegacyTestSupport

The idea is that users that want to continue using the deprecated methods can implement those interfaces and avoid changing much of their code (apart from: 1. adjusting the visibility of the methods and 2. adding the interfaces to their test classes).

Alternatively, for users that want to perform a complete migration away from the deprecated methods, they can use the configureTest and configureContext methods (introduced on Camel 4.9) to do the test and camel context configuration.

As this is for 4.10, and the purpose is to gather feedback, the documentation is not yet available but it should look more or less like this:

_You only need to migrate from the old API to the new API, if you are customizing the test or the camel context and/or if you have been using any of the deprecated methods. In such case, you have to modify the code to implement the configureTest and/or configureContext methods and migrate from the deprecated methods. The table below lists the methods that need to be migrated. _

Old method	New method
isUseRouteBuilder	testConfiguration().withUseRouteBuilder()
isDumpRouteCoverage	testConfiguration().withDumpRouteCoverage()
isUseDebugger	camelContextConfiguration().withBreakpoint()

(... all other methods)

If you wish to continue using the old API methods, the code comes with 3 interfaces to help you:

• LegacyBuiltinAssertions
• LegacyDebug
• LegacyTestSupport

These interfaces retain the old methods and come with pre-configured configureTest andconfigureContext methods that mimic the legacy behavior. In such case, you only need to adjust the visibility of the methods in your test classes.

Obs.: I am leaving on PTO for several days, so I may take a while to reply.

[github-actions]

🌟 Thank you for your contribution to the Apache Camel project! 🌟

🤖 CI automation will test this PR automatically.

🐫 Apache Camel Committers, please review the following items:

• First-time contributors require MANUAL approval for the GitHub Actions to run

• You can use the command /component-test (camel-)component-name1 (camel-)component-name2.. to request a test from the test bot.

• You can label PRs using build-all, build-dependents, skip-tests and test-dependents to fine-tune the checks executed by this PR.

• Build and test logs are available in the Summary page. Only Apache Camel committers have access to the summary.

• ⚠️ Be careful when sharing logs. Review their contents before sharing them publicly.

[squakez]

I wonder if we can have a deprecation notice time and make the legacy coexists while the new methods are working. In this way we guarantee backward compatibility and warn the user to move their test to the new method.

[orpiske]

I wonder if we can have a deprecation notice time and make the legacy coexists while the new methods are working. In this way we guarantee backward compatibility and warn the user to move their test to the new method.

Unfortunately the @deprecated doesn't have a field to add that, but maybe we could include the forRemoval=true on the @deprecated annotations we currently have on CamelTestSupport.

[orpiske]

I've also been reflecting a bit on this and I'm starting to think that 4.10 is way too short of a notice for users. We are currently reaching a maturity level on 4.x where many users will be looking more seriously to migrate.

It may not be a good idea to drop such another task on top of the other things they have to validate when moving from 2.x and 3.x all the way to 4.x. We always intended 4.x to be as close as a drop-in replacement as possible, so I am a bit conflicted here.