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 wrote:
> On Tue, Feb 8, 2022 at 9:32 AM Otavio Rodolfo Piske
> wrote:
> >
> > Hello,
> >
> > I
On Tue, Feb 8, 2022 at 9:32 AM Otavio Rodolfo Piske
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
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
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.
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 wrote:
> I'm ok with deprecating the classes :-)
>
> Il ven 8
I'm ok with deprecating the classes :-)
Il ven 8 gen 2021, 08:48 Otavio Rodolfo Piske 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
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
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,
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 ha
scritto:
> Thanks Claus! That's a good point and I haven't written much - other than
> the pre 3.7 release doc
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
Hello,
I think it's probably too early to deprecate testcontainers modules,
because test-infra modules are probably less easy to use currently.
I would leave them without deprecation for the moment.
But lets wait for more feedback.
Il giorno mar 5 gen 2021 alle ore 10:36 Claus Ibsen
ha
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
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:
13 matches
Mail list logo
