Hello all, I’m fairly new to gradle but have spent nearly two straight days looking for a solution but have come up empty handed. For more background and a more detailed write-up please feel free to take a look at my stackoverflow post.
Ultimately I have a large directory that I want to include as a resource, and is needed for executing in both build/test with gradle and also when being used by end-user in the distributed archive (application plugin). The stackoverflow posts describes why this can’t be bundled up into the JAR as a resource.
I understand the usage of src/dist, but what I can not figure out is what additional I need to do so that the code in my java project can stay unchanged and work with those resources in all instances.
Using new File("some/path/to/orekit-data") is a very bad idea either way.
Actually using new File(...) and similar APIs with a relative path is almost always a bad idea.
The typically only case where this is appropriate is, if you either definitely know you control the working directory, or if you process a path given by the user on the command line.
Because such APIs search the relative file path relative to the current working directory, not relative to the start script location.
So while you are testing and executing the script from some defined location, like where it is for example, it might then work, but if a user then invokes the start script while being in a different directory, it blows up and cannot find your file.
What I typically do in similar situations is to enhance the start script, so that APP_HOME is given as argument or system property to the executable and use that value to access the files using an absolute path. In the same way you can then configure the run task with the absolute path to the src/main/dist directory.
@Vampire (Björ), I appreciate the suggestion and agree that I want to have the most “secure” strategy in that sense that it minimizes the likelihood of it breaking. When I break it down the simplest requirements I want it to work in two cases:
The application is being executed/built/tested from gradle
The application is being execute by and end-user through the sh/bat files created in an archive files (produced through distribution plugin)
I know that just using the resources folder might make the most sense from a stability perspective, but my concern is execution speed from accessing the data files inside of a compressed archive (refer to the post in orekit-forums about the overhead)
I see two options:
Just use the resources folder and deal with the overhead for initial development
Try using the APP_HOME method you mentioned @Vampire. (may need a little bit more insight here)
Also here is an example repo I created where im trying out these options.
Actually you have a third option.
You can package it as resource in the jar, but then unpack it on first start to only have the overhead once.
But then you again have to decide where to unpack it, e. g. on LOCALAPPDATA on Windows and so on.
But it might actually be easier to go with the option I suggested, to just give the location of the files as start parameter or system property or similar.
@Vampire if I were to go the option-1 route I guess here is my question (first I need to do some quick digging into APP_DATA but would I essentially need to configure gradle (application and distribution plugin to look at src/dist for any gradle-related build and test operations and then add the correct updates to the .sh/.bat scripts produced by the distTar/distZip/distInstall commands such that it knows to look for the same resources but in the updated directories?
Is there an option to do it by just updating the CLASSPATH ?
I don’t think there is much of a difference.
Either way you have to update the same tasks configurations iiuc.
So you would probably need to configure the test task, the run task, and the start scripts.