We recently had an issue with an Eclipse project for one of our team members. Tomcat was not deploying JARs of the application.
We eventually noticed the .classpath Eclipse file was not the same as for the team members where the project was OK. We replaced the .classpath file with one from a project that was OK and the Tomcat deploy was complete.
Just out of curiosity and to know at what to look in the future if something is wrong, what is inside the .classpath and .project files. What can I add in there, what does it all mean?
Eclipse is a runtime environment for plugins. Virtually everything you see in Eclipse is the result of plugins installed on Eclipse, rather than Eclipse itself.
The .project file is maintained by the core Eclipse platform, and its goal is to describe the project from a generic, plugin-independent Eclipse view. What's the project's name? what other projects in the workspace does it refer to? What are the builders that are used in order to build the project? (remember, the concept of "build" doesn't pertain specifically to Java projects, but also to other types of projects)
The .classpath file is maintained by Eclipse's JDT feature (feature = set of plugins). JDT holds multiple such "meta" files in the project (see the .settings directory inside the project); the .classpath file is just one of them. Specifically, the .classpath file contains information that the JDT feature needs in order to properly compile the project: the project's source folders (that is, what to compile); the output folders (where to compile to); and classpath entries (such as other projects in the workspace, arbitrary JAR files on the file system, and so forth).
Blindly copying such files from one machine to another may be risky. For example, if arbitrary JAR files are placed on the classpath (that is, JAR files that are located outside the workspace and are referred-to by absolute path naming), the .classpath file is rendered non-portable and must be modified in order to be portable. There are certain best practices that can be followed to guarantee .classpath file portability.
.project
When a project is created in the workspace, a project description file is automatically generated that describes the project. The sole purpose of this file is to make the project self-describing, so that a project that is zipped up or released to a server can be correctly recreated in another workspace.
.classpath
Classpath specifies which Java source files and resource files in a project are considered by the Java builder and specifies how to find types outside of the project. The Java builder compiles the Java source files into the output folder and also copies the resources into it.
Complete reference is not available for the mentioned files, as they are extensible by various plug-ins.
Basically, .project files store project-settings, such as builder and project nature settings, while .classpath files define the classpath to use during running. The classpath files contains src and target entries that correspond with folders in the project; the con entries are used to describe some kind of "virtual" entries, such as the JVM libs or in case of eclipse plug-ins dependencies (normal Java project dependencies are displayed differently, using a special src entry).
This eclipse documentation has details on the markups in .project file: The project description file
It describes the .project file as:
When a project is created in the workspace, a project description file is automatically generated that describes the project. The purpose of this file is to make the project self-describing, so that a project that is zipped up or released to a server can be correctly recreated in another workspace. This file is always called ".project"
Related
I have done my first project using spring boot, I like it :)
But now, I have several files, that I don't know if I have to git it or ignore it
.classpath
.project
.gradle/5.6.2/*
.gradle/*
.settings/org.eclipse.buildship.core.prefs
bin/main/*
build/class/java/main/com/.../*.class
build/libs/snapshot.jar
build/reports/test/test/*
build/resources/main
Can you tell me which one should I include in my VCS ?
There is no clear answer to your question because it depends on whether you want them to be committed or not :) but...
.gradle is a folder that includes settings for building your project. Deleting it is safe, because Gradle will generate it again anyway
bin is usually where the compiled Java classes are copied to
build is where Gradle generates all build artifacts
.settings is where Eclipse stores its preferences files
.project if I'm not mistaken, this file is also related to Eclipse and describes the project somehow
.classpath maintains the project's source and target references for Java compilation
All the files above can be regenerated. For example, Gradle is probably generating the .classpath for you, while .project is generated by Eclipse.
Regarding build and bin, there's no good reason to commit them
I can't make the decision for you, but instead of you, I would ignore all of the files you've mentioned.
I am new to project environment setup. Below is my project structure in eclipse
Project Name
--> .settings
--> .bin
--> lib
--> resources
--> src
--> .classpath
--> .project
I am attempting to export src folder as jar.
When i export to jar, all the above folders & files are created in jar. But i need to convert only src folder as.
Also when i export to executable jar, all the third party libraries are exported as class files in jar. is it right.
What is the best practice to export project. Only src folder or everything.
Which i need to use jar/runnable jar. My requirement is to write start/stop bat file to call jar and execute java program.
Please advice me. Thanks in advance.
First it's important to know what these folders actually do. Following are the workings of several of these files.
.settings -> This file records project specific settings and workspace preferences.
.bin -> folder is usually where the compiled files are copied to.
lib -> contains external libraries that are used in your project (like Apache Commons)
resources -> the resources like images, text, pdf, audio, video are usually copied here
src -> the folder where the project's source files are located.
.classpath -> It contains information that the JDT feature needs in order to properly compile the project: the project's source folders, the output folders , and classpath entries.
.project -> This file is maintained by the core Eclipse platform, and its goal is to describe the project from a generic, plugin-independent Eclipse view.
So you can see that if you exclude some of the files like lib, resources, bin etc... Your jar file will probably stop working. Your jar file needs compiled files and their dependencies.
For example: All your compiled .class files are in bin folder. And your jar works because of these .class files and NOT .java files that are in src. If you delete this bin folder then your jar will probably stop working.
Also, your project may be using some external library supplied by someone else. Like Apache Commons or google/guava and these are usually in lib folder. So you can't delete this folder as well.
However, if you no longer expect to use .java code, then you can exclude files that were created by eclipse to manage this project. See this post.
see also:
1. What's in an Eclipse .classpath/.project file?
2. exclude files from jar or war in eclipse
EDIT: I appreciate the suggestions for Ivy or Maven, but this is just not an option for me at this time. I do not have the authority to use those tools. I am simply looking for a way to get my referenced .classpath JARs into a folder inside my project.
I have created a project that uses about 50 external JAR files that I referenced from other projects inside the same workspace.
Thus, my project's directory strucure looks like:
MyProject
src/
test/
Referenced Libraries/
... 50+ JARs
lib/
My project compiles and runs beautifully inside Eclipse. But now I need to add a buildscript so other developers can pull the project down from SVN and run it standalone. To do that, I'd like to place all the JARs that are currently in Eclipse's in-house directory Referenced Libraries and copy them into my project's lib directory which I will JAR-up with the final distribution.
I'm in Package Explorer, and have tried to just copy + paste the files from Referenced Libraries to lib/ and no dice. I get the following Eclipse error:
Cannot paste the clipboard contents into the selected elements.
Anybody have any idea how I can force this copy operation to work? If I right-click any JAR inside Referenced Libraries I see an Eclipse option called Migrate JAR file, but I'm afraid that would cut-n-paste the JARs from their current location to the new lib/ directory. This isn't feasible because there are many other projects that need these JAR files exactly where they are.
Thanks for any insight here!
Have you considered Maven? It's an exceptional tool for situations like this. For file operations it's best to use Navigator view.
I don't find another way to go but to copy yourself the jars into your lib folder, add the references to your lib files (not to external jars on your machine) and upload it to SVN.
EDIT to clarify:
Remove all references from your build path. Now you can't compile the project.
Copy every jar file you need to your project's lib folder.
Go again to build path and add the references to your jars (the ones on lib) one by one. Use the button that says "Add JARs...", not the one that says "external JARs".
Compile, and if everything is fine,
Upload the whole project to SVN.
I'm working on a Java Netbeans 6.7 roject with a few developers and we're using Mercurial for version control. I was wondering what I should put in the .hgignore file (ie. what files should not be added to the repository). I know I will definitely want the src, test, and lib folders in the repository and the build folder to not be in the repository. But I'm not sure what to do about the nbproject folder.
You must ignore the following folders: build (or nbbuild), dist (or nbdist), and the nbproject/private.
And if you want others to open it with netbeans (as you do in netbeans) you must add nbproject folder.
Though nbproject/private should be ignored, nbproject should be
checked into the version control system.
If you want more information, see netbeans help on http://netbeans.org/kb/docs/java/import-eclipse.html#versioning
If you have created these projects under an existing clone/repository, the NetBeans/Mercurial integration will already have a good idea of what to include or ignore.
NetBeans will automatically include files in nbproject that are considered to be environment independent. Files that include environmental dependencies (like directory paths) are usually placed in nbproject/private directory. You probably do not need to save those to your repo.
You may want to exclude the nbproject/build-impl.xml... it is generated when the project is opened... But, if you do not have it in your repo you will run into problems if you attempt to build the project with ant, independent of the IDE.
Anything that can be generated from what you check in should not be in the repository: no .class, .war, generated .jar, etc.
I have just created a .properties file in Java and got it to work. The problem is where/how to store it. I'm currently developing a "Dynamic Web project" in Eclipse, and have stored the properties file under build/classes/myfile.properties, and I'm using this code to load it:
properties.load(this.getClass().getResourceAsStream("/myfile.properties"));
But won't this folder get truncated when building the project, or not included when exporting as a WAR file? How can I add this file to the build path, so it will be added to /build/classes on every export (in eclipse)?
If you add your .properties file into the source folder, it will get copied into the classes folder at build time. I usually create a separate "Source Folder" in my projects to hold .properties files and other non-Java source files.
See my question on copying property files using an ant task. Eclipse will do this automatically, as #highlycaffeinated has suggested, but you have to make sure your list-of-files is up-to-date (refresh files on your project before you debug/run/deploy).
I use ant for more formal control over this.
Putting it anywhere in classpath will do. Just make sure it is included in WEB-INF/classes after deployment/build.
In maven projects the standard place for property files is /src/main/resources. You can put it there ant add this folder as eclipse "source folder".
You can put the properties into the "Web App Libraries/classes" folder, which corresponds to "src/main/webapp/WEB-INF/class" folder on the disk (eclipse automatically creates the shorthand version above):