You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Bruno <x....@melloni.com> on 2021/09/02 14:40:29 UTC
Best practice to update dependency versions for *many* projects to
the current version
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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Dumb question: How to deploy a command line app?
Posted by Anders Hammar <an...@hammar.net>.
One can also use the assembly plugin [1] to create a distributable file
that contains all this. That's what I would do.
The standard build process will only build the artifact and put it in the
maven repo, which is what you're seeing currently.
[1] https://maven.apache.org/plugins/maven-assembly-plugin/
/Anders
On Thu, Sep 23, 2021 at 8:11 AM Mantas Gridinas <mg...@gmail.com> wrote:
> Use dependencies plugin and copy-dependencies goal. This will copy over all
> of your dependencies into target/dependency folder. .m2 catalog already
> contains your dependencies but in reapective subfolders. Ex. foo.bar:parser
> would be under .m2/repository/foo/bar/parser
>
> On Thu, Sep 23, 2021, 09:00 Bruno Melloni <bm...@melloni.com> wrote:
>
> > Given that the whole point of using Maven is to "not have to worry about
> > dependencies" I am having the most ironic (and probably trivial) problem:
> >
> > - Using Maven in Eclipse.
> >
> > - I wrote a very simple utility. It builds as part of a JAR that will
> > normally be used by other apps, but this utility can be executed from
> > the command line.
> >
> > - So, to run the utility on a server I did a RunAs/Maven/Install. It
> > placed the JAR in the expected .m2 location but... none of the JARs it
> > depends on are there.
> >
> >
> > How do I tell Eclipse to run a Maven Install that puts *everything*
> > needed by the project to run in one folder or folder tree?
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
Re: Dumb question: How to deploy a command line app?
Posted by Mantas Gridinas <mg...@gmail.com>.
Use dependencies plugin and copy-dependencies goal. This will copy over all
of your dependencies into target/dependency folder. .m2 catalog already
contains your dependencies but in reapective subfolders. Ex. foo.bar:parser
would be under .m2/repository/foo/bar/parser
On Thu, Sep 23, 2021, 09:00 Bruno Melloni <bm...@melloni.com> wrote:
> Given that the whole point of using Maven is to "not have to worry about
> dependencies" I am having the most ironic (and probably trivial) problem:
>
> - Using Maven in Eclipse.
>
> - I wrote a very simple utility. It builds as part of a JAR that will
> normally be used by other apps, but this utility can be executed from
> the command line.
>
> - So, to run the utility on a server I did a RunAs/Maven/Install. It
> placed the JAR in the expected .m2 location but... none of the JARs it
> depends on are there.
>
>
> How do I tell Eclipse to run a Maven Install that puts *everything*
> needed by the project to run in one folder or folder tree?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Dumb question: How to deploy a command line app?
Posted by Bruno Melloni <bm...@melloni.com>.
Given that the whole point of using Maven is to "not have to worry about
dependencies" I am having the most ironic (and probably trivial) problem:
- Using Maven in Eclipse.
- I wrote a very simple utility. It builds as part of a JAR that will
normally be used by other apps, but this utility can be executed from
the command line.
- So, to run the utility on a server I did a RunAs/Maven/Install. It
placed the JAR in the expected .m2 location but... none of the JARs it
depends on are there.
How do I tell Eclipse to run a Maven Install that puts *everything*
needed by the project to run in one folder or folder tree?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Best practice to update dependency versions for *many* projects
to the current version
Posted by Nick Stolwijk <ni...@gmail.com>.
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 <mg...@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 <ni...@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 <de...@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....@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-unsubscribe@maven.apache.org
> > >> For additional commands, e-mail: users-help@maven.apache.org
> > >>
> > >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
>
>
> --
> // Mantas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Best practice to update dependency versions for *many* projects
to the current version
Posted by Jim N <no...@gmail.com>.
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 <mg...@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 <de...@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 <mg...@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 <ni...@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 <de...@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....@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-unsubscribe@maven.apache.org
> > > > >> For additional commands, e-mail: users-help@maven.apache.org
> > > > >>
> > > > >>
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: users-help@maven.apache.org
> > > >
> > >
> > >
> > > --
> > > // Mantas
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: users-help@maven.apache.org
> > >
> > >
>
>
>
> --
> // Mantas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Best practice to update dependency versions for *many* projects
to the current version
Posted by Mantas Gridinas <mg...@gmail.com>.
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 <de...@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 <mg...@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 <ni...@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 <de...@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....@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-unsubscribe@maven.apache.org
> > > >> For additional commands, e-mail: users-help@maven.apache.org
> > > >>
> > > >>
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: users-help@maven.apache.org
> > >
> >
> >
> > --
> > // Mantas
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
--
// Mantas
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Best practice to update dependency versions for *many* projects
to the current version
Posted by Delany <de...@gmail.com>.
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 <mg...@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 <ni...@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 <de...@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....@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-unsubscribe@maven.apache.org
> > >> For additional commands, e-mail: users-help@maven.apache.org
> > >>
> > >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
>
>
> --
> // Mantas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Best practice to update dependency versions for *many* projects
to the current version
Posted by Mantas Gridinas <mg...@gmail.com>.
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 <ni...@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 <de...@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....@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-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: users-help@maven.apache.org
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
--
// Mantas
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Best practice to update dependency versions for *many* projects
to the current version
Posted by Nils Breunese <ni...@breun.nl>.
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 <de...@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....@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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Best practice to update dependency versions for *many* projects
to the current version
Posted by Delany <de...@gmail.com>.
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....@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>