You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@camel.apache.org by Otavio Rodolfo Piske <an...@gmail.com> on 2022/02/08 08:32:06 UTC

Re: RFC: deprecating camel-testcontainers modules

Hello,

I was talking to Luca a while ago where he pointed me to this discussion on
StackOverflow [1]. This reminded me that last year I raised this suggestion
about deprecating some of the camel-testcontainers components. I think we
have migrated all of our code to test-infra by now.

I am wondering how the community feels about removing those components in
favor of the test-infra components?

My idea here is to execute the following plan:

1. Review and move the development documentation [2] to the website and
make it more visible to the end users.
2. Remove the components for 3.16.0 (or do you prefer 3.17.0?)
3. Write a blog post about it, linking to the new test infra documentation

If you don't agree, then I think we can rollback marking the components as
deprecated and keep test-infra for internal use only.

Links:
1.
https://stackoverflow.com/questions/71027100/is-camel-testcontainers-deprecated-what-replaces-it
2. Test infra development doc:
https://github.com/apache/camel/tree/camel-3.15.0/test-infra

Any thoughts?

Kind regards

On Thu, Jan 14, 2021 at 9:24 AM Otavio Rodolfo Piske <an...@gmail.com>
wrote:

> Thanks Alex, Andrea and Claus for the feedback.
>
> If I understand it correctly. It should be OK to mark the classes as
> deprecated.
>
> I am going to extend the test infra [1] documentation and will send a PR
> for review, with some classes I think could be marked deprecated as part of
> this.
>
> 1. https://github.com/apache/camel/tree/master/test-infra
>
> Kind regards
>
> On Fri, Jan 8, 2021 at 10:00 AM Alexandre Gallice <al...@gmail.com>
> wrote:
>
>> I see no show stopper to deprecation.
>> Some camel-testcontainers-junit5 users out in the community might enjoy a
>> short and concise migration guide with explanation from Otavio above.
>>
>>
>> On Fri, Jan 8, 2021 at 9:00 AM Andrea Cosentino <an...@gmail.com>
>> wrote:
>>
>> > I'm ok with deprecating the classes :-)
>> >
>> > Il ven 8 gen 2021, 08:48 Otavio Rodolfo Piske <an...@gmail.com> ha
>> > scritto:
>> >
>> > > Just to clarify one point, because I don't want to sound pushy and I
>> may
>> > > have misunderstood you.
>> > >
>> > > I was originally talking about marking as deprecated and suggested a
>> > > timeline for removing it. I interpreted your reply as a comment for
>> both
>> > > (deprecating and removing).
>> > >
>> > > If you commented about the deprecation (ie: marking the classes as
>> > > deprecated), then, please ignore my reply: I got your point.
>> > >
>> > >
>> > >
>> > >
>> > > On Fri, Jan 8, 2021 at 8:34 AM Otavio Rodolfo Piske <
>> > angusyoung@gmail.com>
>> > > wrote:
>> > >
>> > > > Thanks Andrea.
>> > > >
>> > > > I was thinking: how about we only mark the classes as deprecated for
>> > now?
>> > > > Therefore we start to gently encourage users to look at test-infra.
>> > > >
>> > > > In my original email I mentioned removing them before the next LTS,
>> > but,
>> > > > indeed, this may be way too soon.
>> > > >
>> > > > Kind regards
>> > > >
>> > > > On Thu, Jan 7, 2021 at 2:49 PM Andrea Cosentino <an...@gmail.com>
>> > > wrote:
>> > > >
>> > > >> I use test-infra stuff even at ckc but before deprecating the
>> > > >> testcontainers components I'd like to have feedback from existing
>> > > users..
>> > > >>
>> > > >> Il mar 5 gen 2021, 11:36 Otavio Rodolfo Piske <
>> angusyoung@gmail.com>
>> > ha
>> > > >> scritto:
>> > > >>
>> > > >> > Thanks Claus! That's a good point and I haven't written much -
>> other
>> > > >> than
>> > > >> > the pre 3.7 release doc update - about it.
>> > > >> >
>> > > >> > Let me show what a conversion from the camel-testcontainer to
>> > > >> > camel-test-infra would look like ... I am using the work on
>> > camel-nats
>> > > >> as
>> > > >> > an example and we can compare how the base test class for nats
>> > changed
>> > > >> > between 3.6.x [1] and 3.7.x [2].
>> > > >> >
>> > > >> > The first conversion step is to replace the camel-testcontainer
>> > > >> > dependencies [3] with the ones from the test-infra module [4].
>> Then,
>> > > >> it's
>> > > >> > necessary to replace the container handling code and the old base
>> > > class
>> > > >> [5]
>> > > >> > with the service provided in the module. It's important to
>> register
>> > it
>> > > >> as a
>> > > >> > JUnit 5 extension [6]. Then, we replace the
>> > ContainerAwareTestSupport
>> > > >> (and
>> > > >> > similar classes from other camel-testcontainer modules) with
>> > > >> > CamelTestSupport (or the spring based one) as it is not needed
>> > > anymore.
>> > > >> >
>> > > >> > The next step is to make sure that addresses (URLs, hostnames,
>> > ports,
>> > > >> etc)
>> > > >> > and resources (usernames, passwords, tokens, etc) referenced
>> during
>> > > the
>> > > >> > test execution, use the test-infra services. This may differ
>> > according
>> > > >> to
>> > > >> > each service. Replacing the call to get the service URL [7] with
>> the
>> > > one
>> > > >> > provided by the test infra service [8] is a good example of this.
>> > > >> >
>> > > >> > This was the bulk of the work for the Camel code base.
>> > > >> >
>> > > >> > There are a few other cases which may require extra
>> attention/work.
>> > > They
>> > > >> > were not so common, but to highlight:
>> > > >> >
>> > > >> > - It may be necessary to adjust the variables used in simple
>> > language
>> > > >> [9]
>> > > >> > so that they match the property format used in the test infra
>> > service
>> > > >> [10]
>> > > >> > (as was the case for camel-consul).
>> > > >> > - There are some cases where the container instance requires
>> extra
>> > > >> > customization [11]. The code still benefits from the test-infra
>> > > >> approach,
>> > > >> > but this may be very specific to the test scenario [12] .
>> > > >> >
>> > > >> > All in all, it's not a significantly complicated task but it's
>> not a
>> > > >> > drop-in replacement either.
>> > > >> >
>> > > >> > I am linking here to the PR which I submitted for the camel-nats
>> > > >> conversion
>> > > >> > [13] just in case I missed anything. At first sight it may look
>> more
>> > > >> > complicated than what I said, but that's because it also contains
>> > the
>> > > >> > test-infra code for Nats.
>> > > >> >
>> > > >> > 1.
>> > > >> >
>> > > >> >
>> > > >>
>> > >
>> >
>> https://github.com/apache/camel/blob/camel-3.6.0/components/camel-nats/src/test/java/org/apache/camel/component/nats/NatsTestSupport.java
>> > > >> > 2.
>> > > >> >
>> > > >> >
>> > > >>
>> > >
>> >
>> https://github.com/apache/camel/blob/camel-3.7.0/components/camel-nats/src/test/java/org/apache/camel/component/nats/NatsTestSupport.java
>> > > >> > 3.
>> > > >> >
>> > > >> >
>> > > >>
>> > >
>> >
>> https://github.com/apache/camel/blob/camel-3.6.0/components/camel-nats/pom.xml#L59-L63
>> > > >> > 4.
>> > > >> >
>> > > >> >
>> > > >>
>> > >
>> >
>> https://github.com/apache/camel/blob/camel-3.7.0/components/camel-nats/pom.xml#L61-L75
>> > > >> > 5.
>> > > >> >
>> > > >> >
>> > > >>
>> > >
>> >
>> https://github.com/apache/camel/blob/camel-3.6.0/components/camel-nats/src/test/java/org/apache/camel/component/nats/NatsTestSupport.java#L24-L45
>> > > >> > 6.
>> > > >> >
>> > > >> >
>> > > >>
>> > >
>> >
>> https://github.com/apache/camel/blob/camel-3.7.0/components/camel-nats/src/test/java/org/apache/camel/component/nats/NatsTestSupport.java#L25-L27
>> > > >> > 7.
>> > > >> >
>> > > >> >
>> > > >>
>> > >
>> >
>> https://github.com/apache/camel/blob/camel-3.6.0/components/camel-nats/src/test/java/org/apache/camel/component/nats/NatsAuthConsumerLoadTest.java#L38
>> > > >> > 8.
>> > > >> >
>> > > >> >
>> > > >>
>> > >
>> >
>> https://github.com/apache/camel/blob/camel-3.7.0/components/camel-nats/src/test/java/org/apache/camel/component/nats/NatsAuthConsumerLoadTest.java#L38
>> > > >> > 9.
>> > > >> >
>> > > >> >
>> > > >>
>> > >
>> >
>> https://github.com/apache/camel/blob/camel-3.6.0/components/camel-consul/src/test/resources/org/apache/camel/component/consul/cloud/SpringConsulRibbonServiceCallRouteTest.xml#L36
>> > > >> > 10.
>> > > >> >
>> > > >> >
>> > > >>
>> > >
>> >
>> https://github.com/apache/camel/blob/camel-3.7.0/components/camel-consul/src/test/resources/org/apache/camel/component/consul/cloud/SpringConsulRibbonServiceCallRouteTest.xml#L36
>> > > >> > 11.
>> > > >> >
>> > > >> >
>> > > >>
>> > >
>> >
>> https://github.com/apache/camel/blob/camel-3.6.0/components/camel-pg-replication-slot/src/test/java/org/apache/camel/component/pg/replication/slot/integration/PgReplicationTestSupport.java#L31
>> > > >> > 12.
>> > > >> >
>> > > >> >
>> > > >>
>> > >
>> >
>> https://github.com/apache/camel/blob/camel-3.7.0/components/camel-pg-replication-slot/src/test/java/org/apache/camel/component/pg/replication/slot/integration/PgReplicationTestSupport.java#L31
>> > > >> > 13. https://github.com/apache/camel/pull/4706/files
>> > > >> >
>> > > >> > On Tue, Jan 5, 2021 at 10:36 AM Claus Ibsen <
>> claus.ibsen@gmail.com>
>> > > >> wrote:
>> > > >> >
>> > > >> > > Hi Otavia
>> > > >> > >
>> > > >> > > Great work.
>> > > >> > >
>> > > >> > > Can you maybe tell a bit about what if an end user have used
>> > > >> > > camel-testcontainers-junit5 to do his/her own container testing
>> > with
>> > > >> > > Camel (for example to use their own container image, or for
>> > example
>> > > a
>> > > >> > > database container or something). How would they do that today
>> > with
>> > > >> > > the test infra?
>> > > >> > >
>> > > >> > >
>> > > >> > > On Tue, Jan 5, 2021 at 9:37 AM Otavio Rodolfo Piske
>> > > >> > > <an...@gmail.com> wrote:
>> > > >> > > >
>> > > >> > > > Hello,
>> > > >> > > >
>> > > >> > > > as of 3.7.x, all the test infrastructure code that we had was
>> > > >> converted
>> > > >> > > to
>> > > >> > > > use the test-infra modules.
>> > > >> > > >
>> > > >> > > > This brings several benefits for in terms of maintenance for
>> the
>> > > >> test
>> > > >> > > code:
>> > > >> > > > - we can share more easily, among the sub-projects, the code
>> > > >> handling
>> > > >> > the
>> > > >> > > > test infrastructure. For example: setting up and running
>> message
>> > > >> > brokers,
>> > > >> > > > databases, cloud simulation containers, etc.
>> > > >> > > > - we "outsource" the management of the resources to JUnit 5
>> and
>> > > let
>> > > >> it
>> > > >> > > > handle the lifecycle, setup, etc ... thus simplifying the
>> test
>> > > code.
>> > > >> > > > - we can separate the interface from implementation. This
>> allows
>> > > us
>> > > >> and
>> > > >> > > > colleagues running and testing the Camel code to run
>> integration
>> > > and
>> > > >> > > > interoperability tests more easily. For example, it makes it
>> > > >> possible
>> > > >> > to
>> > > >> > > > run the same tests against remote instances of the said
>> > > >> infrastructure.
>> > > >> > > > This is very handy for AWS tests, for example, where we can
>> > switch
>> > > >> to
>> > > >> > run
>> > > >> > > > the tests from Localstack containers to an actual AWS
>> instance
>> > by
>> > > >> > simply
>> > > >> > > > adjusting the test parameters. It still uses testcontainers
>> > under
>> > > >> the
>> > > >> > > hood,
>> > > >> > > > but it is abstracted from the test code.
>> > > >> > > >
>> > > >> > > > As result of this migration, the code in the following
>> > components
>> > > >> has
>> > > >> > > > become unused within Camel:
>> > > >> > > > - camel-testcontainers
>> > > >> > > > - camel-testcontainers-junit5
>> > > >> > > > - camel-testcontainers-spring
>> > > >> > > > - camel-testcontainers-spring-junit5
>> > > >> > > >
>> > > >> > > > I'd like to propose deprecating these components, starting
>> with
>> > > 3.8
>> > > >> and
>> > > >> > > > then removing them before we release the next LTS.
>> > > >> > > >
>> > > >> > > > Therefore, I'd like to gather feedback from the community
>> about
>> > > >> usage
>> > > >> > of
>> > > >> > > > those modules, thoughts on the idea and if any roadblock
>> > remains.
>> > > >> > > >
>> > > >> > > > Kind regards
>> > > >> > > > --
>> > > >> > > > Otavio R. Piske
>> > > >> > > > http://orpiske.net
>> > > >> > >
>> > > >> > >
>> > > >> > >
>> > > >> > > --
>> > > >> > > Claus Ibsen
>> > > >> > > -----------------
>> > > >> > > http://davsclaus.com @davsclaus
>> > > >> > > Camel in Action 2: https://www.manning.com/ibsen2
>> > > >> > >
>> > > >> >
>> > > >> >
>> > > >> > --
>> > > >> > Otavio R. Piske
>> > > >> > http://orpiske.net
>> > > >> >
>> > > >>
>> > > >
>> > > >
>> > > > --
>> > > > Otavio R. Piske
>> > > > http://orpiske.net
>> > > >
>> > >
>> > >
>> > > --
>> > > Otavio R. Piske
>> > > http://orpiske.net
>> > >
>> >
>>
>
>
> --
> Otavio R. Piske
> http://orpiske.net
>


