Mailing-List: contact users-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Maven Users List" <users@maven.apache.org>
Received-SPF: pass (athena.apache.org: domain of anders.g.hammar@gmail.com
 designates 74.125.82.47 as permitted sender)
MIME-Version: 1.0
Sender: anders.g.hammar@gmail.com
In-Reply-To: 
 <CAOonoheiu4EWX6p_g=FJHkRHqmBaG+PJoFbeS=7M9nh+DQhA5g@mail.gmail.com>
References: 
 <CAOonohfsbrJ-7pxsEYFhLJvzb9KS+V6tnM0Je46Ep3m8YLFWSg@mail.gmail.com>
	<CAKDUN1vjCWVKV8BQZkjAW4Xb96z_41mhRmP=TNzLHxaX=YdCGg@mail.gmail.com>
	<CAOonohc6YwtXH-LtEHv3PGnv57cQ0YjWUvcTp9VZ1+Bj8DN7sQ@mail.gmail.com>
	<CAKDUN1v-0t+DhVnYi3CXFa_0UBs+KXXnR3jeDWqaETFQOO8r=Q@mail.gmail.com>
	<CAOonoheiu4EWX6p_g=FJHkRHqmBaG+PJoFbeS=7M9nh+DQhA5g@mail.gmail.com>
Date: Mon, 3 Feb 2014 08:21:38 +0100
Message-ID: 
 <CAKDUN1swy7w7bjj12f7kffY=d-fD=eOThpz-tLgMg7dfBjaC_g@mail.gmail.com>
Subject: Re: dependency management across projects
From: Anders Hammar <anders@hammar.net>
To: Maven Users List <users@maven.apache.org>
Content-Type: multipart/alternative; boundary=047d7bfcf00adfb01804f17b5f84

--047d7bfcf00adfb01804f17b5f84
Content-Type: text/plain; charset=ISO-8859-1

>
> > 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)
>

I believe so, yes. The key thing in my "solution" is the BOM. And the BOM
will keep the appropriate version of the the sub-products together.


> 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.
>

There is no automatic solution for this that I know of. I suppose that
tolls could be created, but keep in mind that in the end, "for backward
compatibility reason SP2 has to use 1.8.0" is normally a human decision.

/Anders


>
> 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.
> > > > >
> > > >
> > >
> >
>

--047d7bfcf00adfb01804f17b5f84--