In our Eclipse plugin are we managing some resources using navigator. For every folder in the navigator Eclipse is creating an .project file which leads to some problem in the code under resource management.
One way is to filter .project file pragmatically. But I wonder if there is a configuration or setting in Eclipse to prevent creation of .project files for the maps under navigator?
.project files created by Eclipse IDE is essential cannot be prevented from generation.
For Further information please refer to documentation at Eclipse Documentation.
EDIT:
The workaround would be to create a project in your workspace and then create a linked folder to the resources you want to scan that are somewhere else on the file system.
Don't try to delete the project meta data. That will lead to more trouble afterwards than simply configuring the team API to ignore the .project files during all version control operations. That .project file contains meta information from all plugins, not only from yours.
Depending on the VCS used, you should just create a default .gitignore, svn:ignore, or whatever you need.
Besides that, I would simply call it a bug in your plugin that it tries to do something with that file. It simply should not do that. Other plugins will create other files in the projects and you should not try to handle each and every file, if they don't belong to your plugin. The JDT plugin also knows which files to compile and which to ignore.
Related
Should I put .classpath, .project files and .settings files on SCM when working with Maven project with m2eclipse plugin? Theoretically every developer can grab the sources and import maven projects.
Due to your experience is it better to do this that way or to put Eclipse files to SCM too? Some developers are using InteliJ so I don't want the projects to be Eclipse specific. It seems that the .project file may change according to the set of installed plugins, e.g. change buildCommand from org.eclipse.jdt.core.javabuilder to org.eclipse.wst.common.project.facet.core.builder etc.
Please share your knowledge and experience.
In my experience, you should not include .classpath, .project or .settings. All the information needed to re-import the project is in the pom file, so long as you use "import existing maven projects".
If you put all those local ones, you are likely to end up having SCM changes for irrelevant things, such as different order of entries, local modifications someone made to their project preferences, etc...
As per my experience , it is safe to check-in .project file as it defines the nature and other properties which is useful for developers who will be creating new workspace. Many times, custom facets needs to be added via Eclipse and you may want to share it with other members of your team provided all others use the same IDE for example RAD.
They won't have to go through the pain of again setting and changing project nature, so it might help. Even we had to share our .settings folder in most cases because ppl were facing issues with workspace setup. So all depends on the need and it might help.
One situation in which it is very convenient to have Eclipse project files under version control is when you have Java code automatically generated by plugins. Eclipse removes missing source directories from its configuration before code generators run.
UPDATE
With recent Eclipse releases (I'd say since Juno, certainly since Mars) this is no longer the case.
Over the years the m2e plugin was greatly improved and nowadays there is really no need to store project settings in your SCM, as these settings are properly recreated from the project POM. This has the added benefit of allowing the use of different Eclipse releases with the same project.
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.
When I commit a web appliction to source control should I also include the .project & .classpath files ? I don't think it should make any difference either way as other users who use the project should have the same project settings ?
This is the sort of question that gets people bent out of shape in a debate that never ends. You basically have two camps:
Only put source code into the source control system. Each developer chooses their own IDE and manages their own project configuration. Setting up your IDE after getting source code from the repository will be tricky. If one dev changes project dependencies, they have to explicitly communicate that so that all other devs update their project configurations. There are some tools that try to address this problem, like a Maven plugin that will attempt to generate Eclipse project metadata from pom.xml, but all have their limitations. Groups that go this way favor the purity of not restricting developer choice in IDE over the convenience of having Eclipse projects across the team that just work.
Standardize on Eclipse. Put all Eclipse project metadata into source control. This includes .project, .classpath and the entire contents of .settings. Basically, the only thing that you don't want in your source control repository is content marked as derived in Eclipse. You can check that in right-click->properties. Taking this approach ensures that developers can get started coding immediately after getting the project from source control. No additional configuration required. Also, when one dev changes project configuration, the rest of the team will see the same change on next sync.
Choose the approach that makes the most sense for your team.
For ClearCase, including the .project and .classpath can make a difference when you are using the IBM ClearCase plugin for Eclipse.
That plugin will work better if it can rely on those (versioned) files being there, right next to the sources (as opposed as being in the Eclipse workspace, which doesn't necessarily contains said sources).
In general, nothing generated should go into repository. Those files are generally generated by IDE or maven. However, sometimes you may need to click a button or execute a command to get those generated.
i would include them.
The .project file have plugin info (e.g. maven, ant, pdt, wst, aspectj, findbug..). It is essential if it is not a plain java project.
.classpath contain the classpath. it is needed if you use jar files.
I would say that all files - including .project and .classpath - should go to source control, to ensure that everyone in the team has the exact same setup.
I created an Eclipse project and now I want to put it on my SVN repository. Which files should I put on ignore list? There are many files that I don't know what they are used for. There are folders like .history, .root, .safetable, .log, .settings ... and many .index files, also some .running files. Can I put all that to ignore list? Do you know which extensions/folders can always be on ignore?
Thanks.
The answer is very dependent on your project. Committing the source is a good thing however it'll force new developer to recreate the project environment which can be painful. If you are using Maven with the m2eclipse plugin committing only src and pom.xml is a good approach as it only takes a few minutes to recreate the Eclipse environment from src and pom.xml.
On the other hand it is ok to commit .classpath and .project but that also means extra work such as never using external jar directly but through variables or user library, etc.
If you have time to experiment, why not check in everything, have a colleague check out the project, and see what throws up errors? Anything that references paths outside the project is likely to fail if your colleague doesn't organize her harddrive the same as yours. Those things should be changed to reference variables, or not placed under version control.
Let your colleague build the project, run the IDE through its paces, and then sync up to the repository to see what changed. Files that are volatile, run time logs, and temp files should be omitted. Anything that makes it easier for another developer to setup the project and get running should be included. Taking time to experiment will help you gain a better understanding how your project is setup.
Basically, you want to avoid checking in anything derived from source (like .class files in a Java project) or anything that every developer would have to change for their local environment, like a file with absolute references outside the project directory. One approach I have used in the past for handling configuration files that require customization by developers is to include a copy of the file, usually with extra comments, with a .example extension. Make it clear in a README or other documentation which example files need to be customized and what the "real" name for the file should be. Also include he "real" file name in the svnignore list so it doesn't get checked in and overwrite everyone's local customizations.
To address your specific examples:
.history, .root, .safetable, .log,
.settings ... and many .index files,
also some .running
.settings is one you'll have to experiment with. If you have settings, such as code style or formatting guidelines, that all developers need to follow, then it can be handy to have those under version control, but some other settings may not be appropriate for all developers. The other examples are not familiar to me, possibly because they are associated with a type of Eclipse project I don't work with.
My first guess would be that any file whose name is starting with a dot should not be versioned. Most commonly such files refer to Eclipse settings which are not project-relevant.
Now, the .project and the .classpath files, in a Java project, are quite "project dependant" and I usually include them.
To get a more precise answer you should specify which project type you are working on.