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
