.env file copy to target in dev mode

[lordofthejars]

Description

When you are at dev mode and you have a file at the root of the project a .env file, the file is not loaded as the root directory at runtime is at target/.

A possible workaround is to use:

<build>
<resources>  
   <resource>
       <directory>${project.basedir}</directory><!-- from -->
       <targetPath>${project.build.directory}</targetPath><!-- to -->
       <includes><!-- what -->
          <include>**/.env</include>
       </includes>
    </resource> 
</resources>
</build>

But we could integrate this on dev mode so if there is a .env the file then we copy directly to target (I don't know if this is possible).

I know that the purpose of a .env is to reside outside of the project (JAR/native package) but I am thinking in the next use case:

I am demoing in front of a big audience, I have my .env file with my credentials to publish a docker image to quai. Then I can just say look I copy this file into root project as it has my credentials and of course, you cannot see them, and then I run mvn .... and the image is published.

I could copy directly to target/ directory it is true, but if I do a clean then I will miss everything.

So it will be great at the plugin level to do this copy instead of having to configure pom.xml with the resources and explain to the audience why I am doing this.

[geoand]

Question: Why not have the .env file in src/main/resources? Then it would be picked up automatically, no?

[lordofthejars]

I think these files are not copied in target dir but inside an special dir which is added to classpath. El mar., 3 mar. 2020 9:02, Georgios Andrianakis <notifications@github.com> escribió:

…

Question: Why not have the .env file in src/main/resources? Then it would be picked up automatically, no? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#7519?email_source=notifications&email_token=AALSMYP4JHOZF2PZY5M5KQDRFS2QDA5CNFSM4K74A5A2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENSPGNA#issuecomment-593818420>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AALSMYKPGVTAPRRWPXPNZILRFS2QDANCNFSM4K74A5AQ> .

[geoand]

Anything in src/main/resources should automatically be added to target without the user having to do anything.

So mvn compile quarkus:dev would automatically update the target directory with the latest "source" version of src/main/resources/.env

[lordofthejars]

No, it seems it is not in this way, I have tried now, I copied .env to src/main/resources and the file is placed at target/classes so it can be picked up as classpath resource.

[geoand]

So all good?

[lordofthejars]

Nope. The .env should be at target/ because of the .env file is loaded by using Paths.get(System.getProperty("user.dir", "."), ".env")

[geoand]

Oh yes, sorry, I see what you are saying

[lordofthejars]

Humm it is really strange, I am not sure if there is a bug or not. Look I share with you the project in case you see something different:

https://github.com/lordofthejars/quarkusenv

I have debugged and in the ConfigUtils DotEnvConfig

quarkus/core/runtime/src/main/java/io/quarkus/runtime/configuration/ConfigUtils.java

Line 158 in cf539e6

DotEnvConfigSource(Path path) {

thing I see the value correctly inserted in the map, but when the app is started I see:

javax.enterprise.inject.spi.DeploymentException: No config value of type [java.lang.String] exists for: greeting.message
	at io.quarkus.arc.runtime.ConfigRecorder.validateConfigProperties(ConfigRecorder.java:37)
	at io.quarkus.deployment.steps.ConfigBuildStep$validateConfigProperties24.deploy_0(ConfigBuildStep$validateConfigProperties24.zig:120)
	at io.quarkus.deployment.steps.ConfigBuildStep$validateConfigProperties24.deploy(ConfigBuildStep$validateConfigProperties24.zig:36)

So it seems that the value does not end up injected correctly.

[geoand]

The config issue should be solved by #7530

[geoand]

@dmlloyd @sherl0cks since you were the ones that had the initial conversation around .dotenv, what do you think about this one?
I personally think it makes sense

[dmlloyd]

Since we're looking in user.dir for .env, I think it makes sense to make an extra effort to copy it for dev mode operation.