diff --git a/compositor.json b/compositor.json index ccbacbc..756e426 100644 --- a/compositor.json +++ b/compositor.json @@ -66,7 +66,7 @@ "metadata": { "source": "github.readme" }, - "html": "\n

\n

A Java port of the Ruby dotenv project (which loads environment variables from a .env file). java-dotenv also offers a Kotlin DSL.

\n

\n \n

\n\n

From the original Library:

\n
\n

Storing 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.

\n

But 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
\n

Environment variables listed in the host environment override those in .env.

\n

Use dotenv.get("...") instead of Java's System.getenv(...).

\n

Install

\n

Maven

\n
<dependency>\n    <groupId>io.github.cdimascio</groupId>\n    <artifactId>java-dotenv</artifactId>\n    <version>3.1.2</version>\n</dependency>

Gradle

\n
compile 'io.github.cdimascio:java-dotenv:3.1.2'

Usage

\n

Use dotenv.get("...") instead of Java's System.getenv(...). Here's why.

\n

Create a .env file in the root of your project

\n
# formatted as key=value\nMY_ENV_VAR1=some_value\nMY_EVV_VAR2=some_value

With Java

\n
import io.github.cdimascio.dotenv.Dotenv;\n\nDotenv dotenv = Dotenv.load();\ndotenv.get("MY_ENV_VAR1")

or with Kotlin

\n
import io.github.cdimascio.dotenv.dotenv\n\nval dotenv = dotenv()\ndotenv["MY_ENV_VAR1"]

Android Usage

\n\n

Note: The above configuration is required because dot files in /assets do not appear to resolve on Android. (Seeking recommendations from the Android community on how java-dotenv configuration should work in order to provide the best experience for Android developers)

\n

Alternatively, if you are using Provider android.resource you may specify

\n
 directory = "android.resource://com.example.dimascio.myapp/raw"

Advanced Usage

\n

Configure

\n

Configure java-dotenv once in your application.

\n

With Java

\n
Dotenv dotenv = Dotenv.configure()\n        .directory("./some/path")\n        .ignoreIfMalformed()\n        .ignoreIfMissing()\n        .load();
\n

or with Kotlin

\n
val dotenv = dotenv {\n    directory = "./some/path"\n    ignoreIfMalformed = true\n    ignoreIfMissing = true\n}
\n

Get environment variables

\n

Note, environment variables specified in the host environment take precedence over those in .env.

\n

With Java

\n
dotenv.get("MY_ENV_VAR1");\ndotenv.get("HOME");

or with Kotlin

\n
dotenv["MY_ENV_VAR1"]\ndotenv["HOME"]

Configuration options

\n

optional directory

\n\n

optional filename

\n\n

optional ignoreIfMalformed

\n\n

optional ignoreIfMissing

\n\n

Examples

\n\n

FAQ

\n

Q: Why should I use dotenv.get("MY_ENV_VAR") instead of System.getenv("MY_ENV_VAR")

\n

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(...).

\n

Q: Should I have multiple .env files?

\n

A: No. We strongly recommend against having a "main" .env file and an "environment" .env file like .env.test. Your config should vary between deploys, and you should not be sharing values between environments.

\n
\n

In a twelve-factor app, env vars are granular controls, each fully orthogonal to other env vars. They are never grouped together as “environments”, but instead are independently managed for each deploy. This is a model that scales up smoothly as the app naturally expands into more deploys over its lifetime.

\n

– The Twelve-Factor App

\n
\n

Q: Should I commit my .env file?

\n

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.

\n

Q: What happens to environment variables that were already set?

\n

A: 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.

\n

Q: What about variable expansion in .env?

\n

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.

\n

Note 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.

\n

Contributors

\n

Contributions are welcome!

\n

see CONTRIBUTING.md

\n

License

\n

see LICENSE (Apache 2.0)

\n" + "html": "\n

\n

A Java port of the Ruby dotenv project (which loads environment variables from a .env file). java-dotenv also offers a Kotlin DSL.

\n

\n \n

\n\n

From the original Library:

\n
\n

Storing 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.

\n

But 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
\n

Environment variables listed in the host environment override those in .env.

\n

Use dotenv.get("...") instead of Java's System.getenv(...).

\n

Install

\n

Maven

\n
<dependency>\n    <groupId>io.github.cdimascio</groupId>\n    <artifactId>java-dotenv</artifactId>\n    <version>3.1.3</version>\n</dependency>

Gradle

\n
compile 'io.github.cdimascio:java-dotenv:3.1.3'

Usage

\n

Use dotenv.get("...") instead of Java's System.getenv(...). Here's why.

\n

Create a .env file in the root of your project

\n
# formatted as key=value\nMY_ENV_VAR1=some_value\nMY_EVV_VAR2=some_value

With Java

\n
import io.github.cdimascio.dotenv.Dotenv;\n\nDotenv dotenv = Dotenv.load();\ndotenv.get("MY_ENV_VAR1")

or with Kotlin

\n
import io.github.cdimascio.dotenv.dotenv\n\nval dotenv = dotenv()\ndotenv["MY_ENV_VAR1"]

Android Usage

\n\n

Note: The above configuration is required because dot files in /assets do not appear to resolve on Android. (Seeking recommendations from the Android community on how java-dotenv configuration should work in order to provide the best experience for Android developers)

\n

Alternatively, if you are using Provider android.resource you may specify

\n
 directory = "android.resource://com.example.dimascio.myapp/raw"

Advanced Usage

\n

Configure

\n

Configure java-dotenv once in your application.

\n

With Java

\n
Dotenv dotenv = Dotenv.configure()\n        .directory("./some/path")\n        .ignoreIfMalformed()\n        .ignoreIfMissing()\n        .load();
\n

or with Kotlin

\n
val dotenv = dotenv {\n    directory = "./some/path"\n    ignoreIfMalformed = true\n    ignoreIfMissing = true\n}
\n

Get environment variables

\n

Note, environment variables specified in the host environment take precedence over those in .env.

\n

With Java

\n
dotenv.get("MY_ENV_VAR1");\ndotenv.get("HOME");

or with Kotlin

\n
dotenv["MY_ENV_VAR1"]\ndotenv["HOME"]

Configuration options

\n

optional directory

\n\n

optional filename

\n\n

optional ignoreIfMalformed

\n\n

optional ignoreIfMissing

\n\n

Examples

\n\n

FAQ

\n

Q: Why should I use dotenv.get("MY_ENV_VAR") instead of System.getenv("MY_ENV_VAR")

\n

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(...).

\n

Q: Should I have multiple .env files?

\n

A: No. We strongly recommend against having a "main" .env file and an "environment" .env file like .env.test. Your config should vary between deploys, and you should not be sharing values between environments.

\n
\n

In a twelve-factor app, env vars are granular controls, each fully orthogonal to other env vars. They are never grouped together as “environments”, but instead are independently managed for each deploy. This is a model that scales up smoothly as the app naturally expands into more deploys over its lifetime.

\n

– The Twelve-Factor App

\n
\n

Q: Should I commit my .env file?

\n

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.

\n

Q: What happens to environment variables that were already set?

\n

A: 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.

\n

Q: What about variable expansion in .env?

\n

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.

\n

Note 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.

\n

Contributors

\n

Contributions are welcome!

\n

see CONTRIBUTING.md

\n

License

\n

see LICENSE (Apache 2.0)

\n" }, { "component": "footer",