| External JARS not being read [message #264339] |
Mon, 15 September 2008 15:45  |
Eclipse User |
|
|
|
I'm using a set of external jars. In the distribution folder, there is a
main jar and two folders, \lib and \endorsed with the other jars in them.
I have added these jars individually, and also as "class libraries" --
folders with the jars in them. In development, the jars are always
recognized. But when I go to debug, the main jar is found, but not the
supporting jars.
I have been offered advice like "add this to the .classpath" -- but I
don't see any .classpath file in my exported application. Someone
mentioned the Manifest.xml file...is this a substitute for the .classpath?
|
|
|
|
|
| Re: External JARS not being read [message #264464 is a reply to message #264378] |
Wed, 17 September 2008 14:38  |
Eclipse User |
|
|
|
"John Bailo" <John.Bailo@Bowne.com> wrote in message
news:e4e6495d08e1e654f5028096c0edede5$1@www.eclipse.org...
>
> Okay, I've gotten a bit further.
>
> Now I use the classpath attribute of the manifest.xml file to point to the
> needed external jars.
>
> That seems to work.
>
> For a servlet running on a Jboss server, there appears to be a logical
> disconnect between setting up the programming debug environment where you
> just add the jars in via project properties and the actual deploy, build
> environment, which you must somehow configure in a different way.
One of the ways that the various app server companies distinguish their
products is by the quality of their tooling around deployment and
configuration. Said tooling is contributed by the app server vendor, rather
than by Eclipse, in part for that reason and in part because Eclipse itself,
which is funded in large part by a consortium of vendors, tries to remain
vendor-neutral.
I can't quite tell, but it sounds to me like your question is about the
JBoss tooling. You may want to try asking on JBoss support forums. If not
that, you might want to try on the eclipse.webtools newsgroup, where you'll
find more people knowledgeable about web development for Eclipse. (This
newsgroup was a fine choice for your question, it's just that we don't have
quite the population of web developers here that we wish we did.)
> There is also the .classpath file. Some articles say use it. Some say
> avoid it and let Eclipse manage it all. I would prefer the latter, but I
> don't see an option that says "Eclipse, build my manifest or classpath or
> whatever will all the dependent software that is needed to run my
> application".
I'm not sure what you mean by "use it". The .classpath file is an Eclipse
project configuration file, not something that should be directly exposed to
an app server - I'd be surprised if there are app servers out there that
know what to do with an Eclipse .classpath file, though it's possible.
Certainly you should not be hand-editing the .classpath file, if that's what
you mean.
As a general rule, files starting with a '.' in their name are not meant for
direct inspection or editing, they're meant to be edited and read by
Eclipse.
If you look in your .classpath file, though, you'll probably see entries in
there that are meta-locations, that is, "classpath containers". The
WEB-INF/lib directory is one such container: its contents are added to the
Eclipse compile classpath programmatically, which is why you can just drop
things into that directory and have them on the compile classpath.
I don't know the JBoss tooling so I don't know how you distinguish between
libraries that you want for compile time only, versus libraries that you
want to be deployed in your WAR. Again, that is probably a question about
JBoss rather than about Eclipse, or at the very least it's a question for
the eclipse.webtools group rather than here.
Hope that helps!
|
|
|
Powered by
FUDForum. Page generated in 0.07170 seconds