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.
Related
I have a netbeans project that is under mercurial. What I would like to do is to strip down everything that makes this project netbeans project to only to leave code in there so that I can easily import it in say eclipse.
Is there some automated way to do this or do I have to remove manually this?
What approach would you recommend.
Cheers
You only have to add the nbproject folder to ignore (= don't check in). All NetBean-settings are placed in this folder. Dont check in the build and dist folder as well, because these contain the compiled code (but they are ignored per default).
The best way to do "IDE neutral projects" is to use Maven !
In NetBeans when the project is Maven-based (as opposed to Ant-based) you'll see that all those NetBeans-specific files that you normally see in nbproject folder are just not there. The nbproject folder doesn't even exist. The reason is that for a Maven-based project NetBeans essentially uses the pom.xml as the definition of the project and that's a good thing because the POM is portable and directly understood by other IDEs.
Even for a Maven-based project NetBeans will still store some IDE-specific stuff in a file called nb-configuration.xml but you can include all of the contents of this file as properties inside the pom.xml. These properties will then be ignored by other IDEs when they load the POM. This way you can pretty much avoid altogether to check any IDE-specific files into the VCS. Also it is worth mentioning that the stuff in nb-configuration.xml is never needed for someone else (using NetBeans or another IDE) to be able to build your project. Another way to put it is that it contains non-essential data. The POM - by virtue - is always guaranteed to be a complete description of how to build the project.
Contrary if your NetBeans project is Ant-based then at least in my experience you cannot avoid checking NetBeans specific files into the VCS ... because otherwise even those using NetBeans won't be able to correctly open your project.
However even with Maven there's one area where you'll be forced to have NetBeans-specific files in the VCS and that is if you use the Matisse GUI builder in NetBeans. The Matisse GUI builder produces some proprietary files with .form extension and you really need to have those in your VCS. But this is the only example I can come up with where NetBeans-specific files will need to go into the VCS assuming your project is Maven-based.
If the project indeed is Maven-based and you still feel that there are NetBeans-specific files that you need to have in the VCS then let us know exactly which files you're thinking of. Then we can take it from there. :-)
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'm looking for advice regarding best practices for sharing an Eclipse project among developers.
It seems clear to me that each developer should have his/her own Eclipse workspace. However, projects seem to loan themselves better for many users to use the same project, e.g., if several users are working on a particular component, they are all likely to need to use the component's project, since if they each had their own project, they'd each have to set up and maintain the same project dependencies, etc. Looking to see if this is what other folks do or if their are reasons to give each developer his own project for a particular component.
Also, if the recommendation is to share a project, what are recommendations for configuration managing an Eclipse project? In the past we have used ClearCase, but we are now looking to change to Git or SVN. In the ClearCase world, it would seem advisable to do frequent checkins and merges to help the team stay up to date. Again, I'm looking for opinions from folks who have already lived this.
Thanks for any recommendations or external "how to" books or websites!
Thanks,
Ken
Sharing an Eclipse project doesn't cause any problem. Just put the .classpath, .project files and the .settings directory (and any project-related config file/directory that Eclipse generates at the root of the project) under source control.
Also, avoid using absolute paths in your project (for external libraries, for example), since all the developers don't necessarily have the same setup and use the same locations.
Git, SVN or ClearCase : it doesn't matter : all allow sharing Eclipse files.
We put the entire eclipse project folder under version control (with an svn:ignore for the directory containing the compiled classes).
This allows us to share not only the build configuration, but also launch configurations (with the proper VM-parameters), the configuration for compiler warnings the team considers relevant, and the formatter configuration for the coding conventions in use. We can also set text file encodings that way.
...avoid using absolute paths in your project
Good point.
We've had some issues with this in ClearCase. Our third party libs were placed in a different part of the filesystem under version control. So to avoid absolute paths to the libs we added an ant script. The script would copy the libs to a view private directory that was directly under the project root.
We then added a builder to the project to make sure that the script was run first at every clean + rebuild.
What Eclipse specific files should I add to the VCS (Subversion, GIT, etc...) when sharing an Eclipse project?
What I have here:
.autotools
.cproject
.project
.settings/
Just stumbled upon this and had the same problem some time ago, so I will try to share my experience.
First it depends on who are the other users of the VCS or better what programs they will use. If they do not use Eclipse these files will only pollute their projects.
If they do use Eclipse the files might be of use to them, but in my latest project I did not include them for the following reasons:
Everyone had another system which meant other paths for the includes and so on. Concluding from this I surveyed the contents of these files to see if they should be used:
.cproject: The includes are listed here, so you will have different files in the list on each platform. -> leave out
.project: Found some environment dependent paths here too. Maybe it also has a problem when there are different plugins installed. -> leave out
.settings: It might make sense sometimes to share the settings but usually it is each developers own decision. -> leave out
.autotools: I did not use this, so I cannot say anything about it.
Summary
It seems best to leave those files out of the repository.
For Eclipse this introduces the problem of creating a new project when importing from the VCS. In this case you should give advice on how to configure the project to set it up correctly.
When you put the project files into the VCS those who do not use Eclipse will probably have less problems than those who do, because the files are simply ignored at their site while the Eclipse users will have to reconfigure them for their system.
Maybe there is some better way to share those projects but I did not find one yet.