From my point of view tychos option 'localArtifacts=ignore' should
becoem the new default in Tycho 2.0 as the current default is really
bad. Relying on localy build artifacts (from whatever reason), treatens
the stability of the build and could lead to various obsuce errors
happening.
That's arguable. The thing is that Maven has `mvn install` and a default behavior to look in the local repo; those are things that are here and will stay as far as I know.
The current defaults with Tycho are made to map the default logic of Maven (combining `mvn install` then anything makes the installed artifact have priority over remote ones), it's the Maven way, and diverging from that will confuse users who are fluent with Maven. That's IMO quite important Tycho remains a Maven "extension" and work as such more than forking Maven logic that's been set in stone years ago.
Of course, Maven default aren't what's best for p2, but remember we're plugging p2 as addition to Maven, not the other way round, so Tycho needs to bend to fit as best in the host (Maven).
In summary, I think there is nothing Tycho can do OOTB for such a
scattered build.
Same is actually true for plain Maven: mixing branches without changing versions is a mess.
As mentioned before I have managed this in my last
company by using a combination of multi-checkout Jenkins file (that
supports branching of single repositories) together with a specific
maven settings and a combined update-site for development from eclipse.
That worked quite well, but also has its drawbacks (e.g. the deplay
between check-in and propagation to the update-site to other developers).
For JBoss Tools (~20 git repos), we used to just have 1 published p2 repo per Git repo, and the location of the published p2 repo contained the branch identifier, so downstream job could reference it just by changing the ${upstreamBranch} variable from `master` to `jbosstools-4.9.x`.
