Develop Reference

Create JAR file using Net Beans including all dependent libs and folders

I have created a JavaFX application using NetBeans IDE and below is my folder structure.
I want to a build a single jar file including all dependencies for this jar to work properly.
This jar requires testplanner and batch folder from project root directory and files inside dist folder to work properly.
How can I package all this to a single jar file?

Theoretically JAR files cannot contain dependencies within, as java does not support it out of the box. WAR and EAR archives can. What You want to do is not standard, but is named fat jar. Fat jars are used i.e. by spring-boot maven plugin, but you could try this:
https://dzone.com/articles/how-build-fat-jar-using
And some more explanation:
NetBeans - deploying all in one jar

Use tecreations Deploy. Put all your sources into a path declared as Tecreations.getProjectPath(), run BuildAll to create your corresponding classes, put your jars in projectpath/jars and select the appropriate settings, whether to include jars, sources or classes. Select your main class and click Deploy. Unsigned and signed output jars are produced in user/Documents.
Download: https://tecreations.ca/java/downloads/release.

Is it correct or incorrect for a Java JAR to contain its own dependencies?

I guess this is a two-part question. I am trying to write my own Ant task (MyFirstTask) that can be used in other project's build.xml buildfiles. To do this, I need to compile and package my Ant task inside its own JAR. Because this Ant task that I have written is fairly complicated, it has about 20 dependencies (other JAR files), such as using XStream for OX-mapping, Guice for DI, etc.
I am currently writing the package task in the build.xml file inside the MyFirstTask project (the buildfile that will package myfirsttask.jar, which is the reusable Ant task).
I am suddenly realizing that I don't fully understand the intention of a Java JAR. Is it that a JAR should not contain dependencies, and leave it to the runtime configuration (the app container, the runtime environment, etc.) to supply it with the dependencies it needs? I would assume if this is the case, an executable JAR is an exception to the rule, yes?
Or, is it the intention for Java JARs to also include their dependencies?
Either way, I don't want to be forcing my users to be copying-n-pasting 25+ JARs into their Ant libs; that's just cruel. I like the way WAR files are set up, where the classpath for dependencies is defined under the classes/ directory.
I guess, ultimately, I'd like my JAR structure to look like:
myfirsttask.jar/
com/ --> the root package of my compiled binaries
config/ --> config files, XML, XSD, etc.
classes/ --> all dependencies, guice-3.0.jar, xstream-1.4.3.jar, etc.
META-INF/
MANIFEST.MF
I assume that in order to accomplish this (and get the runtime classpath to also look into the classes/ directory), I'll need to modify the MANIFEST.MF somehow (I know there's a manifest attribute called ClassPath, I believe?). I'm just having a tough time putting everything together, and have a looming/lingering question about the very intent of JARs to begin with.
Can someone please confirm whether Oracle intends for JARs to contain their dependencies or not? And, either way, what I would have to do in the manifest (or anywhere else) to make sure that, at runtime, the classpath can find the dependencies stored under the classes/ directory? Thanks in advance!

