在哪里定义服务器端jar的类路径？ manifest.mf与CLI参数-cp

Question

Realized a similar question was posted earlier but had no answers. Uuse both a manifest.mf and also pass jars using cp?

1. What is the best way to define classpath in java batch environment? Can both Manifest.MF and cp argument via Command line be used or Do one override the other or Do one takes precedence over the other?

2. If I am using JavaEE-API jar instead of the actual JMS* and XML* jars which are available on the server. Do I need to include each individual jar in the build.gradle as "runtime" ? for traceability on the actual dependencies? What would be the best practice?

3. Taking Continuous integration into account, should the server side dependency jars be packaged along with the application jar, so that its a standalone app ?!

Thank you,

Answer 1

What is the best way to define classpath in java batch environment ? Can both Manifest.MF and cp argument via Command line be used or Does one override the other or Does one takes precedence over the other ?

Nowadays, it's common to create an uber jarfile, one that includes all of its dependencies together, and then to create an executable jar , which leverages the manifest file.

To be clear, if you use the -cp command line option, you still need to specify the class to call containing your application entry point, ie the class containing public static void main(String[] args) .

If I am using javaee-api jar instead of the actual jms* and xml* jars which are available on the server. Do I need to include each individual jar in the build.gradle as "runtime" ? for tracebility on the actual dependencies ? What would be the best practice ?

The better scope to use here is provided , since these libraries will be provided for you by the container.

Taking Continuous integration into account, should the server side dependency jars be packaged along with the application jar, so that its a standalone app ?!

This is a very common practice now, and it simplifies deployment because all dependencies are bundled together. This is the approach that the Dropwizard web service framework has taken, using Jetty as an embedded container.