testcontainers-java

testcontainers-java copied to clipboard

Hi all,

I have been working with AWS DynamoDB and I believe this module can be useful for us. There is an official Docker image provided by AWS with some config. There is another way to use AWS DynamoDB via Localstack which uses the DynamoDBLocal.jar to create the service... but I did not find an elegant way to pass the arguments.

Some motivations:

• simple to use;
• simple to maintain;
• configurable;
• amazon/dynamodb-local:1.17.0 has 238.97 MB and localstack:0.12.20 has 345.56 MB. In that case, we have a specific image instead of another image with lots of dependencies;
• contribute to this project that I have used a lot, thank you guys!;

It is my first contribution, please feel free to guide me about it.

Checklist

Every item on this list will require judgement by the Testcontainers core maintainers. Exceptions will sometimes be possible; items with should are more likely to be negotiable than those items with must.

Default docker image

• [ ] Should be a Docker Hub official image, or published by a reputable source (ideally the company or organisation that officially supports the technology)
• [ ] Should have a verifiable open source Dockerfile and a way to view the history of changes
• [ ] MUST show general good practices regarding container image tagging - e.g. we do not use latest tags, and we do not use tags that may be mutated in the future
• [ ] MUST be legal for Testcontainers developers and Testcontainers users to pull and use. Mechanisms exist to allow EULA acceptance to be signalled, but images that can be used without a licence are greatly preferred.

Module dependencies

• [ ] The module should use as few dependencies as possible,
• [ ] Regarding libraries, either:
  • they should be compileOnly if they are likely to already be on the classpath for users' tests (e.g. client libraries or drivers)
  • they can be implementation (and thus transitive dependencies) if they are very unlikely to conflict with users' dependencies.
• [ ] If client libraries are used to test or use the module, these MUST be legal for Testcontainers developers and Testcontainers users to download and use.

API (e.g. MyModuleContainer class)

• [ ] Favour doing the right thing, and least surprising thing, by default
• [ ] Ensure that method and parameter names are easy to understand. Many users will ignore documentation, so IDE-based substitutes (autocompletion and Javadocs) should be intuitive.
• [ ] The module's public API should only handle standard JDK data types and MUST not expose data types that come from compileOnly dependencies. This is to reduce the risk of compatibility problems with future versions of third party libraries.

Documentation

• [ ] Every module MUST have a dedicated documentation page containing:
  • [ ] A high level overview
  • [ ] A usage example
  • [ ] If appropriate, basic API documentation or further usage guidelines
  • [ ] Dependency information
  • [ ] Acknowledgements, if appropriate
• [ ] Consider that many users will not read the documentation pages - even if the first person to add it to a project does, people reading/updating the code in the future may not. Try and avoid the need for critical knowledge that is only present in documentation.

Hi @ClaudenirFreitas Thank you for your kind submission. It looks like you've put a lot of care and effort into this, and we're always grateful when contributors try to construct things well.

Unfortunately we're in a difficult position with DynamoDB emulation: we already have Localstack (as you're aware) and Dynalite (which is honestly outdated and should be removed).

As you can see, with two parallel modules that aim to emulate DynamoDB we're already failing to keep both up-to-date. Adding a third feels like it would be an extra maintenance overhead that we don't have capacity for.

So I'm afraid right now we have to turn this down for now - I'm sorry for this. We would still encourage you to consider hosting this yourself (on GitHub and publishing a JAR to maven central). We're working on documenting Testcontainers modules better - sort of an index of modules that live both within and outside the testcontainers-java repo. If you'd like to self-publish, then we would be keen to make sure you get recognition for this work.

Hi @rnorth, I understand your considerations. For me, LocalStack is an interesting project because we can use it with other services like API Gateway, Kinesis, Lambda and others. I totally agree with you because Dynalite isn't using an official way provided by AWS and it's just a wrapper. Like you said, the project is outdated. When I created this module, I was thinking about creating a simple way to create DynamoDB using this official image without other dependencies or wrapper. Does it make sense to replace Dynalite with this one?

In the light of @rnorth's original answer and our interest to focus on Localstack for now, we are closing this issue. Nevertheless, thanks a lot for your contribution and the discussion @ClaudenirFreitas.

sorry guys, This module will be beneficial for Java developers. .NET developers already have it and also have the LocalStack.
AWS is providing Docker image officially, I don't know if AWS recognizes the Dynalite and LocalStack as the official tools for Java developers.

thanks again