The term 'JAR file' can mean at least two things, or rather, has at least two facets to its meaning. Most basically, it means a container format: basically, a ZIP file with a META-INF directory. More refinedly, it means this container used as a way to package class files.
In the sense of being a container, there is no intent with respect to contents; the file could contain class files, other JARs (in either sense!), etc. But in the sense of being a packaging of code, i believe the intent for JAR files proper is for them not to contain any dependencies.
If you have a read of the JAR File Specification, you'll find there are several allusions to the storage of class files, but nothing about storing other JAR files. Correspondingly, if you look at the implementation of the JAR file classloader in the JRE, it can't do anything useful with nested JARs.
Furthermore, the JAR specification does detail a mechanism for dealing with non-nested dependencies: the Class-Path attribute. This lets a JAR file make relative references to other JAR files in the filesystem.
Now, in-the-sense-of-a-packaging JAR files are not the only use of in-the-sense-of-a-container JAR files. WAR, EAR, and RAR files (and more besides) are all JAR files used for particular purposes. Each of those is capable of containing other JARs: WARs can contain in-the-sense-of-a-packaging JAR files, and EARs can contain those and also WARs. However, those are quite different beasts than in-the-sense-of-a-packaging JAR files. It's worth noting that special classloaders, that are not in the Java standard library, are needed to make use of them.
The way that WARs etc can collect many JAR files together is indeed very useful, and it's a real shame there's no generic mechanism for doing this in Java outside of Java EE. It would be great to have an 'application archive' or 'meta-archive' format that simply bundled some JARs.
So, you're left with this problem of users needing 25 JARs in order to use your plugin. You have roughly two options.
First, you accept the pain, and distribute your plugin as a zip full of JARs, which users will have to unpack.
Secondly, you join the 21st century, and use a build tool and distribution mechanism which handles dependencies automatically: in practice, that means using Gradle, or Maven, or some other tool (such as Ant) in concert with Ivy, to obtain dependencies from Maven Central, and then then releasing your code along with a POM file which lists those dependencies. Users can then download your JAR and your POM, and have their own build tool obtain the dependencies.
If you do go the second route, it might be prudent to also release a zip of the dependencies, for the benefit of users who are not using automatic dependency management.

The intent (AFAIU) is for JAR files to behave like native code shared object files (.so on Unix, .dll on Windows). Generally, an application will install several shared object files as siblings, plus an executable with which to launch them.
An executable JAR is more like a standalone executable, and so it is more common to include all dependencies (similar to the way a statically-linked native code executable contains all its dependent objects directly).
Unfortunately, the default ClassLoader is not able to load classes from nested JARs. It is possible to write a ClassLoader that does. Or you can use one someone else has written. From the description of your problem, it sounds like Jar Jar Links is exactly what you're looking for.

Is it correct or incorrect for a Java JAR to contain its own dependencies?
There are use cases where it is correct for a JAR file to contain its own
dependencies. If you would like to support users who do not use modern
dependency management, you may want to provide a JAR file containing your Ant
task code as well as all dependencies. The more powerful, flexible, and modular
approach is to publish versioned JAR files to the Maven repository that
only contain your project code.
1) JAR file containing your project code and all dependencies
Pros
Easy to download and the only setup for end users is including a
<taskdef> in their Ant build files
No setup required to publish Maven artificats
Example Ant target to build JAR
<target name="jar" depends="compile"
description="Creates a standalone JAR of all class files and dependencies.">
<jar destfile="${my.ant.task.jar.file}" update="true">
<fileset dir="${build.classes.dir}" />
<zipfileset src="${lib.dir}/javax.inject.jar" />
<zipfileset src="${lib.dir}/guice-3.0.jar" />
<zipfileset src="${lib.dir}/guice-multibindings-3.0.jar" />
<zipfileset src="${lib.dir}/guice-assistedinject-3.0.jar" />
</jar>
</target>
Cons
If end users of your Ant task already have some or all of the dependencies
included in their projects, then they will end up with redundant copies of the
dependencies
The JAR file could be very large
2) JAR file containing only your project code published to Maven Repository
Pros
Users may fetch any version of your Ant task that you have published to
the Maven repository, which provides more flexibility in releasing new
versions of your task while allowing existing users to continue using previous
versions to avoid possible regressions
Avoids duplicate copies of common dependencies (except where different versions of a dependency cause errors)
JAR file will be small
Cons
Need to learn about the following:
Maven Repository
Publishing Maven Artifacts - see
Ant + Ivy specific preparations and procedures
Apache Ivy - Dependency manager integrated with Apache Ant
For reference, the Java™ Tutorials provide a good summary of JAR files.
Lesson: Packaging Programs in JAR Files
The Java™ Archive (JAR) file format enables you to bundle multiple files
into a single archive file. Typically a JAR file contains the class files and
auxiliary resources associated with... applications.
The JAR file format provides many benefits:
Security: You can digitally sign the contents of a JAR file...
Decreased download time: If your applet is bundled in a JAR...
Compression: The JAR format allows you to compress your files for efficient
storage.
Packaging for extensions: The extensions framework provides a means by
which you can add functionality to the Java core platform, and the JAR file
format defines the packaging for extensions...
Package Sealing: Packages stored in JAR files can be optionally sealed so
that the package can enforce version consistency. Sealing a package within a
JAR file means that all classes defined in that package must be found in the
same JAR file.
Package Versioning: A JAR file can hold data about the files it contains,
such as vendor and version information.
Portability: The mechanism for handling JAR files is a standard part of the
Java platform's core API.

