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.middle...@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 <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 > > > > -- // Mantas --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
