Re: Best practice to update dependency versions for *many* projects to the current version
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 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 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
> 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 wrote:
> > > >
> > > > Another option is creating an artifact of type ‘pom’ that consists of
> > > just a pom.xml with a 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:
> > > >
> > > >
> > > >
> > > >
> > > > com.example
> > > > example-dependencies
> > > > 1.0.0
> > > > pom
> > > > import
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > com.example
> > > > example-artifact
> > > >
> > > >
> > > >
> > > >
> > > > 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
> > > het volgende geschreven:
> > > > >
> > > > > Hi Bruno,
> > > > >
> > > > > You can define a property in a project all projects inherit from
> > > > >
> > > > >
> > > > > 3.2.4
> > > > >
> > > > > Then add a dependencyManagement section that sections the version
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >cglib
> > > > >cglib
> > > > >${dep.cglib.cglib}
> > > > >
> > > > > 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 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,
Re: Best practice to update dependency versions for *many* projects to the current version
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 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 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 wrote:
> > >
> > > Another option is creating an artifact of type ‘pom’ that consists of
> > just a pom.xml with a 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:
> > >
> > >
> > >
> > >
> > > com.example
> > > example-dependencies
> > > 1.0.0
> > > pom
> > > import
> > >
> > >
> > >
> > >
> > >
> > > com.example
> > > example-artifact
> > >
> > >
> > >
> > >
> > > 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
> > het volgende geschreven:
> > > >
> > > > Hi Bruno,
> > > >
> > > > You can define a property in a project all projects inherit from
> > > >
> > > >
> > > > 3.2.4
> > > >
> > > > Then add a dependencyManagement section that sections the version
> > > >
> > > >
> > > >
> > > >
> > > >cglib
> > > >cglib
> > > >${dep.cglib.cglib}
> > > >
> > > > 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 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
Re: Best practice to update dependency versions for *many* projects to the current version
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 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 wrote:
> >
> > Another option is creating an artifact of type ‘pom’ that consists of
> just a pom.xml with a 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:
> >
> >
> >
> >
> > com.example
> > example-dependencies
> > 1.0.0
> > pom
> > import
> >
> >
> >
> >
> >
> > com.example
> > example-artifact
> >
> >
> >
> >
> > 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
> het volgende geschreven:
> > >
> > > Hi Bruno,
> > >
> > > You can define a property in a project all projects inherit from
> > >
> > >
> > > 3.2.4
> > >
> > > Then add a dependencyManagement section that sections the version
> > >
> > >
> > >
> > >
> > >cglib
> > >cglib
> > >${dep.cglib.cglib}
> > >
> > > 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 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
>
>
Re: Best practice to update dependency versions for *many* projects to the current version
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 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 wrote:
> >
> > Another option is creating an artifact of type ‘pom’ that consists of
> just a pom.xml with a 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:
> >
> >
> >
> >
> > com.example
> > example-dependencies
> > 1.0.0
> > pom
> > import
> >
> >
> >
> >
> >
> > com.example
> > example-artifact
> >
> >
> >
> >
> > 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
> het volgende geschreven:
> > >
> > > Hi Bruno,
> > >
> > > You can define a property in a project all projects inherit from
> > >
> > >
> > > 3.2.4
> > >
> > > Then add a dependencyManagement section that sections the version
> > >
> > >
> > >
> > >
> > >cglib
> > >cglib
> > >${dep.cglib.cglib}
> > >
> > > 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 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
>
>
Re: Best practice to update dependency versions for *many* projects to the current version
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 wrote:
>
> Another option is creating an artifact of type ‘pom’ that consists of just a
> pom.xml with a 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:
>
>
>
>
> com.example
> example-dependencies
> 1.0.0
> pom
> import
>
>
>
>
>
> com.example
> example-artifact
>
>
>
>
> 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 het
> > volgende geschreven:
> >
> > Hi Bruno,
> >
> > You can define a property in a project all projects inherit from
> >
> >
> > 3.2.4
> >
> > Then add a dependencyManagement section that sections the version
> >
> >
> >
> >
> >cglib
> >cglib
> >${dep.cglib.cglib}
> >
> > 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 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
Re: Best practice to update dependency versions for *many* projects to the current version
Another option is creating an artifact of type ‘pom’ that consists of just a
pom.xml with a 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:
com.example
example-dependencies
1.0.0
pom
import
com.example
example-artifact
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 het
> volgende geschreven:
>
> Hi Bruno,
>
> You can define a property in a project all projects inherit from
>
>
> 3.2.4
>
> Then add a dependencyManagement section that sections the version
>
>
>
>
>cglib
>cglib
>${dep.cglib.cglib}
>
> 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 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
Re: Best practice to update dependency versions for *many* projects to the current version
Hi Bruno,
You can define a property in a project all projects inherit from
3.2.4
Then add a dependencyManagement section that sections the version
cglib
cglib
${dep.cglib.cglib}
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 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
>
>
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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