"Jar Jar Links" is only good for a standalone applications. But not for Ant.
If your project has the same dependencies and they are upgraded to newer versions later on, like xstream-*.jar, then there will be a conflict, and the wrong version may be picked up. In the worst case there will be MethodNotFoundException. That's why it is a bad practice to include dependencies in a single jar.
What's a problem with "I don't want to be forcing my users to be copying-n-pasting 25+ JARs"?
That's the easiest solution. And the best, because you will avoid problems in the future.
Now, when you see the inconveniences of Ant, you might want to compare it to Gradle. With Gradle you get tasks a bit similar to Ant and you don't need to provide any dependency jars. All dependencies for you will resolve Gradle. And like in Ant you still can create your tasks.

Some java application vendors use the following scenario to distribute their application which depend on other jars, it reminds of static linking. At the stage of building the jar all dependencies (being also jars) are unpacked. When building the final jar, they include both their freshly compiled classes and the classes extracted from dependencies.
Possible issues:
Applications cannot reuse the libraries as they are contained in the app. Usual static linking issue.
The licenses of the repacked libraries must be respected. Usually it will be ok to repack them, but sometimes additional care must be paid to their license files, which may happen to be inside their jars.
AFAIK it's not possible to have jars inside the jar or it will be impossible to specify a classpath for them. Hence the repacking procedure.

What is the difference between "Module Dependencies" and "Libraries" in IntelliJ IDEA?

What is the difference between "Module Dependencies" and "Libraries" in IntelliJ IDEA when you want to add a .jar library to your project? Also, What is the "Export" check box when you are adding your .jar library to the "Module Dependencies" in IntelliJ IDEA?
In each of these ways, how are the classes and code inside the included .jar library integrated into your final project (code) when creating the newly generated .jar file?

Module dependencies are classes, archives, libraries and resources that your module files references. While a library is a set of class files stored in an archive or directory.
Export check means if checked then this library will be implicitly added to the other module that references this one.
To create a .jar file you need create an artifact. Artifact is a placeholder of the building output. There's predefined templates for creating .jar, .war, .ear archives. You can choose jar to build a jar artifact. By default it's defined empty and you need to define content of the artifact. You can drag-n-drop compiled output to it but don't do it with library archives. Because libraries in this case will be packaged inside the .jar file and you will be required to create a separate classloader to load them before your application start. Instead you change the artifact type to Other and drag .jar and dependent libraries into output root. This way library archives will be copied along with created .jar. You also need to create a MANIFEST.MF and specify Class-Path there for dependent libraries. All files will be stored in the directory you specify for building the artifact. You can build it using Build Artifact menu.

If your project contains multiple modules, "module dependency" defines dependencies between these modules, but libraries are compiled classes (usually jar files, optionaly containing theirs sources and javadocs) that are used by your module.
Each module can have its own libraries and artifacts (for example a result jar file), and can depend on other modules without circular dependency.

Module Dependencies tab can contain Libraries, Export means that a library from the module will be also available to another module that depends on this module.
Final jar with all the dependencies can be created using Artifacts.

"In IntelliJ IDEA, libraries can be defined at three levels: global (available for many projects), project (available for all modules within a project), and module (available for one module)."
Global library is set via Project Structure\Platform Settings\Global Libraries
Project library is set via Project Structure\Project Settings\Libraries
Module library is set via Project Structure\Project Settings\Modules\Dependencies

