Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / December 2006

Tip: Looking for answers? Try searching our database.

piece of $#!t eclipse can't find the main class

Thread view: 
Brandon McCombs - 28 Dec 2006 10:41 GMT
At one point tonight Eclipse was working fine. After specifying a
separate output folder for class files (and losing all the files in that
folder w/o Eclipse giving me a chance to do anything with them; I hope i
never meet any of the eclipse developers because they may not live long
if I do) I can't get eclipse to build my application now.  I always get
the lovely error:

java.lang.NoClassDefFoundError: org/rekkanoryo/ldapmgr/gui/LDAPMgr
Exception in thread "main"

I don't know why this is happening since that is the class that is found
when I tell eclipse to search for a main class (right click on
LDAPMgr.java, goto Run As, then Run to get Run dialog. I've specified
the following in the MANIFEST.MF file which is part of my project:

Manifest-Version: 1.0
Main-Class: org/rekkanoryo/ldapmgr/gui/LDAPMgr
Class-Path: lib/ldap.jar lib/ldapjdk.jar

I don't know where else I have to tell it the path to the main class
other than where I already have.

Any ideas on how I can teach eclipse to work again?

thanks
Oliver Wong - 28 Dec 2006 15:32 GMT
> At one point tonight Eclipse was working fine. After specifying a separate
> output folder for class files (and losing all the files in that folder w/o
[quoted text clipped - 19 lines]
>
> Any ideas on how I can teach eclipse to work again?

   Did you try cleaning and rebuilding the project? Quitting and restarting
Eclipse? Is your code in CVS or other source code repository?

   - Oliver
Brandon McCombs - 28 Dec 2006 20:32 GMT
>> At one point tonight Eclipse was working fine. After specifying a separate
>> output folder for class files (and losing all the files in that folder w/o
[quoted text clipped - 24 lines]
>
>     - Oliver

I ended up switching the output folder back to the same folder as the
source, and then putting it back to having a separate output folder. I
changed nothing else and after doing that it decided to build again w/o
complaining about the main class. FYI, I didn't restart eclipse and I'm
using subversion. I didn't try cleaning the project.
John Ersatznom - 29 Dec 2006 16:57 GMT
> At one point tonight Eclipse was working fine. After specifying a
> separate output folder for class files (and losing all the files in that
> folder w/o Eclipse giving me a chance to do anything with them; I hope i
> never meet any of the eclipse developers because they may not live long
> if I do)

Are you claiming that setting a separate output folder of C:\foo in
Eclipse wipes out all preexisting files in C:\foo? That sounds like a
serious bug. Remind me never to do that myself...
Brandon McCombs - 29 Dec 2006 23:03 GMT
>> At one point tonight Eclipse was working fine. After specifying a
>> separate output folder for class files (and losing all the files in
[quoted text clipped - 5 lines]
> Eclipse wipes out all preexisting files in C:\foo? That sounds like a
> serious bug. Remind me never to do that myself...

Yes, unfortunately that is what I'm claiming. I'm using Eclipse 3.1.2
(maybe a newer version fixes the problem). I decided to set an output
folder separate from my source files since I started using packages. I
thought it would make creating a JAR file easier since I wouldn't have
to worry about having source files mixed with the class files in the JAR
(although I think that can be avoided with specific syntax in making the
JAR).

I created an output folder and linked it to a real file system folder
which already had data in it. The folder that I linked to was called
"resources" and I created a new output folder in eclipse called
"production" and linked it to the "resources" folder. I expected a
folder called "production" to be created in "resources". What ended up
happening was that I compiled my project and got a complaint that a .bat
file that I had in the resources folder (and that was a resource in the
project) was missing. I went to the resources folder and none of the
files that used to be there were there any more and files from the
compilation process were there instead (like the .settings folder and
the .project file). Eclipse wiped out everything that was in the
"resources" folder without warning. It shouldn't need to do that (maybe
it does that automatically for cleaning purposes during a build but it
should warn you at the least). Needless to say, I was swearing up and
down for about half an hour after that.
Lew - 30 Dec 2006 00:06 GMT
>>> At one point tonight Eclipse was working fine. After specifying a
>>> separate output folder for class files (and losing all the files in
>>> that folder w/o Eclipse giving me a chance to do anything with them;
>>> I hope i never meet any of the eclipse developers because they may
>>> not live long if I do)

John Ersatznom wrote:
>> Are you claiming that setting a separate output folder of C:\foo in
>> Eclipse wipes out all preexisting files in C:\foo? That sounds like a
>> serious bug. Remind me never to do that myself...

> Yes, unfortunately that is what I'm claiming. I'm using Eclipse 3.1.2
> (maybe a newer version fixes the problem).

So does Netbeans and most command-line Ant build files I've used.

The idea is that a build folder (e.g., where you build your .class files) is a
clean environment to contain your deployables and only your deployables. A
"clean" build perforce gets rid of all the files in the output directory,
which by assumption are *all* built from your input files, so their loss
should not be such a keen issue.

Why in the world would you put files in the build folder that you wish to keep?

Don't go murdering Eclipse developers for doing the natural right thing just
because you didn't.

- Lew
Brandon McCombs - 30 Dec 2006 00:27 GMT
>>>> At one point tonight Eclipse was working fine. After specifying a
>>>> separate output folder for class files (and losing all the files in
[quoted text clipped - 17 lines]
> output directory, which by assumption are *all* built from your input
> files, so their loss should not be such a keen issue.

Well the files that were deleted were not output or input files. They
were configuration files I used to test the app.

> Why in the world would you put files in the build folder that you wish
> to keep?

Because I expected Eclipse to create the "production" folder that I had
specified in the Eclipse output folder dialog window. I thought it would
get created in the folder I linked it to instead of just replacing it.
At the least I think it should have warned me about deleting files,
especially ones that wouldn't result from the compilation process and
thus not normally be part of a cleanup process.

By the way, if this build folder is supposed to be where the
ready-to-deploy files are outputted, why is it that Eclipse puts the
project's .settings folder, the .classpath, and the .project file also
in the directory?  Those don't need to be deployed so why should they be
in the folder?

Also, does the Run operation imply a Project->Build and a Project->Clean
operation or just a Project-Build? If the latter then I shouldn't have
lost my files since it did a Clean w/o telling me it would.

> Don't go murdering Eclipse developers for doing the natural right thing
> just because you didn't.
>
> - Lew


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.