Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Split off the DockerClientFactory from this library #240

Open
ldcasillas-progreso opened this issue Oct 27, 2016 · 5 comments
Open

Split off the DockerClientFactory from this library #240

ldcasillas-progreso opened this issue Oct 27, 2016 · 5 comments
Labels
Milestone

Comments

@ldcasillas-progreso
Copy link

Most times I play with other Docker/Java libraries than TestContainers I end up in a world of dependency or configuration hell. It seems like one of the biggest reasons for this is this library's DockerClientFactory class, which does a really excellent job of inspecting the environment and choosing the best way of running Docker on the local machine with very little user intervention.

This is particularly instrumental when trying to convince other users to adopt Docker-based unit testing—if it doesn't "just work" (as it does!), skeptical developers are prone to reject the whole thing.

Therefore, I think that this class and its supporting cast should perhaps be split off into a separate package or merged upstream so that more people and projects can benefit this most commendable work. I know I'd certainly use it!

@rnorth
Copy link
Member

rnorth commented Nov 20, 2016

Hi Luis,
Sorry for the delay in getting back to you on this and other tickets - I've had too much else going on lately but hopefully back to normal soon!

I think this is a fair idea; let's just think about the best approach. A separate JAR release from the testcontainers project would be fine, but maybe it's more appropriate to contribute it to the docker-java project if they'd like to have it. It is, after all, coupled to that library, and should also be of utility to their other users.

What do people think?

@rnorth rnorth modified the milestone: 2.0 Jan 14, 2017
@rnorth rnorth added the type/breaking-api-change Public APIs are being changed label Jan 14, 2017
@stale
Copy link

stale bot commented Oct 28, 2018

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you believe this is a mistake, please reply to this comment to keep it open. If there isn't one already, a PR to fix or at least reproduce the problem in a test case will always help us get back on track to tackle this.

@stale stale bot added the stale label Oct 28, 2018
@rnorth
Copy link
Member

rnorth commented Oct 28, 2018

We have this assigned to the 2.0 milestone, so do intend to bear it in mind for the next breaking release still.

@stale stale bot removed the stale label Oct 28, 2018
@stale
Copy link

stale bot commented Jan 26, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you believe this is a mistake, please reply to this comment to keep it open. If there isn't one already, a PR to fix or at least reproduce the problem in a test case will always help us get back on track to tackle this.

@stale stale bot added the stale label Jan 26, 2019
@stale
Copy link

stale bot commented Feb 9, 2019

This issue has been automatically closed due to inactivity. We apologise if this is still an active problem for you, and would ask you to re-open the issue if this is the case.

@stale stale bot closed this as completed Feb 9, 2019
@rnorth rnorth reopened this Feb 9, 2019
@stale stale bot removed the stale label Feb 9, 2019
@stale stale bot removed the stale label Feb 9, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants