I just upgraded to v0.32.5 and noticed two issues that are minor, but that I’d like to suggest be mentioned in the docs.
I am running the .jar version, on linux; I rename the jars to indicate their version and then have a symbolic link named simply “metabase.jar” that points to the version I wish to be running. For some inane reason, when I renamed the jars, I got in the habit of NOT ending the filename with “.jar” after the version number. This worked fine in previous versions. However, in 0.32.5 it generated fatal errors of type “FileNotFoundException”… the file reported unfound was the jar itself (the physical name, not the link name). Simply renaming the JARs by appending “.jar” to the physical filename (and updating the link) solved the problem.
In other words, beginning with 0.32 the jar filename must end with .jar. That is definitely not a bug, but because it was not true before I’d like to see it mentioned/footnoted in the docs.
Secondly, it didn’t use to matter what the default directory was when starting the jar. Now it does in that the working directory will have the plugins folder created in it. Since I previously had a startup script in my path, I started it from any arbitrary location; the new version litters my drive with plugin directories. This is, IMO, also worth mentioning in the install notes.
Thanks for listening, and for such a great product!
Hi @tengammaps
Didn’t know about the error with the missing .jar - good to know. And yes, it should probably be a note in the JAR setup docs.
About the plugins directory, have you seen the section under the Vertica driver? So you want something similar under the JAR section (maybe Docker too)?
Thanks for the response @flamber. Regarding the plugins dir, I wasn’t necessarily asking for a change, but perhaps again to document the behavior.
But, upon reading the Vertica docs you referenced, I realize that the behavior I saw was not as documented in the sentence, “By default, the plugins directory is called plugins, and lives in the same directory as the Metabase JAR.”
The behavior I saw was that the plugins directory was always created in the current working directory, not necessarily (or in my case usually) the JAR directory. In other words, with the jar in “/opt/metabase/metabase.jar”, running the “java -jar /opt/metabase/metbase.jar” command from my home directory created the plugins dir in my home directory, not in “/opt/metabase/”. So this looks like it may be a legitimate bug (i.e., unintended behavior) after all.
It occurs to me this could also be fallback behavior due to insufficient rights to create the plugins dir in /opt/metabase. However it doesn’t agree with the stated behavior; if the dir can’t be created, I’d expect an error (hopefully a useful one 
) rather than a change in behavior… but if the behavior really is a fallback, that should be documented.
I hope that makes more sense!
I’m totally with you about documentation could be better to describe MB_PLUGINS_DIR - not just the missing section from JAR-setup, but maybe a general re-write too.
There’s currently only a single bug open about anything that seems related to this:
https://github.com/metabase/metabase/issues/9691
Someone else also had some problems, then they upgraded, so it’s probably duo to lack of documentation:
https://github.com/metabase/metabase/issues/9654
) rather than a change in behavior… but if the behavior really is a fallback, that should be documented.