Upgrade to Camel SNAPSHOT

[davsclaus]

We should migrate to Camel SNAPSHOT so we can be ready for Camel 3.0.M4 and onwards.

The initial source code is targeted for Camel 3.0.M2

We can grab the SNAPSHOT jars from Maven Snapshot repo
https://repository.apache.org/snapshots/

[ppalaga]

I'd like to ask in the most polite way whether we could please re-think this idea.

I am a full supporter of Maven SNAPSHOTs as long as they are built locally and the developer knows from which state of the source tree he has installed. They are handy, flexible and quite fast to use.

However, enabling remote SNAPSHOT repositories is a fully different story. Generally, it can be said, that with enabling remote SNAPSHOTs the build reproducibility is simply gone. With remote SNAPSHOTs on, figuring out why some particular build started failing is very hard if not even impossible, because there is no explicit link between a given SNAPSHOT artifact and the state of its source repository. (buildnumber-maven-plugin can help to mitigate this but it is still quite a lot of work to figure out the precise SHA1 the given artifact was built from.) Moreover, one never knows whether Maven has decided to pull a remote SNAPSHOT or if it is still using the SNAPSHOT I have built locally.

In past years, I can remember at least Hawkular, WildFly and WildFly Camel teams discussing this topic, and none of them has decided to use or continue using remote SHAPSHOTs, mainly because of the reproducibility concerns. Each of those projects solved the problem of continuous testing and development against not-yet-released dependencies differently:

Hawkular adopted srcdeps https://github.com/srcdeps/srcdeps-maven Disclaimer: I am the author of srcdeps.

WildFly chose releasing the dependencies often (every two weeks or so).

WildFly Camel has special integration branches that integrate locally built SNAPSHOTs of Camel and WildFly. There is a convention that the maintainer of those branches pushes the commit he has built from to his github fork's master - that's how other team members can reproduce his build.

[oscerd]

I'm not against the SNAPSHOT usage, we are using the a deploy profile on camel-k for example, on each commit we built the project and push on the SNAPSHOT repository, there is a CI job and we are usually always aligned. We can discuss this here with the team.

[davsclaus]

Okay yeah we can have it by default use a released version of Camel, but we should have an easy way to build with camel SNAPSHOT version, maybe like a maven profile

 mvn clean install -P camel-snapshot 

Then we can also have CI jobs that enable this maven profile and run tests etc.
And its easy for developers to work with latest snapshot when working on upgrading Camel or ensuring camel-quarkus will also work with next version etc.

[davsclaus]

Especially now when we need to upgrade from M2 to M4

[ppalaga]

The proposed camel-snapshot profile is fine as long as camel-quarkus does not need to get (backwards incompatibly) adapted to API changes in Camel. Such changes would then break the default profile-less build.