Another way of doing this is with automation. There are various tools that update a dependency, run the build and create a PR (or automerge).
If you are using Github, you can take a look at dependabot, but if you use standalone tools (like bitbucket and Jenkins) you can look at renovate. With regards, Nick Stolwijk ~~~ Try to leave this world a little better than you found it and, when your turn comes to die, you can die happy in feeling that at any rate you have not wasted your time but have done your best ~~~ Lord Baden-Powell On Thu, Sep 2, 2021 at 5:41 PM Mantas Gridinas <mgridi...@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 <n...@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.middle...@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.ma...@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-unsubscr...@maven.apache.org > > >> For additional commands, e-mail: users-h...@maven.apache.org > > >> > > >> > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > > > > -- > // Mantas > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
