A friend and I are working on a java project in Eclipse. Whenever we "ship" a new version we export it to a runnable jar.
It seems whenever we try to send the file back and forth (over google drive) to work on separate parts of it something gets messed up. This doesn't happen for him, but when I download the file from Google Drive, Eclipse does not recognize any change I make to the src.
It doesn't matter how many times I change the workspace, move/ rename the file, clean/ build the project. Nothing seems to be solving this problem. Any advice on why this is happening and how to fix it?
It would be infinitely better for the both of you if you looked into some kind of source control system, as opposed to a file sent through a file sharing service.
Sharing the source code in a JAR doesn't allow you to:
Keep a revision of known working code, in case something breaks
Reliably import the code
Keep track of changes (who did what to what file, etc)
Look into something that's suitable for sharing between users. GitHub and BitBucket both offer free Git hosting, which is a very popular source versioning tool.
Eclipse is probably building the new version of the runnable JAR in the project's output directory, which by default is something like %PROJECTDIR%/target. The new version of the JAR with your changes will be there, and you'll have to export them again to trade files back again. See also: How do I change a Java project's bin folder in Eclipse?
it is probably because it is not updating yours .class, try delete .class of "target" folder of your project, make clean (project - clean) and save again the changes
There are many steps where you can solved it,
Clean Project and Re-Build
Remove .metaData and .settings from Workspace
Clear cache
In my case, I have tried much more and I got to resolve it by removing Classes, test-classes folders if Its there in Target folder
Related
This is my first post on stackoverflow, so I apologize if I do anything incorrectly!
I have a project I've been working on in eclipse 4.6.2 ee neon2. In this workspace folder, I have several other folders such as one that includes my database files, and another called "lib" that includes open source libraries such as joda-time and eclipselink. I'll usually export zip files straight into this "lib" folder, and import the relevant external libraries into eclipselink from this "lib" folder. However, just tonight - I'm not sure how it happened, but eclipse generated some 500 warnings/errors on html/xml files from various open source libraries in the "lib" folder - including readme.html's and so on. I've been unable to find the reason for why they all suddenly appeared. I've tried to disable validation extensively which removes nearly all the errors but I feel that that's a patch up job.
Also note that my program seems to run completely fine, and passes all tests I've written for it. There are no new errors in the src folder, all in that one folder "lib".
My question is what I possibly could have done to make these 500+ errors appear out of thin air? Should eclipse even be generating errors on files outside of the /src folder that is contained in my project directory?
Please let me know where I'm unclear or what I can provide to help things be more clear as I've not had much traditional programming experience and can have trouble phrasing things in the correct way.
Thank you!
-As per the request here are some of the errors it's generating. Note that all the files the errors originate in have not been created by me, they're from open source packages.
If these didn't show the proper information, let me know!
Double Edit - I do realize if I remove the "lib" folder altogether, and import the external jar's, this entire problem would be resolved. However I'd like to know whether the error detection outside of /src is the intended behavior of eclipse. Thanks again!
Edit many days later - SOLUTION: I had found the solution myself, which was identical to Exclude directories & subdirectories from validation in Eclipse. I had to clean my project to get the exclude rules to apply!
When I posted this question, my solution was to recreate the project and add back all the external libraries.
I then stumbled upon this problem, months later, attempting to put my external libraries in a folder called /lib/ in the same directory as my project in eclipse. This triggered a similar flood of warnings in the screenshots in the post.
The proper solution, to avoid the errors while keeping your external libraries in the same folder, was identical to the solution I found here: Exclude directories & subdirectories from validation in Eclipse.
I had to clean my project to get the exclude rules to apply, but after that worked like a charm, and all the errors cleared up.
I have been working on a project locally and at some point I gave the project to someone else to work on.
Since that time, I have created another package with classes and so on in my own project version. Since I want the other person to have this package, I gave him the package folder which he copied in the path ProjectName/src/packageName.
Of course, he didn't see it right away, so I used New->Source Folder and refresh/clean/pray to make it work.
The question is: is there some other way to add packages to projects? as I'm not sure this is the right solution.
A refresh is sufficient after you have dropped the new source files inside the source folder. No need to add a new source folder.
The clean way to collaborate is to use a version control system, like Subversion, git, or whatever. Copying files between developers is a recipe for chaos.
From backend, Go to ProjectName/src and copy/paste all the package, and then right click and select "Refresh".
Simply dropping in the files and refreshing is sufficient. Eclipse will automatically ammend the package declaration in the Java sources.
That all being said, you should be looking at using a version control system such as CVS or subversion for example.
Copy the folder at desired location.
Refresh the project in eclipse. It will be visible now.
Right click on the folder in eclipse under project explorer. Select Build path>Use as source folder.
I accidentally deleted a .class (Java bytecode) file in my project (on the filesystem, not using Eclipse itself). Easy to fix, right? Just re-build it. But that doesn't work! Even if I select "Build Project" or "Build All" or "Build Automatically" from the "Project" menu, nothing actually happens on the file system, and I still get:
Exception in thread "main" java.lang.NoClassDefFoundError
I just want to re-compile this from the source code I already have!
By the way, when I choose "Clean..." from the "Project" menu, Eclipse doesn't delete any files either. I have also tried re-importing the project into a different folder, but Eclipse just copies all the .class files and the problem persists.
The OP answered his own question in the comments (2 and a half years ago):
Found the solution: another project on which that project depended could not be compiled, because it could not be cleaned, because Eclipse wanted to delete the .svn directories throughout that project (I have no idea why), and it could not because some of the files didn't have write permission. I was happy to wipe out all the .svn data just to get this working! Thanks for the hint. – user690075 Sep 7 '11 at 1:25
In regards to the bounty
This question has not received enough attention.
This problem keeps wasting hours of my time.
IF the OP's answer didn't resolve your issue, you should ask a more specific question on a new post, describing what you've attempted and how the OP's solution didn't resolve your specific issue.
That being said, assuming you did try the solution the OP posted, it is possible a different issue (that wasn't caused by deleting a class file) is causing the same error. Because you started a bounty on someone else's question and you can't get your prestige back I thought it would be appropriate to mention it might be worth your time to make sure your JDK version(s) are compatible between old or external source code used in your project. You'll get the same error NoClassDefFoundError when the compiler reaches a point in your code that references an object/class that's defined in a library that was developed on an incompatible JDK, it's missing key internal dependencies that are not found within your JDK version.
I would go into more detail, but since this question is specifically about an error that came about from deleting a class file I don't feel it's right to do so.
Do a complete clean
1) Find and delete the .eclipse folder (you may back them up first)
2) Delete related .class files
3) If there are any .svn folders, delete them either manually or via your svn client
4) Do not use auto build for this, but manually select only the broken project and do a clean (in case there are dependencies)
If that fails, probably a good idea to package your source codes and re-import as a new project. That can avoid wasting time on a probable IDE bug
In more traditional languages, programs are loaded all at once as part of the startup process. Java doesn’t have this problem because it takes a different approach to loading. This is one of the activities that become easier, because everything in Java is an object. Remember that the compiled code for each class exists in its own separate file. That file isn’t loaded until the code is needed. In general, you can say that “class code is loaded at the point of first use.” This is usually when the first object of that class is constructed, but loading also occurs when a static field or static method is accessed.
If You can't restore from local history. Then you are out of Luck. Use Source Control Management Tools like SVN or Git to avoid such surprises next time.
If you are having source file try to compile file along with dependencies alone in console or other IDE and copy that class file let the errors be errors now edit source file in eclipse try to build again. Hopefully this will not work because even eclipse will neglect Re-compiling some files while building Project. Better Give a Try.
You sure this source file is in your project's source set? Because Eclipse will only compile and put it in your classpath in that case. Right click the project in Package Explorer, Properties -> Java Build Path -> Source. The enclosing folder should be there or Eclipse won't compile it.
In case, say, this source file of yours was once in source set and was compiled that could explain why it was working up until you removed the binary.
In order for this problem not to happen I suggest having Scrub output folders when cleaning projects being selected in Java -> Compiler -> Building and Build automatically... on in Project menu.
Also make sure your project compilation/build succeeds, otherwise Eclipse may not compile all the classes.
If it still doesn't help it could be important what type of project you are having problems with: Java Project, Maven Project, Gradle Project, etc.
To the person that put the bount out, maybe you could just commit all your changes to what ever code repository you have, after exiting eclispe just delete the whole workspace, then create a new workspace and re import all the files into the new workspace from your code repository.
Background:
Here at the office my group uses a common linux environment where we do our code development. Our code is kept in CVS. The latest releases of our various libraries are kept in a specific directory (ie /data/group_projects/lib). Our Makefiles/Ant builds all specify what libraries are needed. We use autoconf to create the makefile after checkout for most C/C++ projects. We've just got Eclipse (3.4) installed and are planning to incorporate it into our workflow.
Problem:
So, when I check out a project from CVS through the Eclipse interface and then I have to set up all of the library paths (and include paths for C/C++). For some of our projects, this could be a lot of work. Is there a good way to save these paths along with the code when I check it back into CVS?
Ideally, when the next person checks out the code in Eclipse, the paths (and anything else they might need) will automatically be set up and they will be able to compile straight away.
Efforts:
I know that the include/lib path info is kept in a .cproject or a .classpath file (C/C++ or Java respectively). I thought I could export this info through Export -> Preferences. The resulting epf file doesn't have any path data in it unfortunately. I tried directly adding the .cproject file to one of my projects (so I could then put it into CVS) but Eclipse really doesn't seem to want me to do that.
I am quite new to Eclipse (esp using CDT), but maybe the necessary path info can be pulled out of build.xml/Makefile automatically by Eclipse? There seems to be a bit of a disconnect in Eclipse between the buildfile/makefile and the jar/include files that the IDE uses for checking your code as you type it. Maybe I am missing something?? I'm planning to put some serious time into researching Eclipse over the next few days so hopefully the inner workings will become much more clear to me.
I've asked the guys here at the office but no one is much of an Eclipse guru. My searches haven't turned up much . . I did see a suggestion to add all external jars to Java -> Build Path -> User Libraries under Eclipse Preferences. For us, each user would have to set this up once but afterward all of our java libraries would be available to whatever project we decided to check out. Unfortunately, it doesn't seem as though I can do the same thing for CDT.
What would you suggest? Am I missing a setting or function of Eclipse? Or am I going about this the wrong way? Please let me know what you think. I'd really appreciate it. Thanks!
You simply need to share the .project, .cproject and .classpath files through CVS. You can do this from the cvs command line, or select then 'Team/add file to version control'.
You don't need to add these files to the project explicitly: they are inherently part of it.
Obviously, if you do this, you need to make sure they are location-independent.
See:
eclipse wiki
Safari books
I've done this in Eclipse, and it's not too hard. You have to check in the .project and .classpath files. There are one or two places where Eclipse doesn't correctly automatically check out the files when you want to edit them, so when you get a read-only error you have to go manually do it, but for the most part it works.
The paths need to be all relative.
If relative paths is a problem, you can also take advantage of workspace variables in Eclipse. The developer sets their workspace variables appropriately on their machine (e.g., OPENGL_INCLUDE_PATH ), and then in the builder you can set the environment to pass that path along.
I'm having a difficult time figuring out how to add a .jar/library to a Netbeans project in such a way that I can get it committed to the repository.
The typical way to add a library (per the Netbeans documents I've already gone through) ends up with it just being local to me. Anyone who checks out my project ends up missing my required library.
Inserting it manually and trying to work around Netbeans results in Netbeans hanging while trying to scan the project...
So, how can I tell Netbeans to pick up a jar as a library and include it in my project in such a way that Subversion will be able to handle it?
There are a couple ways to fix this.
A. When you define your Library, use a path to a common location. A location that's identical on everyone's machine--such as the location of a JAR installed with a third-party app into Program Files or /usr/local/ works well or a network drive.
Then, when they check-out the code, the path will still be correct and they do not have to define the Library on their Netbeans workspace.
B. Edit your project.properties file to use a relative path. Open your project.properties file and look for "libs.LIBRARY_NAME.classpath=...". That will be the "default" location used if the Library is not defined.
Change this to use a path relative to your project and store the jar files in your project. For example:
libs.Log4J.classpath=lib/log4j.jar
Keep in mind that the Library definition in your Library Manager will override this value--so make sure you keep them in-sync (i.e. append a version number to the library name!).
C. Use Vincent's suggestion of using a build-system such as Maven. The Maven build-process will take care of downloading dependencies, etc. Netbeans has plugins for several popular build systems.
There is a new feature in NetBeans 6.5 (variable-based paths in projects) which should make this easier.
See http://wiki.netbeans.org/NewAndNoteWorthyNB65#section-NewAndNoteWorthyNB65-VariableBasedPathsInJ2SEJ2EEProjects for details. Note the screenshot includes variable references in the library customizer.
Not really an answer to your question but... generally you should not include these libraries in your subversion repository. There is usually no need to have them managed. What you might want is to set up a central repository similar to what happens with maven. If you use maven, you can create a local repository of libraries on a server accessible by the team. The dependencies on these libraries are entered in the pom.xml file and this is in the subversion repository. Now, as team members check out the code from subversion they all have access to the maven repository.
[I am looking for a reference to this right now. When I find it I'll edit this answer.]
I use NetBeans IDE 6.5.1 and the best solution I've found so far is to include the needed libraries from your local host and then change their paths to relative. After that you have to remove the libraries manually from the NetBeans file explorer, and then copy them from their OS location in your computer manually to the file explorer again. That way NetBeans detects the change and you can commit it to the repository.
Note: I Highly recommend to clean and build the project again after updating.
An easy way to pack up your lib/jars into your project so that subversion "just handles it" so you can grab it out with all the attached libraries ready to compile and go is to include them all under your project directory via the "shared libraries" option by managing the libraries folder.
When creating a new project you can specify "Use Dedicated Folder for Storing Libraries" and then use the suggested relative .\lib path. If you have an existing project, you can edit it's properties, Libraries Category, and Browse for a Libraries Folder. Again a first-time run will suggest .\lib and then offer to copy existing dependencies to that folder. These graphical actions should provide similar results to James Schek's 'B' answer.
Commit the project with the newly added libs in .\lib and you should be able to checkout and build from anywhere and know you'll have the same libs (at the same version) as you had when you last built and committed.
I don't know how long this feature has been in NetBeans. For more details see:
http://netbeans.org/kb/docs/java/project-setup.html#projects-shared-libraries
I ended up just downloading my own set and putting them on my local drive for this project. I setup my Netbeans to look there and warned the other guys what I did... Eventually, we'll have to do something a bit more scalable though... :-)
OK, the working solution that I've now moved to is to extract the class files out of the jars and dump them into the Source Packages area. Then it all gets committed to the repository and also avoids having to deal with handling a separate "lib" directory in the deployment phase.
This solution does everything I'm looking for, yet I feel real dirty about doing it this way. It just seems horribly broken and wrong... :-)