[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Newsgroup Home]
[news.eclipse.newcomer] Re: user library problem

"Roger H. Levy" <rhl@xxxxxxx> wrote in message 
news:gomrdr$o8j$1@xxxxxxxxxxxxxxxxxxxx
> Project 1 consists of classes I want to structure as a library.  Each 
> class is in "package X" and I produced a jar file that has a directory "X" 
> with all the class files in that directory.
>
> Project 2 is an application that needs to use the library.  I created a 
> "lib" directory in that project and imported the library jar into it. 
> Then I right clicked on the imported jar, selected "build path" and 
> selected "add to build path."  At that point all errors in source files in 
> Project 2 that imported classes in package X cleared.
>
> I then exported Project 2 to an application jar file.  The jar file has a 
> lib directory with the jar from Project 1 in it.  There is a .classpath 
> file with,
> <classpathentry kind="lib" path="lib/X.jar"/>
> and there is a manifest file that identifies the Main-Class.  Everything 
> seems in order to me but when I execute the application I immediately get 
> class not found exceptions for classes in the library.
>
> I've built simpler projects before but use of a user library is new for 
> me. Can someone identify the problem?


Sounds like you're trying to embed one jar file in another.  The JRE doesn't 
know how to cope with that, unfortunately; it doesn't have any way of 
expanding the jar file at runtime.  (Also, at runtime the .classpath file is 
completely irrelevant; that is just an Eclipse compile-time thing, that you 
should not even include in your packaged .jar file.)

The inability to deal with embedded jar files is a Java limitation, nothing 
to do with Eclipse.  Normally you would deliver the jar files as separate 
files, and the user would list them individually on the classpath; or you'd 
deliver them separately and project 2's manifest.mf file would have a 
classpath entry pointing to the project 1 jar file with some relative path. 
There are also some solutions that can package jars together into a single 
executable; google "FatJar" for an example.

If you're coming at this from a C/C++ background you might want to think of 
jars as being a bit like DLLs: if you package up one DLL as a resource 
inside another, it won't be executable unless you write some custom code to 
extract it at runtime.  Same with Java: you can write custom code to do it, 
but it doesn't happen automatically.