Contributing to Ecotone

Preparing development environment

Start by cloning ecotone-dev repository.

1. To run your local environment with tests:

2. Copy .env.dist to .env and start docker containers

   docker-compose up -d

3. To run tests for monorepo:

   docker exec -it ecotone_development composer tests:local

4. To run tests for given module

   docker exec -it -w=/data/app/packages/Dbal ecotone_development composer tests:ci

5. Clear development environment

   docker-compose down

Debugging code

Development containers comes with xdebug installed, so you can debug directly from IDE.

• To have enabled debugging all the time, change line in your .env file to

  XDEBUG_ENABLED="1"

  and rebuild containers:

  docker-compose down && docker-compose up -d

• As having xdebug enabled all the time, may slow your test execution, you may run it conditionally for given test case

  docker exec -it ecotone_development xdebug vendor/bin/phpunit --filter test_calling_command_on_aggregate_and_receiving_aggregate_instance

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.

Ecotone Concepts

Even though Ecotone introduces its own concepts, many of them already existed. A good source of information is Gregor Hohpe's Enterprise Integration Patterns website and accompanying book.

For example, if you're interested in what Service Activator is, you make take a look here.

You may also take a look on previous chapters 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 NServiceBus or Java's Spring Integration (which is foundation for Spring Cloud), as they are also built on top of EIP patterns.

Contribution guidelines

• 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.

• 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 Ecotone Lite). 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 Ecotone's community channel to get quick feedback and help with your implementation.

Articles on how internal works

• Building Message-Driven Framework - Foundation