I have a couple of maven projects with this basic structure:

root
  my-group:app
    my-group:app-core, parent my-group:app
      class Main
      dependency foo:foo-lib
    my-group:app-util, parent my-group:app
      dependency bar:bar-lib
  my-group:lib, parent my-group:lib-parent
    dependency bar:bar-lib

I also have the my-group:lib-parent dependency installed into my .m2

.m2
  my-group:lib-parent
    dependency qux:qux-lib

I have my-group:app and my-group:lib checked out locally in my IDE. With that, I can update things - both source code and dependencies - and they will be resolved without having to install anything in .m2. For example, if I change something in my-group:lib - e.g. update the version of bar:bar-lib - I don't have to run the whole time-consuming build cycle to install that into .m2.

The same doesn't seem to work from command line. mvn insists on using what's in .m2 first and I have not found a way to tell it to use the latest from checked out sources.

My primary motivation is avoiding this cost which is a big hindrance when iterating on the code.

In this case, all that I need is to run Main that lives in my-group:app-core. If there's a solution similar to mvn dependency:build-classpath that is local-first, .m2-second, that should work.

I'm not sure if other build systems (e.g. gradle) would allow for this, but even if they did that probably wouldn't work because other people are using maven, so I'd have to maintain two build systems.

Is there any way to make maven work like this? If not, is there anything else that can work with pom.xml without modifications to my-group:app or my-group:lib projects that would work like this? If not, do I have any options that perhaps modify these projects, but not in a way that makes syncing cumbersome (e.g. adding some unrelated files may be OK, but modifying pom.xml or maintaining an equivalent copy for the other build tool probably not)?

I tried looking into using https://github.com/apache/maven-resolver, but what I've tried so far is either very brittle (e.g. doesn't handle versions via properties or dependencyManagement) or requires installing in .m2 anyway, defeating the purpose.