the use case you're describing is similar to what I'm using at my current
job: we have 3 applications and a bunch of internal libraries that are used
by those applications and, in some cases, applications developed by other
teams in the company.
Each of the applications live in a separate repository but are mult-module
maven projects to make advancing versions in all modules easier (we use the
maven release plugin for this, which isn't all that bad).
The libraries also have a repository each and use the same release process
as applications but, of course, each has its own version.
The way we've found to ease the burden of updating is having update jobs
that run the update goals in the versions maven plugin: those jobs update
the dependency versions, run a SNAPSHOT build to verify that it still
passes and, if it does, pushes the result into an updates branch that is
then reviewed and manually merged.
We use this not only for internal dependencies but external as well and
found it to work well.
The only downside so far is that you have to maintain an exclusions list
because several projects make "fake" releases like RCs and others use
"strange" versioning schemes like "odd minor versions are always unstable",
but this can be managed in a parent POM.
Hope this helps.
On 1 December 2016 at 04:53, Christian Schulte <c...@schulte.it> wrote:
> Am 11/30/16 um 19:18 schrieb Florian Schätz:
> >> A library project to be
> >> shared between multiple applications each having its own release-cycle
> >> should not be part of a multi-module project used to build such an
> >> application and should be an independent project with its own
> >> release-cycle.
> > While this is of course a good idea, especially when starting to create
> > new applications, the library projects will grow with the applications
> > and not independently of them. We cannot start by first investing months
> > to create the perfect will-work-for-ten-years library and only then
> > start coding the application that will, in the first months, only use
> > 10% of all these features. So, realistically, during a development
> > cycle, both the application and the library will grow... (which doesn't
> > mean that we cannot separate them)
> That's what I was referring to with "inheritance vs. aggregation". In a
> multi-module project you get versioning "for free" by using the
> release:prepare release:perform goals. Maintaining the build is not a
> one time task. You adjust things over time until you get things
> structured the way it fits your situation perfectly. To not be trapped
> later, you need to carefully decide the artifact coordinates in use and
> the way versions will be assigned. If a shared library has been part of
> a multi-module project together with an application, extracting it later
> should not have an impact on the rest of the build. It should carry it's
> own version from day one. It should carry it's own coordinate namespace
> from day one. Once in a multi-module project, you will soon start to
> inherit groupId and version. That can lead to having to update each and
> every application POM when extracting that library later. Starting some
> application from scatch today, keep in mind you will re-structure your
> build over time until things have been sorted out. If you know from day
> one that a specific module/project will have it's own release-cycle
> sooner or later, be prepared for that from day one.
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org