How can I treat a dependency as resolved?

[ViToni]

I am on MacOS and have my JDK set up (which is not openjdk) and would like to use it instead of openjdk.
To avoid side effects I would like brew to treat the openjdk dependency as resolved so that it does not try to install openjdk whenever I add maven or gradle or anything else requiring openjdk.
I would prefer something "permanent" since I'm pretty sure I would forget about a command line option latest after the next vacation...

Trying to be clever I tried brew pin openjdk but since it is not installed I get an error mentioning exactly that.

Can it be done?

[SMillerDev]

You can't, brew will install the dependencies it needs. Trying to get around that is just asking for trouble.

If you want to use a different java to run your tools you can just use the JAVA_HOME environment variable though.

[carlocab]

One way to avoid installing Homebrew openjdk as a dependency is for you to maintain your own tap with modified formulae that don't declare openjdk as a dependency. You may need to make further modifications to the formulae to make sure it can find your local JDK if it needs to.

It may not feel like the most convenient solution, but it's there if you really need it.

[ViToni]

@SMillerDev @carlocab Thank you both for your swift response.

@carlocab Thanks for the explanation.
Before asking I read about something like uses_from_macos "swift" and also about .Brewfile so I thought things would be in place for my use case but I wouldn't understand how to use them. Ideally put a uses_from_macos "java" "somewhere" and would be done, I just didn't know where this place would be and how it should look like.
As I started using brew just yesterday I guess there is some misunderstanding on my side. Of creating a tap/formulae it seems a bit too much of a hassle ATM so I'll cope with it.

Thanks for caring

[carlocab]

I don't think you want a uses_from_macos statement here -- that expects very specific things to come after it (e.g. ncurses, zlib, etc), and may give you errors if you give it something it doesn't expect. (In fact, you don't need the uses_from_macos statement. That's only there to help make the formula useable on Linux.)

In case you decide you want to maintain your own formulae, here are some docs to help you get started:

https://docs.brew.sh/How-to-Create-and-Maintain-a-Tap
https://docs.brew.sh/Taps

I'd start with doing brew extract on the formula I want to remove the openjdk dependency from (checkout man brew for its arguments), and then edit the extracted formula by taking out the depends_on "openjdk" statement. From here, you can try installing your new formula to see if it works fine, though it would be a good idea to read the docs for the package you're trying to install so you understand the structure of its dependency on JDK.

It is admittedly a lot of work, but sadly any other setup requires more work for the (already overworked and underthanked) maintainers. Unless you have a very atypical use case, the best idea is probably to just live with having an installed Homebrew openjdk. I'd even consider getting rid of the original JDK install, unless I really needed it.

[ViToni]

As said I just started using brew so there is quite a lot of new wording for me and also new concepts in there.
Being a long time Linux user there are distros which provide something like a noop or minimal version of dependencies (e.g. for SMTP when most users don't need/want a full blown mail server installed).

I also saw that there are packages like openjdk@8 or openjdk@11 which suggests that they are more specific versions which still provide the openjdk capability.
My idea would have been more of an openjdk@noop or jdk@noop. Having to edit each and every tap seems like the wrong way around (especially since I don't know in advance which taps will hit that dependecy) and would make me loose connection to upstream which does not sound good longterm.

Generally speaking the requirement to openjdk is too specfic IMO, so instead of

maven => openjdk
openjdk => openjdk@8 and/or openjdk@11

something like that might solve more use cases:

maven => jdk
jdk => openjdk and/or jdk@os and/or jdk@noop
openjdk => openjdk@8 and/or openjdk@11

But as I seem to be the first one to report something like that I might have hit again some corner case...

[ViToni]

BTW I'm using a JDK from Azul because I'd like to match the runtime I'm using in production so there is a specific need to not interfere with another JDK. Having only one would be the easiest.

[SMillerDev]

If you need a very specific version configuration you're better off using something like Docker where you can just pin the version. What you're asking for has the downside that it's untestable for Homebrew. The reason brew works as well as it does is because it tests all the software it distributes whenever one of its dependencies is changed.

Most software allows setting the JDK location using JAVA_HOME though. So even if you have an OpenJDK from homebrew that doesn't mean you have to use it at runtime. It's just there to make sure that someone who installs it without a JDK can actually use the software.

[carlocab]

The @ refers to upstream versions of openjdk. They're mainly there to support commonly used (typically also Homebrew-packaged) software that depend on them, and not so much to support variety in build configuration (e.g. minimal vs full, etc). There are other reasons, but, at least in my (possibly erroneous!) view, that's the main one.

I don't think you've discovered a previously unreported corner case -- it sounds to me more like you're looking for flexibility that Homebrew sadly does not have the resources to support directly. (Homebrew may be different from some Linux package managers in this regard.)

Have you had a look at other macOS package managers (e.g. MacPorts)? Maybe they'd be more suitable to your needs. (Caveat: it is probably not a good idea to use Homebrew and, say, MacPorts simultaneously.)

[jonchang]

See https://docs.brew.sh/Building-Against-Non-Homebrew-Dependencies for some instructions and a history of why this is the case.