This message was deleted.

If you publish a build scan, it will have information on repository used for each dependency in each configuration

👋 Hey, @Eli Graber! I suggest reading this section of the documentation. If you still feel like you need to use

mavenLocal()

, you can apply Repository content filtering to control which dependencies are resolved on a per repository basis. A Build Scan is also a good suggestion.

And if you want a dependency resolved only from mavenLocal you could try exclusive content. I found it enough to use content filtering mentioned by @Eric Haag with exclude for same groupIds (or regexes) in some of the enterprise environments. In my case I had git-ignored marker files (with a simple build service) to activate init script to do the repo config for contractor work for a repos and content filtering rules to apply only for some projects. If you dependent libraries are gradle-built included build (with automatic substitution rules) could be a way to go too

I'm trying to solve for an issue where I'm making changes to a library (in a separate project) and want to test those changes in my main project. What I've been doing until now is add

mavenLocal

when I need it, and remove it before committing my changes. However it slows down my velocity slightly, and I'd like to speed it up by just always having

mavenLocal

used (for non ci builds). If the local repo is usually empty, would there still be a performance issue?

Is you dependent library build with Apache Maven or Gradle?

If the library you're building uses Gradle as its build tool then I would certainly consider using Composite builds as mentioned by @grossws. From the documentation:

Composite builds allow you to combine builds that are usually developed independently, for instance when trying out a bug fix in a library that your application uses

Based on what you've said so far, it does seem this describes your use case.

I'd rather not have to make changes to the project to run those tests. For a composite build I'd have to rewrite the dependency.

If dependent library use gradle you'll only have to modify

settings.gradle[.kts]

in the dependee with additional bonus of compilation avoidance. And the dependency will be the same GAV coordinates. If you use maven local you already had to modify dependee build to use

-SNAPSHOT

dependency anyway

I'm not sure your last point applies in my case. In both cases I have to add at least one thing to `settings.gradle.kts`: Add

mavenLocal

to the top of the

repositories

(which I'd like to be a one time thing) VS Add an

includeBuild

statement for each library I need So the

includeBuild

route could technically require more changes if I need more than one library (which has happened), but I'll balance that out with not needing to first deploy the library to maven local. In either case, there's still set up and clean up that has to happen, which is what I'm trying to avoid.

settings.gradle.kts

can contain logic, such as "`includeBuild` if the directory exists"

With composite build you don't need to edit any file, you can simply use the command line argument

--include-build

.

@ephemient it's likely that the directory will exist in cases where I don't want it to be used. Although I suppose I could have a gitignored directory in my project and symlink the desired included builds into there. That could be interesting, as is @Vampire approach. Thanks!