diff --git a/compositor.json b/compositor.json index 7723fad..e631044 100644 --- a/compositor.json +++ b/compositor.json @@ -66,7 +66,7 @@ "metadata": { "source": "github.readme" }, - "html": "\n
\n
\n
A zero-dependency Java port of the Ruby dotenv project (which loads environment variables from a .env
file). java-dotenv also offers a Kotlin DSL.
From the original Library:
\n\n\nStoring configuration in the environment is one of the tenets of a twelve-factor app. Anything that is likely to change between deployment environments–such as resource handles for databases or credentials for external services–should be extracted from the code into environment variables.
\nBut it is not always practical to set environment variables on development machines or continuous integration servers where multiple projects are run. Dotenv load variables from a .env file into ENV when the environment is bootstrapped.
\n
Environment variables listed in the host environment override those in .env
.
Use dotenv.get("...")
instead of Java's System.getenv(...)
.
<dependency>\n <groupId>io.github.cdimascio</groupId>\n <artifactId>java-dotenv</artifactId>\n <version>3.0.1</version>\n</dependency>
compile 'io.github.cdimascio:java-dotenv:3.0.1'
Use dotenv.get("...") instead of Java's System.getenv(...). Here's why.
\nCreate a .env
file in the root of your project
# formatted as key=value\nMY_ENV_VAR1=some_value\nMY_EVV_VAR2=some_value
With Java
\nimport io.github.cdimascio.dotenv.Dotenv;\n\nDotenv dotenv = Dotenv.load();\ndotenv.get("MY_ENV_VAR1")
or with Kotlin
\nimport io.github.cdimascio.dotenv.dotenv\n\nval dotenv = dotenv()\ndotenv["MY_ENV_VAR1"]
Configure java-dotenv
once in your application.
With Java
\nDotenv dotenv = Dotenv.configure()\n .directory("./some/path")\n .ignoreIfMalformed()\n .ignoreIfMissing()\n .load();
or with Kotlin
\nval dotenv = dotenv {\n directory = "./some/path"\n ignoreIfMalformed = true\n ignoreIfMissing = true\n}
Note, environment variables specified in the host environment take precedence over those in .env
.
With Java
\ndotenv.get("MY_ENV_VAR1");\ndotenv.get("HOME");
or with Kotlin
\ndotenv["MY_ENV_VAR1"]\ndotenv["HOME"]
directory
path
specifies the directory containing .env
. Dotenv first searches for .env
using the given path on the filesystem. If not found, it searches the given path on the classpath. If directory
is not specified it defaults to searching the current working directory on the filesystem. If not found, it searches the current directory on the classpath.
Java example
\n Dotenv\n .configure()\n .directory("/some/path")\n .load()
Kotlin Dsl example
\n dotenv {\n directory = "/some/path"\n }
ignoreIfMalformed
Do not throw when .env
entries are malformed. Malformed entries are skipped.
Java example
\nDotenv\n .configure()\n .ignoreIfMalformed()\n .load()
Kotlin Dsl example
\n dotenv {\n ignoreIfMalformed = true\n }
ignoreIfMissing
Do not throw when .env
does not exist. Dotenv will continue to retrieve environment variables that are set in the environment e.g. dotenv["HOME"]
Java example
\nDotenv\n .configure()\n .ignoreIfMissing()\n .load()
Kotlin Dsl example
\n dotenv {\n ignoreIfMissing = true\n }
Q: Why should I use dotenv.get("MY_ENV_VAR")
instead of System.getenv("MY_ENV_VAR")
A: Since Java does not provide a way to set environment variables on a currently running process, vars listed in .env
cannot be set and thus cannot be retrieved using System.getenv(...)
.
Q: Should I commit my .env
file?
A: No. We strongly recommend against committing your .env
file to version control. It should only include environment-specific values such as database passwords or API keys. Your production database should have a different password than your development database.
Q: What happens to environment variables that were already set?
\nA: java-dotenv will never modify any environment variables that have already been set. In particular, if there is a variable in your .env
file which collides with one that already exists in your environment, then that variable will be skipped. This behavior allows you to override all .env
configurations with a machine-specific environment, although it is not recommended.
Q: What about variable expansion in .env
?
A: We haven't been presented with a compelling use case for expanding variables and believe it leads to env vars that are not "fully orthogonal" as The Twelve-Factor App outlines. Please open an issue if you have a compelling use case.
\nNote and reference: The FAQs present on motdotla's dotenv node project page are so well done that I've included those that are relevant in the FAQs above.
\nContributions are welcome!
\nsee CONTRIBUTING.md
\nApache 2.0 - see LICENSE
\n" + "html": "\n\n
\n
A zero-dependency Java port of the Ruby dotenv project (which loads environment variables from a .env
file). java-dotenv also offers a Kotlin DSL.
From the original Library:
\n\n\nStoring configuration in the environment is one of the tenets of a twelve-factor app. Anything that is likely to change between deployment environments–such as resource handles for databases or credentials for external services–should be extracted from the code into environment variables.
\nBut it is not always practical to set environment variables on development machines or continuous integration servers where multiple projects are run. Dotenv load variables from a .env file into ENV when the environment is bootstrapped.
\n
Environment variables listed in the host environment override those in .env
.
Use dotenv.get("...")
instead of Java's System.getenv(...)
.
<dependency>\n <groupId>io.github.cdimascio</groupId>\n <artifactId>java-dotenv</artifactId>\n <version>3.0.1</version>\n</dependency>
compile 'io.github.cdimascio:java-dotenv:3.0.1'
Use dotenv.get("...") instead of Java's System.getenv(...). Here's why.
\nCreate a .env
file in the root of your project
# formatted as key=value\nMY_ENV_VAR1=some_value\nMY_EVV_VAR2=some_value
With Java
\nimport io.github.cdimascio.dotenv.Dotenv;\n\nDotenv dotenv = Dotenv.load();\ndotenv.get("MY_ENV_VAR1")
or with Kotlin
\nimport io.github.cdimascio.dotenv.dotenv\n\nval dotenv = dotenv()\ndotenv["MY_ENV_VAR1"]
Configure java-dotenv
once in your application.
With Java
\nDotenv dotenv = Dotenv.configure()\n .directory("./some/path")\n .ignoreIfMalformed()\n .ignoreIfMissing()\n .load();
or with Kotlin
\nval dotenv = dotenv {\n directory = "./some/path"\n ignoreIfMalformed = true\n ignoreIfMissing = true\n}
Note, environment variables specified in the host environment take precedence over those in .env
.
With Java
\ndotenv.get("MY_ENV_VAR1");\ndotenv.get("HOME");
or with Kotlin
\ndotenv["MY_ENV_VAR1"]\ndotenv["HOME"]
directory
path
specifies the directory containing .env
. Dotenv first searches for .env
using the given path on the filesystem. If not found, it searches the given path on the classpath. If directory
is not specified it defaults to searching the current working directory on the filesystem. If not found, it searches the current directory on the classpath.
Java example
\n Dotenv\n .configure()\n .directory("/some/path")\n .load()
Kotlin Dsl example
\n dotenv {\n directory = "/some/path"\n }
ignoreIfMalformed
Do not throw when .env
entries are malformed. Malformed entries are skipped.
Java example
\nDotenv\n .configure()\n .ignoreIfMalformed()\n .load()
Kotlin Dsl example
\n dotenv {\n ignoreIfMalformed = true\n }
ignoreIfMissing
Do not throw when .env
does not exist. Dotenv will continue to retrieve environment variables that are set in the environment e.g. dotenv["HOME"]
Java example
\nDotenv\n .configure()\n .ignoreIfMissing()\n .load()
Kotlin Dsl example
\n dotenv {\n ignoreIfMissing = true\n }
Q: Why should I use dotenv.get("MY_ENV_VAR")
instead of System.getenv("MY_ENV_VAR")
A: Since Java does not provide a way to set environment variables on a currently running process, vars listed in .env
cannot be set and thus cannot be retrieved using System.getenv(...)
.
Q: Should I commit my .env
file?
A: No. We strongly recommend against committing your .env
file to version control. It should only include environment-specific values such as database passwords or API keys. Your production database should have a different password than your development database.
Q: What happens to environment variables that were already set?
\nA: java-dotenv will never modify any environment variables that have already been set. In particular, if there is a variable in your .env
file which collides with one that already exists in your environment, then that variable will be skipped. This behavior allows you to override all .env
configurations with a machine-specific environment, although it is not recommended.
Q: What about variable expansion in .env
?
A: We haven't been presented with a compelling use case for expanding variables and believe it leads to env vars that are not "fully orthogonal" as The Twelve-Factor App outlines. Please open an issue if you have a compelling use case.
\nNote and reference: The FAQs present on motdotla's dotenv node project page are so well done that I've included those that are relevant in the FAQs above.
\nContributions are welcome!
\nsee CONTRIBUTING.md
\nApache 2.0 \nsee LICENSE
\n" }, { "component": "footer",