-- 
Otavio R. Piske
http://orpiske.net

Re: RFC: deprecating camel-testcontainers modules

Posted by Otavio Rodolfo Piske <an...@gmail.com>.

Thanks Claus, I'll take care of it (hopefully in time for 3.16.0).

I am tracking it on https://issues.apache.org/jira/browse/CAMEL-17625.

Kind regards

On Tue, Feb 8, 2022 at 10:53 AM Claus Ibsen <cl...@gmail.com> wrote:

> On Tue, Feb 8, 2022 at 9:32 AM Otavio Rodolfo Piske
> <an...@gmail.com> wrote:
> >
> > Hello,
> >
> > I was talking to Luca a while ago where he pointed me to this discussion
> on
> > StackOverflow [1]. This reminded me that last year I raised this
> suggestion
> > about deprecating some of the camel-testcontainers components. I think we
> > have migrated all of our code to test-infra by now.
> >
> > I am wondering how the community feels about removing those components in
> > favor of the test-infra components?
> >
> > My idea here is to execute the following plan:
> >
> > 1. Review and move the development documentation [2] to the website and
> > make it more visible to the end users.
> > 2. Remove the components for 3.16.0 (or do you prefer 3.17.0?)
> > 3. Write a blog post about it, linking to the new test infra
> documentation
> >
>
> +1 that is a good plan.
>
>
> > If you don't agree, then I think we can rollback marking the components
> as
> > deprecated and keep test-infra for internal use only.
> >
> > Links:
> > 1.
> >
> https://stackoverflow.com/questions/71027100/is-camel-testcontainers-deprecated-what-replaces-it
> > 2. Test infra development doc:
> > https://github.com/apache/camel/tree/camel-3.15.0/test-infra
> >
> > Any thoughts?
> >
> > Kind regards
> >
> > On Thu, Jan 14, 2021 at 9:24 AM Otavio Rodolfo Piske <
> angusyoung@gmail.com>
> > wrote:
> >
> > > Thanks Alex, Andrea and Claus for the feedback.
> > >
> > > If I understand it correctly. It should be OK to mark the classes as
> > > deprecated.
> > >
> > > I am going to extend the test infra [1] documentation and will send a
> PR
> > > for review, with some classes I think could be marked deprecated as
> part of
> > > this.
> > >
> > > 1. https://github.com/apache/camel/tree/master/test-infra
> > >
> > > Kind regards
> > >
> > > On Fri, Jan 8, 2021 at 10:00 AM Alexandre Gallice <
> aldettinger@gmail.com>
> > > wrote:
> > >
> > >> I see no show stopper to deprecation.
> > >> Some camel-testcontainers-junit5 users out in the community might
> enjoy a
> > >> short and concise migration guide with explanation from Otavio above.
> > >>
> > >>
> > >> On Fri, Jan 8, 2021 at 9:00 AM Andrea Cosentino <an...@gmail.com>
> > >> wrote:
> > >>
> > >> > I'm ok with deprecating the classes :-)
> > >> >
> > >> > Il ven 8 gen 2021, 08:48 Otavio Rodolfo Piske <an...@gmail.com>
> ha
> > >> > scritto:
> > >> >
> > >> > > Just to clarify one point, because I don't want to sound pushy
> and I
> > >> may
> > >> > > have misunderstood you.
> > >> > >
> > >> > > I was originally talking about marking as deprecated and
> suggested a
> > >> > > timeline for removing it. I interpreted your reply as a comment
> for
> > >> both
> > >> > > (deprecating and removing).
> > >> > >
> > >> > > If you commented about the deprecation (ie: marking the classes as
> > >> > > deprecated), then, please ignore my reply: I got your point.
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > > On Fri, Jan 8, 2021 at 8:34 AM Otavio Rodolfo Piske <
> > >> > angusyoung@gmail.com>
> > >> > > wrote:
> > >> > >
> > >> > > > Thanks Andrea.
> > >> > > >
> > >> > > > I was thinking: how about we only mark the classes as
> deprecated for
> > >> > now?
> > >> > > > Therefore we start to gently encourage users to look at
> test-infra.
> > >> > > >
> > >> > > > In my original email I mentioned removing them before the next
> LTS,
> > >> > but,
> > >> > > > indeed, this may be way too soon.
> > >> > > >
> > >> > > > Kind regards
> > >> > > >
> > >> > > > On Thu, Jan 7, 2021 at 2:49 PM Andrea Cosentino <
> ancosen@gmail.com>
> > >> > > wrote:
> > >> > > >
> > >> > > >> I use test-infra stuff even at ckc but before deprecating the
> > >> > > >> testcontainers components I'd like to have feedback from
> existing
> > >> > > users..
> > >> > > >>
> > >> > > >> Il mar 5 gen 2021, 11:36 Otavio Rodolfo Piske <
> > >> angusyoung@gmail.com>
> > >> > ha
> > >> > > >> scritto:
> > >> > > >>
> > >> > > >> > Thanks Claus! That's a good point and I haven't written much
> -
> > >> other
> > >> > > >> than
> > >> > > >> > the pre 3.7 release doc update - about it.
> > >> > > >> >
> > >> > > >> > Let me show what a conversion from the camel-testcontainer to
> > >> > > >> > camel-test-infra would look like ... I am using the work on
> > >> > camel-nats
> > >> > > >> as
> > >> > > >> > an example and we can compare how the base test class for
> nats
> > >> > changed
> > >> > > >> > between 3.6.x [1] and 3.7.x [2].
> > >> > > >> >
> > >> > > >> > The first conversion step is to replace the
> camel-testcontainer
> > >> > > >> > dependencies [3] with the ones from the test-infra module
> [4].
> > >> Then,
> > >> > > >> it's
> > >> > > >> > necessary to replace the container handling code and the old
> base
> > >> > > class
> > >> > > >> [5]
> > >> > > >> > with the service provided in the module. It's important to
> > >> register
> > >> > it
> > >> > > >> as a
> > >> > > >> > JUnit 5 extension [6]. Then, we replace the
> > >> > ContainerAwareTestSupport
> > >> > > >> (and
> > >> > > >> > similar classes from other camel-testcontainer modules) with
> > >> > > >> > CamelTestSupport (or the spring based one) as it is not
> needed
> > >> > > anymore.
> > >> > > >> >
> > >> > > >> > The next step is to make sure that addresses (URLs,
> hostnames,
> > >> > ports,
> > >> > > >> etc)
> > >> > > >> > and resources (usernames, passwords, tokens, etc) referenced
> > >> during
> > >> > > the
> > >> > > >> > test execution, use the test-infra services. This may differ
> > >> > according
> > >> > > >> to
> > >> > > >> > each service. Replacing the call to get the service URL [7]
> with
> > >> the
> > >> > > one
> > >> > > >> > provided by the test infra service [8] is a good example of
> this.
> > >> > > >> >
> > >> > > >> > This was the bulk of the work for the Camel code base.
> > >> > > >> >
> > >> > > >> > There are a few other cases which may require extra
> > >> attention/work.
> > >> > > They
> > >> > > >> > were not so common, but to highlight:
> > >> > > >> >
> > >> > > >> > - It may be necessary to adjust the variables used in simple
> > >> > language
> > >> > > >> [9]
> > >> > > >> > so that they match the property format used in the test infra
> > >> > service
> > >> > > >> [10]
> > >> > > >> > (as was the case for camel-consul).
> > >> > > >> > - There are some cases where the container instance requires
> > >> extra
> > >> > > >> > customization [11]. The code still benefits from the
> test-infra
> > >> > > >> approach,
> > >> > > >> > but this may be very specific to the test scenario [12] .
> > >> > > >> >
> > >> > > >> > All in all, it's not a significantly complicated task but
> it's
> > >> not a
> > >> > > >> > drop-in replacement either.
> > >> > > >> >
> > >> > > >> > I am linking here to the PR which I submitted for the
> camel-nats
> > >> > > >> conversion
> > >> > > >> > [13] just in case I missed anything. At first sight it may
> look
> > >> more
> > >> > > >> > complicated than what I said, but that's because it also
> contains
> > >> > the
> > >> > > >> > test-infra code for Nats.
> > >> > > >> >
> > >> > > >> > 1.
> > >> > > >> >
> > >> > > >> >
> > >> > > >>
> > >> > >
> > >> >
> > >>
> https://github.com/apache/camel/blob/camel-3.6.0/components/camel-nats/src/test/java/org/apache/camel/component/nats/NatsTestSupport.java
> > >> > > >> > 2.
> > >> > > >> >
> > >> > > >> >
> > >> > > >>
> > >> > >
> > >> >
> > >>
> https://github.com/apache/camel/blob/camel-3.7.0/components/camel-nats/src/test/java/org/apache/camel/component/nats/NatsTestSupport.java
> > >> > > >> > 3.
> > >> > > >> >
> > >> > > >> >
> > >> > > >>
> > >> > >
> > >> >
> > >>
> https://github.com/apache/camel/blob/camel-3.6.0/components/camel-nats/pom.xml#L59-L63
> > >> > > >> > 4.
> > >> > > >> >
> > >> > > >> >
> > >> > > >>
> > >> > >
> > >> >
> > >>
> https://github.com/apache/camel/blob/camel-3.7.0/components/camel-nats/pom.xml#L61-L75
> > >> > > >> > 5.
> > >> > > >> >
> > >> > > >> >
> > >> > > >>
> > >> > >
> > >> >
> > >>
> https://github.com/apache/camel/blob/camel-3.6.0/components/camel-nats/src/test/java/org/apache/camel/component/nats/NatsTestSupport.java#L24-L45
> > >> > > >> > 6.
> > >> > > >> >
> > >> > > >> >
> > >> > > >>
> > >> > >
> > >> >
> > >>
> https://github.com/apache/camel/blob/camel-3.7.0/components/camel-nats/src/test/java/org/apache/camel/component/nats/NatsTestSupport.java#L25-L27
> > >> > > >> > 7.
> > >> > > >> >
> > >> > > >> >
> > >> > > >>
> > >> > >
> > >> >
> > >>
> https://github.com/apache/camel/blob/camel-3.6.0/components/camel-nats/src/test/java/org/apache/camel/component/nats/NatsAuthConsumerLoadTest.java#L38
> > >> > > >> > 8.
> > >> > > >> >
> > >> > > >> >
> > >> > > >>
> > >> > >
> > >> >
> > >>
> https://github.com/apache/camel/blob/camel-3.7.0/components/camel-nats/src/test/java/org/apache/camel/component/nats/NatsAuthConsumerLoadTest.java#L38
> > >> > > >> > 9.
> > >> > > >> >
> > >> > > >> >
> > >> > > >>
> > >> > >
> > >> >
> > >>
> https://github.com/apache/camel/blob/camel-3.6.0/components/camel-consul/src/test/resources/org/apache/camel/component/consul/cloud/SpringConsulRibbonServiceCallRouteTest.xml#L36
> > >> > > >> > 10.
> > >> > > >> >
> > >> > > >> >
> > >> > > >>
> > >> > >
> > >> >
> > >>
> https://github.com/apache/camel/blob/camel-3.7.0/components/camel-consul/src/test/resources/org/apache/camel/component/consul/cloud/SpringConsulRibbonServiceCallRouteTest.xml#L36
> > >> > > >> > 11.
> > >> > > >> >
> > >> > > >> >
> > >> > > >>
> > >> > >
> > >> >
> > >>
> https://github.com/apache/camel/blob/camel-3.6.0/components/camel-pg-replication-slot/src/test/java/org/apache/camel/component/pg/replication/slot/integration/PgReplicationTestSupport.java#L31
> > >> > > >> > 12.
> > >> > > >> >
> > >> > > >> >
> > >> > > >>
> > >> > >
> > >> >
> > >>
> https://github.com/apache/camel/blob/camel-3.7.0/components/camel-pg-replication-slot/src/test/java/org/apache/camel/component/pg/replication/slot/integration/PgReplicationTestSupport.java#L31
> > >> > > >> > 13. https://github.com/apache/camel/pull/4706/files
> > >> > > >> >
> > >> > > >> > On Tue, Jan 5, 2021 at 10:36 AM Claus Ibsen <
> > >> claus.ibsen@gmail.com>
> > >> > > >> wrote:
> > >> > > >> >
> > >> > > >> > > Hi Otavia
> > >> > > >> > >
> > >> > > >> > > Great work.
> > >> > > >> > >
> > >> > > >> > > Can you maybe tell a bit about what if an end user have
> used
> > >> > > >> > > camel-testcontainers-junit5 to do his/her own container
> testing
> > >> > with
> > >> > > >> > > Camel (for example to use their own container image, or for
> > >> > example
> > >> > > a
> > >> > > >> > > database container or something). How would they do that
> today
> > >> > with
> > >> > > >> > > the test infra?
> > >> > > >> > >
> > >> > > >> > >
> > >> > > >> > > On Tue, Jan 5, 2021 at 9:37 AM Otavio Rodolfo Piske
> > >> > > >> > > <an...@gmail.com> wrote:
> > >> > > >> > > >
> > >> > > >> > > > Hello,
> > >> > > >> > > >
> > >> > > >> > > > as of 3.7.x, all the test infrastructure code that we
> had was
> > >> > > >> converted
> > >> > > >> > > to
> > >> > > >> > > > use the test-infra modules.
> > >> > > >> > > >
> > >> > > >> > > > This brings several benefits for in terms of maintenance
> for
> > >> the
> > >> > > >> test
> > >> > > >> > > code:
> > >> > > >> > > > - we can share more easily, among the sub-projects, the
> code
> > >> > > >> handling
> > >> > > >> > the
> > >> > > >> > > > test infrastructure. For example: setting up and running
> > >> message
> > >> > > >> > brokers,
> > >> > > >> > > > databases, cloud simulation containers, etc.
> > >> > > >> > > > - we "outsource" the management of the resources to
> JUnit 5
> > >> and
> > >> > > let
> > >> > > >> it
> > >> > > >> > > > handle the lifecycle, setup, etc ... thus simplifying the
> > >> test
> > >> > > code.
> > >> > > >> > > > - we can separate the interface from implementation. This
> > >> allows
> > >> > > us
> > >> > > >> and
> > >> > > >> > > > colleagues running and testing the Camel code to run
> > >> integration
> > >> > > and
> > >> > > >> > > > interoperability tests more easily. For example, it
> makes it
> > >> > > >> possible
> > >> > > >> > to
> > >> > > >> > > > run the same tests against remote instances of the said
> > >> > > >> infrastructure.
> > >> > > >> > > > This is very handy for AWS tests, for example, where we
> can
> > >> > switch
> > >> > > >> to
> > >> > > >> > run
> > >> > > >> > > > the tests from Localstack containers to an actual AWS
> > >> instance
> > >> > by
> > >> > > >> > simply
> > >> > > >> > > > adjusting the test parameters. It still uses
> testcontainers
> > >> > under
> > >> > > >> the
> > >> > > >> > > hood,
> > >> > > >> > > > but it is abstracted from the test code.
> > >> > > >> > > >
> > >> > > >> > > > As result of this migration, the code in the following
> > >> > components
> > >> > > >> has
> > >> > > >> > > > become unused within Camel:
> > >> > > >> > > > - camel-testcontainers
> > >> > > >> > > > - camel-testcontainers-junit5
> > >> > > >> > > > - camel-testcontainers-spring
> > >> > > >> > > > - camel-testcontainers-spring-junit5
> > >> > > >> > > >
> > >> > > >> > > > I'd like to propose deprecating these components,
> starting
> > >> with
> > >> > > 3.8
> > >> > > >> and
> > >> > > >> > > > then removing them before we release the next LTS.
> > >> > > >> > > >
> > >> > > >> > > > Therefore, I'd like to gather feedback from the community
> > >> about
> > >> > > >> usage
> > >> > > >> > of
> > >> > > >> > > > those modules, thoughts on the idea and if any roadblock
> > >> > remains.
> > >> > > >> > > >
> > >> > > >> > > > Kind regards
> > >> > > >> > > > --
> > >> > > >> > > > Otavio R. Piske
> > >> > > >> > > > http://orpiske.net
> > >> > > >> > >
> > >> > > >> > >
> > >> > > >> > >
> > >> > > >> > > --
> > >> > > >> > > Claus Ibsen
> > >> > > >> > > -----------------
> > >> > > >> > > http://davsclaus.com @davsclaus
> > >> > > >> > > Camel in Action 2: https://www.manning.com/ibsen2
> > >> > > >> > >
> > >> > > >> >
> > >> > > >> >
> > >> > > >> > --
> > >> > > >> > Otavio R. Piske
> > >> > > >> > http://orpiske.net
> > >> > > >> >
> > >> > > >>
> > >> > > >
> > >> > > >
> > >> > > > --
> > >> > > > Otavio R. Piske
> > >> > > > http://orpiske.net
> > >> > > >
> > >> > >
> > >> > >
> > >> > > --
> > >> > > Otavio R. Piske
> > >> > > http://orpiske.net
> > >> > >
> > >> >
> > >>
> > >
> > >
> > > --
> > > Otavio R. Piske
> > > http://orpiske.net
> > >
> >
> >
> > --
> > Otavio R. Piske
> > http://orpiske.net
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>


