maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephane Nicoll <stephane.nic...@gmail.com>
Subject Re: dependency management across projects
Date Sun, 02 Feb 2014 08:34:17 GMT
On Fri, Jan 31, 2014 at 1:16 PM, Anders Hammar <anders@hammar.net> wrote:

> The release of the BOM would be that release of "a single coherent unit"
> then. It would specify the (marketing) version of the "platform" P.
> For example, P v1.0.0 will include v1.2.3 of SP1 (sub-product 1), v1.4.3 of
> SP2, etc.
>

Isn't it what I just write in my original post? (without mentioning the BOM)


>
> Creating the BOM would be a manual work I think, as you want to make sure
> that exactly the correct versions are included (might not be the latest
> releases).
>

Yes, this is already what I do. The very point I am trying to make here is
"how do you manage that manual BOM on a daily basis". Each sub-project has
its own release cycle and we cannot force the versions it has to use for a
specific branch. For instance, the product might state that the dependency
D should be 2.2.0 (because that's the latest or the one that people
generally use) but for backward compatibility reason SP2 has to use 1.8.0.

Creating manually the first BOM for P v1.0.0 isn't a problem: i've created
a set of tools that I am happy to share once they are fully ready. But
maintaining that BOM in the long run is more of a challenge (because we
can't force the sub-projects to use those versions so we have to monitor
what happens in each sub-project to take the appropriate version at the
product level).

Thanks again for the feedback!

S.


>
> /Anders
>
>
> >
> >
> > >
> > >
> > > There is also the possibility of creating a "grouping pom", which lists
> > all
> > > artifacts as dependencies. You would then declare a dependency to that
> > > grouping pom and get all deps magically sucked in. However, this is not
> > > really the "Maven way" in my opinion as you wouldn't specify your
> direct
> > > deps bu sort of relly on transitive deps. There are some fans of this
> > > approach though here on this list.
> > >
> > >
> > > > 2. Build configs that *force* each sub-project to run with the list
> of
> > > > dependencies for the project (to ensure all tests pass, etc). This is
> > to
> > > be
> > > > used alongside the regular build job for validation purpose
> > > >
> > >
> > > Maybe some enforcer rule?
> > >
> >
> > Like I said, this is to be used alongside the regular build job. So my
> SP4
> > 1.2.0-SNAPSHOT is building with a set of dependencies on its own and I
> want
> > to validate that with the dependencies of the target release for P, it is
> > also working just fine. It may just be the same ideally or slightly
> > different (or not slightly at all which requires an explicit validation).
> >
> > So I need to be able to swap those versions for validation purposes and
> run
> > the build with that.
> >
> > S.
> >
> >
> >
> > >
> > > /Anders
> > >
> > >
> > > >
> > > > I started to look at this and my first trial was to generate a report
> > > with
> > > > all the dependencies of each project and build a consolidated report
> > > that I
> > > > can match against the candidates. This would help manage the first
> goal
> > > as
> > > > if a dependency gets added, removed or updated, the global
> > > > dependencyManagement has to be impacted manually (do we upgrade or
> not,
> > > > etc).
> > > >
> > > > For the second part, it's not easy to force a dependency change in
> > Maven,
> > > > especially if the version has been specified at the project level.
> > > >
> > > > Thanks for reading that far. If you have any idea or know any
> > > organisation
> > > > that tried to implement that, I'd be interested
> > > >
> > > > Thanks!
> > > > S.
> > > >
> > >
> >
>

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