Contributing to Ecotone
Last updated
Last updated
Start by cloning .
To run your local environment with tests:
Copy .env.dist to .env and start docker containers
To run tests for monorepo:
To run tests for given module
Clear development environment
Development containers comes with installed, so you can debug directly from IDE.
To have enabled debugging all the time, change line in your .env file to
and rebuild containers:
As having xdebug enabled all the time, may slow your test execution, you may run it conditionally for given test case
If you're asked about mapping path, map your xdebug server to "/data/app" and name it "project", if you have not changed xdebug project name.
Make use of real providers in tests - This means, if integrating with RabbitMQ/SQS write tests that actually make use of this Message Brokers. This will ensure, that tests will stay the same, even if underlying 3rd party library/SDK will change.
Even though Ecotone introduces its own concepts, many of them already existed. A good source of information is Gregor Hohpe's website and accompanying book.
For example, if you're interested in what Service Activator is, you make
You may also take a look on to get familiar with fundamental building blocks.
Due to the fact that Ecotone is based on EIP patterns, you will find a lot of similarities to well known frameworks in other languages, like C#'s or Java's (which is foundation for ), as they are also built on top of EIP patterns.
Focus on client level code - Your tests do not need to test every single class you add to the repository. It's more valuable from perspective of long term maintenance to focus on tests that will be testing on the high level (using ). Those tests will be also similar to the ones, you will be writing in your own Ecotone based projects.
Ask questions in case you need some help - You can use to get quick feedback and help with your implementation.