maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anders Hammar <and...@hammar.net>
Subject Re: dependency management across projects
Date Mon, 03 Feb 2014 07:21:38 GMT
>
> > 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.
> > > > >
> > > >
> > >
> >
>

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