Difference between extracting and packaging libraries into a jar file

I would like to know the difference between extracting and packaging libraries into a jar file from eclipse with the runnable jar file creation.
If my program (runnable jar) uses other classes which require these external libraries(jars), what should I pick?

If you want to put jars into your generated jar file, you can use packaging method.
For example if you are using an Apache library or some other 3rd party jars, you may want to keep these jars preserved in your generated jar. In this case, use packaging.
"Packaging required libraries into a jar file" option puts classes of org.eclipse.jdt.internal.jarinjarloader package into your generated file and this package is just under the root directory of the generated jar file. This option also creates a larger jar file in terms of size due to jar loader classes of Eclipse.
Extracting required libraries will result in putting classes of 3rd party libraries into your jar file by following the package naming convention, e.g. if you open your jar content you can see some classes under org.apache.. packages.
Main class entries are different between the MANIFEST.MF files of these jar files:
Main class entry when you package required libraries:
Main-Class: org.eclipse.jdt.internal.jarinjarloader.JarRsrcLoader
Main class entry when you extract required libraries:
Main-Class: YourMainClass

For my use, the principal difference is that packaged JAR files are included intact as a distinct item, hence retaining their copyright information and signature data.
If you choose extract, the class files are pulled out of their original context and stored as if you had originated them, hence possibly violating some licence conditions, although the size of the final JAR will be smaller in this case. Eclipse does warn you about licensing in this case, too.
So, if using third-party JAR libraries, it's professional to always package.

Try it both ways, and open the resulting jar files with a Zip program. Very instructive.

These are mainly two ways to export as a Runnable jar in eclipse.
1). Package required libraries into jar
This will add actual jar files of the libraries into your jar.
This is the cleanest since it separates application class files with
library JARs.
The downside is this makes runnable jar perform very slow.
2). Extract required libraries into generated jar
This way will extract only the actual class files from the libraries
that your application uses and includes in the runnable jar file.
As a result your Jar file will include your application class files
as well as class files of all the libraries used by your application.
This method makes runnable jar perform just like it is run in your
eclipse IDE.

How do I include external JARs in my own Project JAR

I have a Java application and created a JAR file and deployed it.
The App uses external JARs such as the Log4J JAR. When creating my JAR file, how do I include all external dependent JARs into my archive?
In order to get my App working, I'm having to copy the Log4J JAR into the same directory as my own JAR which kinda defeats the purpose of the jar. Wouldn't it be more elegant to have 1 single JAR file to deploy?

If you use Eclipse, You can extract all included files into one runnable jar like this:
Right click on your project name from Package Explorer and select Export.
In Export screen, select Java -> Runnable JAR file and Next.
Fill in the Runnable JAR File Spec screen and Finish.
You can choose whether to package dependency jars as individual jar files or extract them into the generated JAR.

You could use something like One-JAR to package your Java application together with its dependency into a single executable Jar file (One-JAR uses a custom classloader to make JARs nesting possible).

You have to expand the library jars into the same place where your compiled classes go, then make a jar from that. Depending on how your build process is set up, there may be multiple ways to achieve this. It's not rocket science - a jar is just a zip archive with a META-INF directory at the root level.

Keeping JAR separate is better as it is easy to upgrade only the specific JARs to its new versions without touching any other configuration. As of your issue of having to copy each file to same location as of your JAR, you can always use Java CLASSPATH and include any JAR to your application's class path.

A JAR is not itself capable of nesting other JARs, as you discovered.
Traditionally, one would distribute a ZIP archive or other installer that would unwind the application JAR (yours) as well as any support JARs in the appropriate location for classpath access. Frequently, then, the application was invoked through a script that invoked the primary JAR and created a classpath that listed the support JARs.
As other posters have noted, you have some options to create a super-JAR if that's what you want.

You can use Maven + assembly plugin (http://maven.apache.org/plugins/maven-assembly-plugin/)
BTW, probably that's not the easiest way, if you did not work with maven.