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 <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 > >
