Your commits should be broken into logical units with clear descriptions of what you're fixing and why. Looking at the commits you should probably have 1 where you add the example and then another where you fix the problem.
To be clear, I'm not indicating the fix is valid at this point as it's not clear to me what specifically you're fixing and why. The commits need to be better organized before I can actually get to that point.
Can you help me understand how the commits should be organized?
The commit "Mqtt cluster" has the scenario I want to test.
The commit "ARTEMIS-1523 Fixing mqtt dynamic cluster" is the fix for that scenario.
The other commits are just pom stuff.
In the scenario you have:
- two brokers using dynamic cluster (I think is the right term) and receiving mqtt messages
- the brokers have a queue configured with anycast
- two consumers, each one subscribing the broker 1 and the other subscribing the broker 2
- one producer sending 3 messages to broker 1
The goal is to receive the the first and third message in the consumer 1 and the second message in the broker 2.
> Can you help me understand how the commits should be organized?
Commits should be organized into logical units. You shouldn't have a commit adding the example and then a handful of smaller commits fixing stuff in the example you added in a previous commit. All those commits should be squashed together into a single commit and then the commit message should follow the recommendation from the [Hacking Guide](https://github.com/apache/activemq-artemis/blob/master/docs/hacking-guide/en/maintainers.md#commit-messages). Git makes it easy to manipulate commits so take advantage of its power.
Once everything is organized in a sane manner I'll take a look at the actual commit (assuming I have time).