1
\$\begingroup\$

This question is not about packing a simple jar file (e.g. lwjgl) into a runnable jar file. I know how to do this using JarSplice. So if I have a game which uses JInput, I will pack my game jar and jinput.jar using JarSplice and enter the natives in the process. The problem arises when I want to create a custom library that uses JInput, and then pack that into my games. See, the whole idea of writing a game library is that I don't ever have to even copy code like the wrapper I wrote for JInput Controller, and I always have a definitive version inside a library jar. Basically what I want to do is create a jar file of my library, pack jinput.jar into it using JarSplice, possibly with the natives as well, and then when I want to export a jar of my game, I either export it automatically through Eclipse with the library jar, or, if that doesn't work, use JarSplice.

I've tried several solutions, and nothing works. When I try to pack the game jar and the library jar using JarSplice, I get an error saying that there's either duplicate .project or .classpath. When I try to export my game through Eclipse with the library jar, it won't run (which is to be expected), but then, if I try to attach the natives with JarSplice, it doesn't give me any errors but the jar doesn't run.

I'm not expecting anyone to solve this, but if anyone has an idea, something that will allow me to never look at the Gamepad code ever again, that would be awesome. I don't care if I have to package my library jar using JarSplice 5 times, and then do the same with the game jar, as long as it works. Otherwise I'll just have to copy the Gamepad class into every project alongside the library jar. :(

Edit: to clear things up, here's what I'm trying to do-
JInput has a class Controller, for controller input.
My_Library has a class Gamepad, which is a wrapper for JInput's Controller.
My_Game should be packed with My_Library so that it can access My_Library's different utilities, including Gamepad (for example, the class Player in My_Game has a field Gamepad for the player to pass gamepad input).
If I can't pack them all into one fat jar, I guess it's OK, as long as I'll be able to place Gamepad in My_Library and access it from My_Game.

\$\endgroup\$
  • 1
    \$\begingroup\$ Sounds like there is likely an easy solution for this, however I don't understand the problem clearly. Could you "visualize" it by listing the content of these different .jar files (JInput, Custom_library, Game) with just a few example files and respectively the end result you are looking for? \$\endgroup\$ – msell Jun 30 '13 at 5:19
  • \$\begingroup\$ OK, I edited it. \$\endgroup\$ – Hillel Jun 30 '13 at 5:35
  • \$\begingroup\$ I believe this is off-topic here, this is a general Java question. You might have better luck at stackoverflow, where it is probably already answered. \$\endgroup\$ – MartinTeeVarga Jun 30 '13 at 7:10
1
\$\begingroup\$

Note that .jar files are simply .zip files with a different extension. You can freely view the contents and modify the archives with any zip program. Java also comes with a jar utility, which is a command-line program for creating, modifying and extracting .jar files. To make a .jar file executable, a manifest file is needed with main-class attribute. Learn to use these well. Don't be dependent on Eclipse creating your .jar files. Instead do it yourself from the command-line. Then make a script (either a shell script or Ant / Maven script), which does this for you. At least with Apache Ant manipulating .jar files is easy and combining multiple .jar files is simpler than from the command-line. Once you know how to work with .jar files well enough, you can offload the creation process to Eclipse or whatever tool you prefer, but only when you are the master and the tool is the slave.

One problem with executable .jar files is that the native binaries don't work inside them and must be present on the filesystem next to the .jar files. This is the point where you need JarSplice. It creates a wrapper class in the .jar file that first extracts the native files (e.g. lwjgl.dll) and then executes the original program. In addition it can create a native application such as .exe file for Windows. This means that JarSplice should be run only once and should be the last step when creating the distributable package. For intermediate libraries you should just combine the .jar files directly.

\$\endgroup\$
  • \$\begingroup\$ Don't get me wrong- I appreciate what you're trying to do, and I'm all for learning. When I get some free time, after I finish my engine, I will learn this. The thing is, right now I need a solution. If you could add a list of operations I need to do in order to achieve what I'm trying to do, I'd learn a lot more from doing them, rather than trying to understand the jar mechanism in order to solve one problem. \$\endgroup\$ – Hillel Jul 1 '13 at 8:08
  • 1
    \$\begingroup\$ I'm sorry, but I disagree. When I was a kid before the Internet, I learnt programming by copying and it wasn't very efficient. It's far more important to understand what you are doing, otherwise you'll just run into more and more problems you can't solve yourself. We are here to help with problems, but not to write complete solutions for others. Even if I wanted to find out the exact commands, it would be impossible with the given information, as this problem is local to your build setup. Also stackoverflow.com would be better site for issues related to manipulating Java Archives. \$\endgroup\$ – msell Jul 1 '13 at 21:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.