-- 
Otavio R. Piske
http://orpiske.net

Re: RFC: deprecating camel-testcontainers modules

Posted by Claus Ibsen <cl...@gmail.com>.

On Tue, Feb 8, 2022 at 9:32 AM Otavio Rodolfo Piske
<an...@gmail.com> wrote:
>
> Hello,
>
> I was talking to Luca a while ago where he pointed me to this discussion on
> StackOverflow [1]. This reminded me that last year I raised this suggestion
> about deprecating some of the camel-testcontainers components. I think we
> have migrated all of our code to test-infra by now.
>
> I am wondering how the community feels about removing those components in
> favor of the test-infra components?
>
> My idea here is to execute the following plan:
>
> 1. Review and move the development documentation [2] to the website and
> make it more visible to the end users.
> 2. Remove the components for 3.16.0 (or do you prefer 3.17.0?)
> 3. Write a blog post about it, linking to the new test infra documentation
>

+1 that is a good plan.


> If you don't agree, then I think we can rollback marking the components as
> deprecated and keep test-infra for internal use only.
>
> Links:
> 1.
> https://stackoverflow.com/questions/71027100/is-camel-testcontainers-deprecated-what-replaces-it
> 2. Test infra development doc:
> https://github.com/apache/camel/tree/camel-3.15.0/test-infra
>
> Any thoughts?
>
> Kind regards
>
> On Thu, Jan 14, 2021 at 9:24 AM Otavio Rodolfo Piske <an...@gmail.com>
> wrote:
>
> > Thanks Alex, Andrea and Claus for the feedback.
> >
> > If I understand it correctly. It should be OK to mark the classes as
> > deprecated.
> >
> > I am going to extend the test infra [1] documentation and will send a PR
> > for review, with some classes I think could be marked deprecated as part of
> > this.
> >
> > 1. https://github.com/apache/camel/tree/master/test-infra
> >
> > Kind regards
> >
> > On Fri, Jan 8, 2021 at 10:00 AM Alexandre Gallice <al...@gmail.com>
> > wrote:
> >
> >> I see no show stopper to deprecation.
> >> Some camel-testcontainers-junit5 users out in the community might enjoy a
> >> short and concise migration guide with explanation from Otavio above.
> >>
> >>
> >> On Fri, Jan 8, 2021 at 9:00 AM Andrea Cosentino <an...@gmail.com>
> >> wrote:
> >>
> >> > I'm ok with deprecating the classes :-)
> >> >
> >> > Il ven 8 gen 2021, 08:48 Otavio Rodolfo Piske <an...@gmail.com> ha
> >> > scritto:
> >> >
> >> > > Just to clarify one point, because I don't want to sound pushy and I
> >> may
> >> > > have misunderstood you.
> >> > >
> >> > > I was originally talking about marking as deprecated and suggested a
> >> > > timeline for removing it. I interpreted your reply as a comment for
> >> both
> >> > > (deprecating and removing).
> >> > >
> >> > > If you commented about the deprecation (ie: marking the classes as
> >> > > deprecated), then, please ignore my reply: I got your point.
> >> > >
> >> > >
> >> > >
> >> > >
> >> > > On Fri, Jan 8, 2021 at 8:34 AM Otavio Rodolfo Piske <
> >> > angusyoung@gmail.com>
> >> > > wrote:
> >> > >
> >> > > > Thanks Andrea.
> >> > > >
> >> > > > I was thinking: how about we only mark the classes as deprecated for
> >> > now?
> >> > > > Therefore we start to gently encourage users to look at test-infra.
> >> > > >
> >> > > > In my original email I mentioned removing them before the next LTS,
> >> > but,
> >> > > > indeed, this may be way too soon.
> >> > > >
> >> > > > Kind regards
> >> > > >
> >> > > > On Thu, Jan 7, 2021 at 2:49 PM Andrea Cosentino <an...@gmail.com>
> >> > > wrote:
> >> > > >
> >> > > >> I use test-infra stuff even at ckc but before deprecating the
> >> > > >> testcontainers components I'd like to have feedback from existing
> >> > > users..
> >> > > >>
> >> > > >> Il mar 5 gen 2021, 11:36 Otavio Rodolfo Piske <
> >> angusyoung@gmail.com>
> >> > ha
> >> > > >> scritto:
> >> > > >>
> >> > > >> > Thanks Claus! That's a good point and I haven't written much -
> >> other
> >> > > >> than
> >> > > >> > the pre 3.7 release doc update - about it.
> >> > > >> >
> >> > > >> > Let me show what a conversion from the camel-testcontainer to
> >> > > >> > camel-test-infra would look like ... I am using the work on
> >> > camel-nats
> >> > > >> as
> >> > > >> > an example and we can compare how the base test class for nats
> >> > changed
> >> > > >> > between 3.6.x [1] and 3.7.x [2].
> >> > > >> >
> >> > > >> > The first conversion step is to replace the camel-testcontainer
> >> > > >> > dependencies [3] with the ones from the test-infra module [4].
> >> Then,
> >> > > >> it's
> >> > > >> > necessary to replace the container handling code and the old base
> >> > > class
> >> > > >> [5]
> >> > > >> > with the service provided in the module. It's important to
> >> register
> >> > it
> >> > > >> as a
> >> > > >> > JUnit 5 extension [6]. Then, we replace the
> >> > ContainerAwareTestSupport
> >> > > >> (and
> >> > > >> > similar classes from other camel-testcontainer modules) with
> >> > > >> > CamelTestSupport (or the spring based one) as it is not needed
> >> > > anymore.
> >> > > >> >
> >> > > >> > The next step is to make sure that addresses (URLs, hostnames,
> >> > ports,
> >> > > >> etc)
> >> > > >> > and resources (usernames, passwords, tokens, etc) referenced
> >> during
> >> > > the
> >> > > >> > test execution, use the test-infra services. This may differ
> >> > according
> >> > > >> to
> >> > > >> > each service. Replacing the call to get the service URL [7] with
> >> the
> >> > > one
> >> > > >> > provided by the test infra service [8] is a good example of this.
> >> > > >> >
> >> > > >> > This was the bulk of the work for the Camel code base.
> >> > > >> >
> >> > > >> > There are a few other cases which may require extra
> >> attention/work.
> >> > > They
> >> > > >> > were not so common, but to highlight:
> >> > > >> >
> >> > > >> > - It may be necessary to adjust the variables used in simple
> >> > language
> >> > > >> [9]
> >> > > >> > so that they match the property format used in the test infra
> >> > service
> >> > > >> [10]
> >> > > >> > (as was the case for camel-consul).
> >> > > >> > - There are some cases where the container instance requires
> >> extra
> >> > > >> > customization [11]. The code still benefits from the test-infra
> >> > > >> approach,
> >> > > >> > but this may be very specific to the test scenario [12] .
> >> > > >> >
> >> > > >> > All in all, it's not a significantly complicated task but it's
> >> not a
> >> > > >> > drop-in replacement either.
> >> > > >> >
> >> > > >> > I am linking here to the PR which I submitted for the camel-nats
> >> > > >> conversion
> >> > > >> > [13] just in case I missed anything. At first sight it may look
> >> more
> >> > > >> > complicated than what I said, but that's because it also contains
> >> > the
> >> > > >> > test-infra code for Nats.
> >> > > >> >
> >> > > >> > 1.
> >> > > >> >
> >> > > >> >
> >> > > >>
> >> > >
> >> >
> >> https://github.com/apache/camel/blob/camel-3.6.0/components/camel-nats/src/test/java/org/apache/camel/component/nats/NatsTestSupport.java
> >> > > >> > 2.
> >> > > >> >
> >> > > >> >
> >> > > >>
> >> > >
> >> >
> >> https://github.com/apache/camel/blob/camel-3.7.0/components/camel-nats/src/test/java/org/apache/camel/component/nats/NatsTestSupport.java
> >> > > >> > 3.
> >> > > >> >
> >> > > >> >
> >> > > >>
> >> > >
> >> >
> >> https://github.com/apache/camel/blob/camel-3.6.0/components/camel-nats/pom.xml#L59-L63
> >> > > >> > 4.
> >> > > >> >
> >> > > >> >
> >> > > >>
> >> > >
> >> >
> >> https://github.com/apache/camel/blob/camel-3.7.0/components/camel-nats/pom.xml#L61-L75
> >> > > >> > 5.
> >> > > >> >
> >> > > >> >
> >> > > >>
> >> > >
> >> >
> >> https://github.com/apache/camel/blob/camel-3.6.0/components/camel-nats/src/test/java/org/apache/camel/component/nats/NatsTestSupport.java#L24-L45
> >> > > >> > 6.
> >> > > >> >
> >> > > >> >
> >> > > >>
> >> > >
> >> >
> >> https://github.com/apache/camel/blob/camel-3.7.0/components/camel-nats/src/test/java/org/apache/camel/component/nats/NatsTestSupport.java#L25-L27
> >> > > >> > 7.
> >> > > >> >
> >> > > >> >
> >> > > >>
> >> > >
> >> >
> >> https://github.com/apache/camel/blob/camel-3.6.0/components/camel-nats/src/test/java/org/apache/camel/component/nats/NatsAuthConsumerLoadTest.java#L38
> >> > > >> > 8.
> >> > > >> >
> >> > > >> >
> >> > > >>
> >> > >
> >> >
> >> https://github.com/apache/camel/blob/camel-3.7.0/components/camel-nats/src/test/java/org/apache/camel/component/nats/NatsAuthConsumerLoadTest.java#L38
> >> > > >> > 9.
> >> > > >> >
> >> > > >> >
> >> > > >>
> >> > >
> >> >
> >> https://github.com/apache/camel/blob/camel-3.6.0/components/camel-consul/src/test/resources/org/apache/camel/component/consul/cloud/SpringConsulRibbonServiceCallRouteTest.xml#L36
> >> > > >> > 10.
> >> > > >> >
> >> > > >> >
> >> > > >>
> >> > >
> >> >
> >> https://github.com/apache/camel/blob/camel-3.7.0/components/camel-consul/src/test/resources/org/apache/camel/component/consul/cloud/SpringConsulRibbonServiceCallRouteTest.xml#L36
> >> > > >> > 11.
> >> > > >> >
> >> > > >> >
> >> > > >>
> >> > >
> >> >
> >> https://github.com/apache/camel/blob/camel-3.6.0/components/camel-pg-replication-slot/src/test/java/org/apache/camel/component/pg/replication/slot/integration/PgReplicationTestSupport.java#L31
> >> > > >> > 12.
> >> > > >> >
> >> > > >> >
> >> > > >>
> >> > >
> >> >
> >> https://github.com/apache/camel/blob/camel-3.7.0/components/camel-pg-replication-slot/src/test/java/org/apache/camel/component/pg/replication/slot/integration/PgReplicationTestSupport.java#L31
> >> > > >> > 13. https://github.com/apache/camel/pull/4706/files
> >> > > >> >
> >> > > >> > On Tue, Jan 5, 2021 at 10:36 AM Claus Ibsen <
> >> claus.ibsen@gmail.com>
> >> > > >> wrote:
> >> > > >> >
> >> > > >> > > Hi Otavia
> >> > > >> > >
> >> > > >> > > Great work.
> >> > > >> > >
> >> > > >> > > Can you maybe tell a bit about what if an end user have used
> >> > > >> > > camel-testcontainers-junit5 to do his/her own container testing
> >> > with
> >> > > >> > > Camel (for example to use their own container image, or for
> >> > example
> >> > > a
> >> > > >> > > database container or something). How would they do that today
> >> > with
> >> > > >> > > the test infra?
> >> > > >> > >
> >> > > >> > >
> >> > > >> > > On Tue, Jan 5, 2021 at 9:37 AM Otavio Rodolfo Piske
> >> > > >> > > <an...@gmail.com> wrote:
> >> > > >> > > >
> >> > > >> > > > Hello,
> >> > > >> > > >
> >> > > >> > > > as of 3.7.x, all the test infrastructure code that we had was
> >> > > >> converted
> >> > > >> > > to
> >> > > >> > > > use the test-infra modules.
> >> > > >> > > >
> >> > > >> > > > This brings several benefits for in terms of maintenance for
> >> the
> >> > > >> test
> >> > > >> > > code:
> >> > > >> > > > - we can share more easily, among the sub-projects, the code
> >> > > >> handling
> >> > > >> > the
> >> > > >> > > > test infrastructure. For example: setting up and running
> >> message
> >> > > >> > brokers,
> >> > > >> > > > databases, cloud simulation containers, etc.
> >> > > >> > > > - we "outsource" the management of the resources to JUnit 5
> >> and
> >> > > let
> >> > > >> it
> >> > > >> > > > handle the lifecycle, setup, etc ... thus simplifying the
> >> test
> >> > > code.
> >> > > >> > > > - we can separate the interface from implementation. This
> >> allows
> >> > > us
> >> > > >> and
> >> > > >> > > > colleagues running and testing the Camel code to run
> >> integration
> >> > > and
> >> > > >> > > > interoperability tests more easily. For example, it makes it
> >> > > >> possible
> >> > > >> > to
> >> > > >> > > > run the same tests against remote instances of the said
> >> > > >> infrastructure.
> >> > > >> > > > This is very handy for AWS tests, for example, where we can
> >> > switch
> >> > > >> to
> >> > > >> > run
> >> > > >> > > > the tests from Localstack containers to an actual AWS
> >> instance
> >> > by
> >> > > >> > simply
> >> > > >> > > > adjusting the test parameters. It still uses testcontainers
> >> > under
> >> > > >> the
> >> > > >> > > hood,
> >> > > >> > > > but it is abstracted from the test code.
> >> > > >> > > >
> >> > > >> > > > As result of this migration, the code in the following
> >> > components
> >> > > >> has
> >> > > >> > > > become unused within Camel:
> >> > > >> > > > - camel-testcontainers
> >> > > >> > > > - camel-testcontainers-junit5
> >> > > >> > > > - camel-testcontainers-spring
> >> > > >> > > > - camel-testcontainers-spring-junit5
> >> > > >> > > >
> >> > > >> > > > I'd like to propose deprecating these components, starting
> >> with
> >> > > 3.8
> >> > > >> and
> >> > > >> > > > then removing them before we release the next LTS.
> >> > > >> > > >
> >> > > >> > > > Therefore, I'd like to gather feedback from the community
> >> about
> >> > > >> usage
> >> > > >> > of
> >> > > >> > > > those modules, thoughts on the idea and if any roadblock
> >> > remains.
> >> > > >> > > >
> >> > > >> > > > Kind regards
> >> > > >> > > > --
> >> > > >> > > > Otavio R. Piske
> >> > > >> > > > http://orpiske.net
> >> > > >> > >
> >> > > >> > >
> >> > > >> > >
> >> > > >> > > --
> >> > > >> > > Claus Ibsen
> >> > > >> > > -----------------
> >> > > >> > > http://davsclaus.com @davsclaus
> >> > > >> > > Camel in Action 2: https://www.manning.com/ibsen2
> >> > > >> > >
> >> > > >> >
> >> > > >> >
> >> > > >> > --
> >> > > >> > Otavio R. Piske
> >> > > >> > http://orpiske.net
> >> > > >> >
> >> > > >>
> >> > > >
> >> > > >
> >> > > > --
> >> > > > Otavio R. Piske
> >> > > > http://orpiske.net
> >> > > >
> >> > >
> >> > >
> >> > > --
> >> > > Otavio R. Piske
> >> > > http://orpiske.net
> >> > >
> >> >
> >>
> >
> >
> > --
> > Otavio R. Piske
> > http://orpiske.net
> >
>
>
> --
> Otavio R. Piske
> http://orpiske.net



-- 
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2