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 Tue, 04 Feb 2014 09:54:25 GMT
On Mon, Feb 3, 2014 at 8:21 AM, Anders Hammar <anders@hammar.net> wrote:

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

Right!

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

It is. The tool I aim to create is more report-based. Something that would
gather the dependencies on each sub-projects and report inconsistencies: a
dependency unknown to the product has been added or removed, etc.

Thanks for brainstorming this with me. It feels that we're indeed lacking
for a standard solution for this in the Maven land. Will look into that and
report here my progress

S.


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

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