As a developer and sysadmin, I would enjoy the benefits of using Java MicroProfile based deployments with an application server like Payara Micro or Thorntail.

[poikilotherm]

• This has been inspired from a discussion on IRC.
• This is related to Glassfish 5 Upgrade #4248, installing Dataverse under Payara 5 #4172, Docker for production #4665 and Running integration tests for more than just API #5068

In these days of 2018, things start to change while developing and deploying web applications:

1. It has become common to use Docker in development environment and continious integration scenarios.
2. With Kubernetes and other tools, the usage of container based application deployment is emerging.
3. (Many) people like stuff like systemd these days (and similiar tools) and they enjoy the handling of services based on Java technology with them, even if they do not like or use containers.
4. Integration testing becomes a demanding task the larger an application grows, thus there is room for automation and getting devs life easier as much as possible (especially for onboarders).

Reasons this user story came up:

1. Currently, the setup and maintenance of a Dataverse installation needs a handcrafted Glassfish 4.1.1 deployment and a rather complex setup. Deploying, undeploying, etc is rather clumbsy. If things fail, there are good chances that you need to start all over. It would be a huge benefit if these steps are a bit more comfortable to use.
2. Starting an instance for demo or testing of the application needs either a bigger Docker container environment like the docker-aio approach or spinning up EC2 machines. For many cases, this just might be to much, when a local database and Solr (maybe usable via docker-compose as "hire and fire") are just fine. Starting the hole application with a simple CLI invocation, logs on stdout gives devs more control and maybe a speedup.
3. Running integration tests for different and growing modules of a software get a lot easier when you can test them in isolation. Small chunks with all necessary code, automatically deployed and runnable make this a breathe. Running regular CI checks for integration tests is easier.
4. Developers like to run the application locally from within their IDE and from CLI.
5. People that are "into containers" often prefer applications, they can entirely spin up via simple CLI invocation, that do not send themself to the background, log on stdout, etc. Currently, this is not possible.
6. Nearly the same as (4) applies to people using systemd. Spinning up the united team of application server AND application makes people happy that write unit files
7. Many others I can't think of right now...

As a result, I would really like to see Dataverse usable with the Java MicroProfile approach.

This acts together with the (necessary?) upgrade to a modern application server like Glassfish/Payara 5 (#4248, #4172). (Sorry guys, but adding patched JARs to a installation shouldn't be necessary in 2018...) And for testing as suggested in #5068 but also for other approaches and issues, this makes things a lot easier...

Things to keep in mind:

• Not everyone likes to have containers. Keep the good old sysadmin job possible.
• Don't make it bloated. Nobody likes to download a 1GiB release archive.
• Make container guys happy: don't bloat their images, make it fast to build and send to a registry. This also helps with CI.
• Don't force people to give up their ways. A traditional deployment with a standalone app server should be totally possible.

Things to argue about and read:

• https://www.pavel.cool/javaee/java-ee-fatjars-docker
• The configuration mechanisms for the application servers are pretty neat with Microprofile. Maybe there is a way in between, without creating a UberJAR, but not giving up on the single command approach?

[poikilotherm]

When using a different Java EE profile than "Full", like "Micro[service]" or "Web", you should be aware what parts of Java EE you use. [1]

First approach:

$ grep -r "import javax" ./src | cut -f2 -d: | cut -f1,2 -d. | cut -f2 -d" " | sort | uniq -c
      1 javax.activation
     22 javax.annotation
     47 javax.batch
      9 javax.crypto
    338 javax.ejb
      9 javax.enterprise
    212 javax.faces
      7 javax.imageio
    193 javax.inject
     11 javax.jms
    359 javax.json
     20 javax.mail
      9 javax.naming
   1048 javax.persistence
    107 javax.servlet
     79 javax.validation
    308 javax.ws
     93 javax.xml

[poikilotherm]

Closing in favor of #5292 .