0

I need to produce a jar file that will be used by others as a library (lets call it 'myLib.jar'), thus the jar does not need to be executable. The library depends on some other 3rd-party jars but i will not expect from the ones who use 'myLib.jar' to include them in his/hers Buildpath.

While searching, i found OneJar and followed the 2 steps at the top of the page. 

1. Download one-jar-appgen-0.97.jar
   Generate application, build, and run it.
   $ java -jar one-jar-appgen-0.97.jar

2. Enter project path (project name is last segment): c:/tmp/test-one-jar
   Enter java package name: com.example.onejar
   $ cd c:/tmp/test-one-jar 
   $ ant 
   $ cd build 
   $ java -jar test-one-jar.jar
   test_one_jar main entry point, args=[]
   test_one_jar main is running
   test_one_jar OK.
   Add source code to the src directory, library jars to the lib directory, and rebuild.

Unfortunately, this did not worked for me since when i tried to include 'myLib.jar' in a new project, i was not able to use the expected classes.

So...

Q1: Is OneJar intended only for executable jars? If not how could i achieve what i have described above.

Q2: If OneJar is intended only for executables, is there another way to produce the 'myLib.jar' library?

PS: If there is a need to add more information please let me know, in order to edit my quetsion.

Mario
  • 767
  • 1
  • 14
  • 42
  • 2
    Why not just package your own classes in 'myLib.jar' and then inform users of your dependencies. Better yet, if you used a build tool like Maven or Gradle, you could declare your dependencies so that when they include your library, they get them automagically! – rmlan Jul 26 '16 at 14:06
  • Ideally, i wanted to distribute just one jar without any dependencies and without expecting from the users to do anything else besides including this jar to buildpath. If this is not possible, i may try something like maven. – Mario Jul 26 '16 at 14:14
  • Its possible (often times using something called 'shading'), but it shouldn't necessarily be used terribly often. Have a look at the majority of open-source projects in use today: they all either provide maven-like dependency declarations, or are packaged into a distributable _zip_ archive with all of their dependencies as separate jars (i.e. - not a single jar). The problem with the single jar thing gets into versions and classpath conflicts that become harder to find/debug. – rmlan Jul 26 '16 at 14:16
  • 1
    Also, why do you think that this is a requirement? It is totally reasonable to expect users of your library to have to have your dependencies on their classpath at runtime. I have never been discouraged from using a library simply because it had dependencies. – rmlan Jul 26 '16 at 14:20
  • 2
    Have you checked the license terms for your dependencies to make sure that it is OK to repackage the JARs. For at least some open source licenses, repackaging goes against the spirit, if not the letter of the license. (I'm thinking of LGPL's rules about "linking" ... which are intended to make it easier for your users to use a different version of the dependencies.) – Stephen C Jul 26 '16 at 14:21
  • 3
    You are going to create headaches when some wants to use myLib.jar with other libraries. Suppose myLib.jar had dependancy A version 1. Some other library may have dependency A version 2. You're forcing both versions into their path. – bradimus Jul 26 '16 at 14:22
  • So, from your comments i can understand that this is a sinful path :) I was considering the "expect users of your library to have your dependencies on their classpath at runtime" a bad practice but this seams not to be the case. If someone could post an answer saying this and justifying why we should not pack all jars into one (versioning, licensing, classpath conflicts etc), i will happily accept it as an answer. – Mario Jul 26 '16 at 14:50

1 Answers1

0

All the comments are suggesting to avoid packing the 3rd party libraries into a single jar. There are several good reasons for this:

  1. Packing all 3rd party libraries to one jar, permits the ones who use 'myLib.jar' to have up-to-date versions of the 3rd party libraries.
  2. It is forbitten for any other library to use the same 3rd party libraries which are packed in 'myLib.jar' because this will cause classpath conflicts.
  3. You have to be very careful with the licenses. Every 3rd party library will be probably bounded by a specific license. Many licenses are incompatible and cannot be used together.

So, what did i eventually do?

As @rmlan assured me, there is nothing wrong about notifing to the users of the library to add another library to their classpath. Keeping this in mind, i've created the following folder structure (which is actually what many others do) and zipped it in one compressed file:

myLib
-----bin
----------myLib.jar
-----documentation (mentions 'myLib' dependencies among other stuff)
-----lib (contains the 3rd party libraries)
----------thirdPartyLibrary.jar
----------anotherThirdPartyLibrary.jar
-----source (if it is an open source project)

Finally, in my case i could not use maven or another alternative, but if i could this would make the whole procedure much easier.

EDIT: To create 'myLib.jar' I've used eclipse

Community
  • 1
  • 1
Mario
  • 767
  • 1
  • 14
  • 42