On 18 Jun 2014, at 17:05, Barrie Treloar wrote:
It takes a small (but not negligible) amount of time to haul the
release
jars from you local Maven Repository - likely also hosted on your CI
server.
Plus pulling in any snapshots previously deployed.
The problem gets extended further when you're actually wanting topic
isolation of related, independent changes.
If your CI server can't work out that two projects share a dependency
relationship are in the build queue then you are left with manual
workarounds.
In some cases - such as my github based open source projects, using
either Travis CI or Cloudbees BuildHive - the projects cannot know
they're related - at least AFAIK there's no way of indicating that.
Sharing a local maven cache (~/.m2/repo) feels wrong for two
independent projects. And if they are dependent they should be built
together in the same reactor project.
Whilst they're technically independent projects because of using git -
where they MUST be due to how maven-release-plugin works, and how git
branches/tags - they are related, but differ in release cadence.
In-progress reviews that introduce related changes to both require
visibility or each others current builds, but neither knows what SHA1
they relate to, unless you start introducing git-submodules and
source-dependencies - but that makes for rather wacky repository layouts
and monolithic maven builds.
As for review, if they are independent why do they need to be reviewed
together?
99% of the time they are independent, as the API changes at a slower
cadence, but sometimes - changes affect both - and should be review in
relation to each other.
Perhaps rethinking the workflow is an option?
Possibly - at this stage it's looking like "don't use github - or the
biggest CI environment on the planet" - sadly.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
