[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.