Every projects in eclipse has 4 .files(.settings,.classpath,.cprojects and .projects).
Can anyone explain me why are these files generated and what happens if I delete these 4 files. I have deleted these files from one app which resulted in changing the name of app.
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.
The .settings folder is used by various plugins to set persistent 'Properties' as opposed to 'Prefereneces' to specify project specific settings that should be preserved.
.settings is usually a directory you most definitely want checked into svn/cvs/git etc as it will ensure that all users who check that project out into eclipse use the right project specific settings.
In our case we use it to supply a minimum compiler version of java but we want things compiled to 5 for our servers. We also use it to enforce some coding standards and auto-formaters which makes version diffs much easier to read.
In your specific case you selected 'Enable Project Specific Settings' under "Properties->Java Compiler" by right clicking on the project and choosing properties.
Related
I'm working on eclipse-kepler.
when I try to add external jars, they are added under the project and not under any folder (that is under the project),
Is there a way I can abbreviate (shorten/shrink) them so it wouldn't be so annoying?
Well, it depends on what is your issue.
If you would like to filter out libraries, there is a magical button, a white triangle on the top bar of the Package Explorer. There you can filter out all the libraries with a click so they won't be enumerated (see this screenshot).
If the issue is that they are included as external Jars (which I'd discourage, since it becomes harder to set up the project in a different environment both for you and others), simply create a lib folder, copy the Jar there and include it as simple Jar files (that way the .classpath file won't have any absolute paths).
Actually this feature is quite handy, it saved me a dozens of times. When there is a problem with a class you are using you can easily locate it by opening the type with Ctrl+Shift+T and linking it with the editor. It can go into the Jar files and show you where is it. When there is a Claspath conflict it can be a life saviour.
This issue is a variation on the one described here: Eclipse buildpath automatically taking all JARs of a internal directory
But instead of any local folder, I'd rather have a linked folder from another project be picked up automatically in the buildpath.
Basically, I have a main project in my workspace that holds directories lib, ext-lib that contain multiple jar files each. These jar files may be upgraded/removed or new ones added every few days.
I also have many other projects in the workspace that relay on the exact same (up-to-date) jars from my main project.
My goal is that as I modify the jars in these two folders in my main project, to have them as linked folders in all other projects and have those linked projects dynamically picked up as part of the buildpath of all those projects.
Any suggestion on how to do that in eclipse would be highly appreciated.
Unfortunately, the "dynamic directory" plugins people mention can not work with "linked" folders :(
Sincerely,
Guy
I would suggest creating a USER LIBRARY in eclipse and then using that in all of your eclipse projects.
Try going into preferences Java -> Build Path -> User Libraries and creating a new user library with all your jars. Then use this everywhere you need these jars.
See this page for more details.
Also, this page explains creating a user library in a bit more detail. There is also a use-case there which seems a bit more aligned to what you had in mind:
6.2.1. Linked Library Project
A useful hybrid strategy is to configure a user library that is also available as a linked folder in your Eclipse workspace. Follow these steps:
1.
Create a simple project in your workspace. Unlike Java projects, a simple project has no Java build path configuration in its properties. Use the command File > New > Project > Simple Project.
2.
Uncheck the option to use a default project location within the workspace folder and enter the path for your \eclipse-contrib\libraries folder (see Figure 6-8).
I am currently working on an effort which makes use of Windriver's Workbench tool, which I understand is built on top of Eclipse.
Our source control tool is ClearCase and we are working primarily out of snapshot views located on the workstations of individual developers. As a result the absolute path for each developer's view is different. As deeply nested relative paths can be somewhat cumbersome (e.g. ../../../../../Some_Package/src/) we are using a Linked Resource PROGRAM_ROOT_PATH which identifies the particular view directory for a given developer.
This is working relatively well for for referencing header and library directories in the build properties, but we are trying to reference that Linked Resource from our build scripts in order to do build post processing such as copying the compiled program to a release area.
Accessing the Linked Resource as though it were an environmental variable appears to be the wrong thing to do as $(SOURCE_ROOT_PATH) provides an empty string. Is there a way to access this information from Eclipse / Workbench from a makefile?
Look inside the .classpath and .project files in the root of your workspace project - I believe the linked resource should be defined in one or the other of those (probably .classpath). From your script (you don't mention if it is Ant, Maven, Gradle, etc.) you should be able to find a way to get that value out of the .classpath (through some plugin or custom code).
We use Eclipse, ClearCase, and Ant. The easiest way I have found to share projects is to include the .project, .classpath, and build.xml files in the top level of the project in ClearCase. Then when you create your view, mount it in your Eclipse workspace, and do a File -> Import, then choose Existing Project from the popup. Browse to the top-level of the project in the view and import it.
The paths in the build.xml and .classpath are relative from that point down, so it doesn't matter what the absolute path is up to the project. For example, your build will define your source directory as something like ./src/java, test directory as ./test/java, etc. Whether your absolute path is c:\workspace\project or /home/someuser/project or whatever doesn't matter to your build script.
What is the "correct"/better place to put eclipse's .launch files in a maven/gradle project? I want to commit my run configurations but I don't know where to put the files
I know maven and gradle are always about standarization so I rather ask than put them in a random folder and then get in trouble with some plugin
After creating a launcher on each maven module now I have each launcher appearing twice in eclipse. This is due to the fact that when I check out my multi-module project it creates an eclipse project for the top POM as well as for each child POM and all the files are "duplicated" in the Navigator view, once for the top and once for each module. This to me means that either I have some problem in my maven organization or that I am putting the launcher in the wrong place
Edit
Since I asked this question I learned of a new way to solve this. Enable an experimental feature in eclipse which will prevent the subprojects to appear in the top project. The setting is under windows/preferences/maven/Hide folders of physically nested modules
The standard location in Eclipse is in the project's root directory, that's where I always save them (and commit to SVN). Maven will ignore them there by default, so they will not show up in your artifacts.
One additional thing to keep in mind (since you mentioned that you want to commit the launch configurations to SCM and possibly share them with others): Avoid absolute paths in the launch configurations, since they will probably not work for other people. Try to use relative paths or Eclipse variables pointing to your local resources.
Edit: moved comment that answers the question
In this case you might consider moving them to a sub-directory (launch?). It should be one that is ignored by Maven by default (so not src/main/java or src/main/resources. On the other hand, I'm not sure whether Eclipse will pick up the files from a sub-directory... I've always kept them in the project root.
in my Java Eclipse project that contains JUnit tests, I also have a package "resource" that contains all input data used for the tests. But when compiling JUnit tests, the Java compile also data available in resources, so I find the same data in the "bin" folder. Is there a way to avoid this?
thanks.
If you have a particular package within the source path you want to exclude (your resources folder for example), you can right click on the package and select: Build Path > Exclude.
This will tell Eclipse that you don't want to include that package as part of the build.
This is making a couple of assumptions: that you're using Eclipse Helios (because the option might be different in older versions), and that the resources are stored in the same folder as your regular java source files (because if resources is in a folder by itself, you can remove that entire folder from the build by using Build Path > Configure Build Path -> Source tab.
Update:
After the discussion in the comments regarding why you would or would not want to copy resources into the bin directory:
The contents of your bin directory should be ignored and not checked into to a version control system (when using CVS, bin should be an entry in the .cvsignore file)
The resources are only duplicated on your local machine, which is fast and hard discs are big. I'm not sure you should be worrying about this
If you're using Class.getResource to access those resources, they need to be on the classpath somewhere. The bin directory is as good a place as any
So, realistically (barring some unknown, like the files are hundreds of gigabytes or something), I don't think you need to be concerned about excluding these files from the build.