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:55:17 GMT
Thanks for the feedback. This looks like something that the
versions-maven-plugin could do. There's something similar that is
advertised by the plugin documentation but it's not implemented. I'll have
a look to that too.

Thanks!
S.


On Mon, Feb 3, 2014 at 6:39 PM, Curtis Rueden <ctrueden@wisc.edu> wrote:

> Hi everyone,
>
> > > The very point I am trying to make here is
> > > "how do you manage that manual BOM on a daily basis".
> >
> > There is no automatic solution for this that I know of.
>
> Maybe not exactly what you are looking for, but sort of similar:
>
> My group uses a script [1] to automatically bump the version of our parent
> POM [2].
>
> In that parent POM, we declare many version properties, plugin
> configuration in pluginManagement, etc., and we like to keep all our
> projects across various Git repositories using the newest available version
> of the parent, to minimize version clashes when mixing and matching
> libraries.
>
> We set up a parameterized Jenkins job [3] to run the parent bump for us,
> which provides checkboxes for all the downstream projects so the bump can
> be controlled individually.
>
> It's not perfect but it does save a lot of manual maintenance.
>
> Regards,
> Curtis
>
> [1]
>
> https://github.com/scijava/scijava-scripts/blob/a0fc8006741e0216c74c82866fd1bb1a7d364d55/bump-pom-scijava.sh
> [2]
>
> https://github.com/scijava/pom-scijava/blob/0de0676f7731b98baa89379dc8b92f8b26a5d086/pom.xml
> [3] http://jenkins.imagej.net/view/SciJava/job/Bump-POM-SciJava/
>
>
> On Mon, Feb 3, 2014 at 1:21 AM, 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)
> > >
> >
> > 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