maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Podgursky <>
Subject Re: Best strategy for using lots of modules/projects with some private and some OSS
Date Fri, 25 Sep 2015 18:22:56 GMT
On Fri, Sep 25, 2015 at 10:53 AM, Bernd <> wrote:

> Hello Ben,
> 2015-09-23 0:28 GMT+02:00 Ben Podgursky <>:
> > +1 for aggressive SNAPSHOT use
> >
> > Our setup.  YMMV:
> >
> > ...
> > - All developers have all code checked out in intellij, source linked
> > - If you push changes to a library, you update all downstream usages.  No
> > exceptions.  Since you have all source in intellij, this usually isn't
> > hard.
> >
> How do you deal with changes  to multiple projects (as you suggest) when
> you do not use a mono repository? When one commit kicks off Jenkins it
> might as well not yet see the "fixed" snapshot dependency. Do you use
> atomic commits or a monorepo or do you trigger jenkin builds only by time?
We encourage devs to do non-breaking migrations when possible -- deprecate,
switch usages, and then remove the old methods.  When that's not practical,
we just push everything at once.  Since projects and builds are small and
short (almost all < 10 min), we just live with a broken build for a couple
minutes while upstream deploys run.  But it's the responsibility of the dev
making the changes to make sure everything is converging cleanly or revert
the changes.

> BTW: just my few cents, we added Gerrit to the mix, so we can have
> pre-commit builds. But those only run the tests for the modified project,
> they do not integrate. The normal CI jobs are triggert when submitting the
> change (but typically no downstream projekt gets the snapshots as we have
> them locked on releases. Once you do the release and add the dependency to
> the BOM (or less often to dependend projects) another integration build
> triggers a while pipeline (producing ultimatively a new installation media
> which gets automatically integration tested).
> Gruss
> Bernd

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message