LukeANewton/Tool-Framework-to-Measure-Test-Case-Diversity

Packaged jar is insufficient for production

Closed this issue · 2 comments

CameronRushton commented

The way we package our jar is currently lacking.

  1. Dependencies are not included in our jar file. This means that gson isn't included, so the program won't start. We need to tell maven that we want to create a fat/uber jar using their shadow plugin so that the user only as to download and run the jar. Other packages like JUnit need to be excluded once we create the fat jar, but this is easy.

  2. Our config.json file isn't being included in our jar. Moving this to the resources folder fixes this.

  3. FileReader and FileWriter are not able to access jar files. Our config.json file is in the jar which is a compressed archive. The JVM runs this from the outside and FileReader/Writer are incapable to unpackaging a jar file to read contents. InputStream needs to be used for read and write operations from/to the config file instead. This will only impact the FileWriterService and FileReaderService used by the Controller and not testing because we can assume that tests are only ran in a development environment with an uncompressed file structure.

CameronRushton commented

Our jar before including the gson dependency is ~40 KB and after is ~260 KB. Beefy in comparison, but we're talking in KB here. I attempted to replace our config.json with a config.properties and use the built in java api, but it's not good at all. It doesn't support lists, complex objects, and the api isn't as clean.
We made the right decision here.

CameronRushton commented

After lots of research and testing, I've determined that it's impossible to write configuration files (or any file) to the jar, especially after it has been opened and is currently in use. This SO post was the final nail in the coffin.

Option 1

  1. Keep the current config file in the jar where it can be initially read.
  2. On app start, determine if there is already a config file at location
    Windows: AppData/local/
    Mac: preferences/ (NOTE: Apple wants people to use their api for this)
    Linux: (educated guess here) opt/ (Wouldnt use tmp/ because technically this isn't temporary)
  3. If there is a config file under out app's name, then use that, otherwise, make one.

Option 2

Use the built in preferences api. I don't like it, but I think we have to do it this way.

  1. Build our preferences file using their api on app start. We could do this in main(). Now that I think about it, I'm 80% sure this is how it's done at Solace... The api will automatically figure out where everything will go.
  2. Read and write key/value pairs using the api.

This will also remove gson as a dependency.

Let me know what you guys think. What should we do? I can work on this. @LukeANewton @EricRBedard