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 <mgridi...@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.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 > >