'Re: Best practice to update dependency versions for *many* projects to the current version'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       maven-user
Subject:    Re: Best practice to update dependency versions for *many* projects to the current version
From:       Jim N <northrup.james () gmail ! com>
Date:       2021-09-03 15:31:07
Message-ID: CAPkEcwhWJ=JyUfFTNAiqz6GDnmLjgwHrX=NpVyCu-dzE4YVf9Q () mail ! gmail ! com
[Download RAW message or body]


mvn versions:use-latest-versions

this plugin does what it says, but also supports overriding specific ranges
in specific scopes




On Fri, Sep 3, 2021 at 4:05 PM Mantas Gridinas <mgridinas@gmail.com> wrote:

> It's a matter of preference, really. But I'd like to avoid anything
> that I can override via command-line unless it is documented as a
> plugin property. We have profiles for that.
> 
> On Thu, Sep 2, 2021 at 10:52 PM Delany <delany.middleton@gmail.com> wrote:
> > 
> > Mantas, why dont you use properties for versions? I found that some
> plugins
> > don't pick up artifact versions from dependencyManagement, breaking the
> > uniformity that depmng supposedly offers. Properties ensure a single
> source
> > of truth.
> > Delany
> > 
> > On Thu, 2 Sept 2021 at 17:35, Mantas Gridinas <mgridinas@gmail.com>
> wrote:
> > 
> > > You might be interested in running the POM per application rather than
> > > some global singular POM, since you should retain the ability to
> > > update a single application's dependencies without breaking other
> > > applications' behavior. I agree that this approach is the more time
> > > consuming than having some company wide common dependency list, but it
> > > all boils down to if you have an extensive test suite and if you are
> > > willing to redeploy all the applications when that super-pom (or BOM)
> > > is changed.
> > > 
> > > "Maven dependency mechanism" is a good read in general. The only thing
> > > I disagree with is using properties for versions of artifacts.
> > > 
> > > Since you're also migrating existing applications, I suppose you have
> > > some JAR folder that you (or it was done for you) copy over by hand.
> > > To prevent breakage when using external versions of said JARs you
> > > might want to use install plugin's install-file
> > > (
> > > 
> https://maven.apache.org/plugins/maven-install-plugin/install-file-mojo.html
> > > )
> > > goal to copy those files over into the common .m2 repository and then
> > > isolate your builds from network by either using private nexus or
> > > using offline mode.
> > > 
> > > On Thu, Sep 2, 2021 at 6:07 PM Nils Breunese <nils@breun.nl> wrote:
> > > > 
> > > > Another option is creating an artifact of type ‘pom' that consists of
> > > just a pom.xml with a <dependencyManagement> section and optionally
> > > properties for the versions (so they can easily be overridden when
> needed),
> > > and importing this BOM (bill of materials) artifact in your
> applications.
> > > > 
> > > > See spring-boot-dependencies for an example:
> > > 
> https://search.maven.org/artifact/org.springframework.boot/spring-boot-dependencies/2.5.4/pom
> 
> > > > 
> > > > You can use such an artifact as the parent of your applications
> > > (especially handy if you also want to centralize plugin configurations,
> > > etc.), or import its dependency management like this:
> > > > 
> > > > <dependencyManagement>
> > > > <dependencies>
> > > > <dependency>
> > > > <groupId>com.example</groupId>
> > > > <artifactId>example-dependencies</artifactId>
> > > > <version>1.0.0</version>
> > > > <type>pom</type>
> > > > <scope>import</scope>
> > > > </dependency>
> > > > </dependencies>
> > > > </dependencyManagement>
> > > > <dependencies>
> > > > <dependency>
> > > > <groupId>com.example</groupId>
> > > > <artifactId>example-artifact</artifactId>
> > > > <!-- Don't provide a version here, that version is centrally
> managed
> > > in example-dependencies -->
> > > > </dependemcy>
> > > > </dependencies>
> > > > 
> > > > See
> > > 
> https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#bill-of-materials-bom-poms
> 
> > > for more information about BOM POMs.
> > > > 
> > > > Nils.
> > > > 
> > > > > Op 2 sep. 2021, om 16:52 heeft Delany <delany.middleton@gmail.com>
> > > het volgende geschreven:
> > > > > 
> > > > > Hi Bruno,
> > > > > 
> > > > > You can define a property in a project all projects inherit from
> > > > > 
> > > > > <properties>
> > > > > <dep.cglib.cglib>3.2.4</dep.cglib.cglib>
> > > > > 
> > > > > Then add a dependencyManagement section that sections the version
> > > > > 
> > > > > <dependencyManagement>
> > > > > <dependencies>
> > > > > <dependency>
> > > > > <groupId>cglib</groupId>
> > > > > <artifactId>cglib</artifactId>
> > > > > <version>${dep.cglib.cglib}</version>
> > > > > 
> > > > > And use this plugin to check for updates etc
> > > > > https://www.mojohaus.org/versions-maven-plugin/
> > > > > 
> > > > > Delany
> > > > > 
> > > > > On Thu, 2 Sept 2021 at 16:40, Bruno <x.maven@melloni.com> wrote:
> > > > > 
> > > > > > I have been developing in Java almost from the beginning, but
> have not
> > > > > > used Maven for much more than a few personal test apps. I am now
> about
> > > > > > to migrate nearly 100 applications to Maven and I am a bit
> concerned
> > > > > > about how to manage dependency versions across that many projects
> in
> > > the
> > > > > > future.
> > > > > > 
> > > > > > For a single app it is simple, go into the POM, modify the
> version of
> > > > > > the dependency, then verify that nothing broke due to newly
> > > unsupported
> > > > > > methods and fix the issues.
> > > > > > 
> > > > > > But if you have a lot of applications, the above method becomes
> very
> > > > > > time consuming and manual.
> > > > > > 
> > > > > > QUESTION:  Is there a best practice (or perhaps tools that help)
> for
> > > how
> > > > > > to handle updating the dependency versions for that many
> applications?
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > > > > > For additional commands, e-mail: users-help@maven.apache.org
> > > > > > 
> > > > > > 
> > > > 
> > > > 
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: users-help@maven.apache.org
> > > > 
> > > 
> > > 
> > > --
> > > // Mantas
> > > 
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: users-help@maven.apache.org
> > > 
> > > 
> 
> 
> 
> --
> // Mantas
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
> 
> 



[prev in list] [next in list] [prev in thread] [next in thread]
Configure | About | News | Add a list | Sponsored by KoreLogic