[Hawkular-dev] maven stuff

[Heiko W.Rupp]

> Am 24.02.2015 um 20:01 schrieb John Mazzitelli <mazz at redhat.com>:
> to merge it, up the version number, release it, then go to the kettle repo, up the version number of the bus artifacts, create PR/merge it, and release it. People would still be waiting for a good kettle build :)

Actually this morning (MET) Travis did not have a good build, because a not-yet-built dependency was 
introduced and hawkular/kettle was not finding it.
This seems to finally build again after kicking all the individual CI builds in correct order.

Asking that we need to be able to apply duct tape all over the mistakes we made a few minutes ago
when not following the more strict rules that could have prevent havoc in the first place, may be a flawed argument.

I like the absolute freedom to be able to just commit what I want.
On the other hand  I make mistakes and it is good that peer review and CI can catch them before they hit master.

What is wrong in a PR to say depends on foo-M123 and bar-M245 ?
Or that Hawkular-1.0.0.GA.Super.Duper.Cool will internally depend on metrics-M345 and inventory-M23 ?

Also with the idea of "release early, release often" and "make small customer visible changes", master and
the PRs should not diverge too much, but will allow PR-builds to depend on a defined set of dependencies.
Today when you say "depends on bla-SNAPSHOT", you don't know what version of bla-SNAPSHOT will
be used in CI (or later even in CD ).

Instead of using Milestones (Mxxx) we can also introduce/use timestamped snapshots.

And Lukas: Now suppose you change the inventory-implementation to the future branch, which has a different REST-api, different domain objects and a few other things. Once that hits master, every other component depending on Inventory (UI , Pinger, ??) will 
fail as they just pull the new snapshot and have compile or runtime failures. With some "luck" you only see that after someone assembles the Kettle and runs it.
Here allowing the UI / Pinger to still build/run against inventory-current will help to transition them over to the new api, as the Kettle will still build and work. And only if the Pinger dev explicitly says "Now I want inventory-future and have changed my code", that breakage is prevented. And yes, I know this still requires the 3 components being introduced in lock-step, which could be prevented by content-negotiation, which we need to introduce once the existing apis have stabilized.