I keep myself telling me and others not to commit .classpath and
.project files and use Maven.
Somehow, Junior developers always ignore certain rules and commits those files and it's much better to have such files for newbies who can jump and start using the code.
Now from myside, I would like to try/do something. When I clone the repo, I will get .classpath and .project files and certainly they get modified in my system.
But I want them not to be committed and should always be ignored while
synchronizing with Git. So that my changes in local system doesn't
mess up with Git and Git changes of those files doesn't mess up my
local files.
How do I achieve this? Anyway to mark those files to be ignored in such a way?
If the .project and .classpath are already committed, then they need to be removed from the index (but not the disk)
git rm --cached .project
git rm --cached .classpath
Then the .gitignore would work (and that file can be added and shared through clones).
For instance, this gitignore.io/api/eclipse file will then work, which does include:
# Eclipse Core
.project
# JDT-specific (Eclipse Java Development Tools)
.classpath
Note that you could use a "Template Directory" when cloning (make sure your users have an environment variable $GIT_TEMPLATE_DIR set to a shared folder accessible by all).
That template folder can contain an info/exclude file, with ignore rules that you want enforced for all repos, including the new ones (git init) that any user would use.
As commented by Abdollah
When you change the index, you need to commit the change and push it.
Then the file is removed from the repository. So the newbies cannot checkout the files .classpath and .project from the repo.
Add the below lines in .gitignore and place the file inside ur project folder
/target/
/.classpath
/*.project
/.settings
/*.springBeans
The git solution for such scenarios is setting SKIP-WORKTREE BIT. Run only the following command:
git update-index --skip-worktree .classpath .gitignore
It is used when you want git to ignore changes of files that are already managed by git and exist on the index. This is a common use case for config files.
Running git rm --cached doesn't work for the scenario mentioned in the question. If I simplify the question, it says:
How to have .classpath and .project on the repo while each one can
change it locally and git ignores this change?
As I commented under the accepted answer, the drawback of git rm --cached is that it causes a change in the index, so you need to commit the change and then push it to the remote repository. As a result, .classpath and .project won't be available on the repo while the PO wants them to be there so anyone that clones the repo for the first time, they can use it.
What is SKIP-WORKTREE BIT?
Based on git documentaion:
Skip-worktree bit can be defined in one (long) sentence: When reading an entry, if it is marked as skip-worktree, then Git pretends its working directory version is up to date and read the index version instead.
Although this bit looks similar to assume-unchanged bit, its goal is different from assume-unchanged bit’s. Skip-worktree also takes precedence over assume-unchanged bit when both are set.
More details is available here.
Use a .gitignore file. This allows you to ignore certain files. http://git-scm.com/docs/gitignore
Here's an example Eclipse one, which handles your classpath and project files: https://github.com/github/gitignore/blob/master/Global/Eclipse.gitignore
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 want to know what files in a Maven project should be committed to git.
Am I suppose to perform a mvn clean before committing, or do I add certain files to the .gitignore file?
Personally I use Maven gitignore and Java gitignore for a Maven project. You might need to adjust it with the languages used in your Maven project.
https://github.com/github/gitignore/blob/master/Maven.gitignore
target/
pom.xml.tag
pom.xml.releaseBackup
pom.xml.versionsBackup
pom.xml.next
release.properties
dependency-reduced-pom.xml
buildNumber.properties
.mvn/timing.properties
# https://github.com/takari/maven-wrapper#usage-without-binary-jar
.mvn/wrapper/maven-wrapper.jar
https://github.com/github/gitignore/blob/master/Java.gitignore
# Compiled class file
*.class
# Log file
*.log
# BlueJ files
*.ctxt
# Mobile Tools for Java (J2ME)
.mtj.tmp/
# Package Files #
*.jar
*.war
*.nar
*.ear
*.zip
*.tar.gz
*.rar
# virtual machine crash logs, see http://www.java.com/en/download/help/error_hotspot.xml
hs_err_pid*
Is it good practice to perform mvn clean before committing, or do I add certain files to the .gitignore file?
Add rules to your .gitignore file first, which makes Git ignores the undesired files correctly. Understanding Maven standard directory layout will also help you better determine which are the undesired directories.
Is it good practice to perform mvn clean before committing, or do I
add certain files to the .gitignore file?
Executingmvn clean before committing is not practical at all. Developers can forget that and besides they should rebuild their projects at each commit.
The correct way is using .gitignore to specify files to ignored in the tracking. Just commit it and push into the remote branch and all developers could work with the same rules.
I want to know what files in a Maven project should be committed to
git.
You want to commit/push files that you want to version/track.
But it is very broad. You cannot have rules just for Maven. Maven have some specificities (target folder for example that you want to ignore) but you would have probably more things to ignore.
You want to generally commit/push the source code and application configuration files such as pom.xml or any configuration files used in your build but you can also add any other kind of files. For example committing a changelog or even a word document (more rare but possible) may also be valid.
Generally what you don't want to commit are files that :
depends on the developer machine (IDE, custom files)
created by a build operation (target folder in Maven but you could also have other folders according to your pom configuration)
temporary files using during the build, the application execution or still the release operations.
archives
Check this:
https://www.gitignore.io/api/maven
# Created by https://www.toptal.com/developers/gitignore/api/maven
# Edit at https://www.toptal.com/developers/gitignore?templates=maven
### Maven ###
target/
pom.xml.tag
pom.xml.releaseBackup
pom.xml.versionsBackup
pom.xml.next
release.properties
dependency-reduced-pom.xml
buildNumber.properties
.mvn/timing.properties
# https://github.com/takari/maven-wrapper#usage-without-binary-jar
.mvn/wrapper/maven-wrapper.jar
# Eclipse m2e generated files
# Eclipse Core
.project
# JDT-specific (Eclipse Java Development Tools)
.classpath
# End of https://www.toptal.com/developers/gitignore/api/maven
In general you should ignore all targets and metadata. If you ignore targets, mvn clean is not required before pushing.
I had a Maven project in VSCodium and had to decide whether to commit the .project file or not. That should be linked to in this Q/A since it happens with other IDE:s as well that have Maven extensions.
This is 2010, only for Eclipse:
.classpath and .project - check into version control or not?
which says overall that it should be committed. I guess the discussion is timeless. It is a Maven generated file, but it should still be in the repository, and even more, if the repository is at work with the same setup and tools by the team.
Other questions:
Should I keep my project files under version control? [closed]
Java project: should .classpath .project file be committed into repository? [duplicate]
The same for the .classpath. Even if it is made by Maven, it should be in the repo.
I am a beginner at Maven and only guess this. I cannot understand why this was not in this Q/A up to now. The accepted answer lists the ignored files, but from reading that, I was not fully sure what to do with these meta files from Maven. And there is even one answer that lists the two files as files that are to be ignored in this Q/A here. Which, as far as I can see from a repository I took over, and guessing from the accepted answer, is wrong: the two files belong to the version control.
I added Maven support to a project that previously did not have it. IntelliJ then moved all the java files, but even though it's a git project, did not use git mv and so there's no file history.
How do I fix this?
Example:
//The below structure was before Maven
/src
.../com
.../test
.../SomeClass.java
//After Maven
/src
.../main
.../java
.../com
.../test
.../SomeClass.java
Renames are not first class citizens in Git.
Git detects renames based on file content changes.
As such, the main purpose of git mv is to simplify staging.
If files get renamed without git mv,
that causes only a minor inconvenience,
which you can rectify by appropriate git add commands.
That is, for each renamed file, one git add for the old name ("deleted file" from the perspective of Git), and one git add for the new name ("new file" from the perspective of Git).
In your particular example,
a simple fix could be staging everything by running git add . at the project root.
After that, check the output of git status -sb.
There's a good chance that Git will figure out all the renames.
I want to checkin a Dynamic Web Project I created in eclipse into svn. Can someone tell me which files I have to check in and which one I should not? The idea is to be able to check out the project using the New Project Wizard so that I can create the Dynamic Web Project again. More specifically here are the files/directories I have in the project --
src
WebContent
build
dist
build.xml
.project
.classpath
.settings/
The build directory is not supposed to checked in obviously. What about the other ones?
I am guessing all the . files should not be checked in either. Can some one verify this?
What is this dist directory and the .settings directory?
Also where does eclipse store the Server information (tomcat)? I don't want to check it in either.
EDIT:
I initially checked in all of the above except the build directory of course. When I checked out the project from inside Eclipse it did not prompt me to create a new project since the .project is there but Eclipse was creating a JavaEE project or something instead of the Dynamic Web Project. Did anyone else run into this behavior?
** EDIT 2 **
Found it! Turns out I should not check in the following --
.project
.settings/
.classpath
Once these 3 are removed the New project Wizard works as expected and everything is fine.
If you check in .classpath/.project/.settings you make your project Eclipse-specific. What about developers who work with Netbeans or IntelliJ? IMO it is cleaner to keep your project IDE-independent and easy to set up.
I usually go for a Maven build. The pom.xml specifies all the required dependencies and mvn eclipse:eclipse generates the .classpath/.project files for you.
The .settings directory contains local settings (like which Java version you want to use). IMO it is not useful to check this in. You can enforce Java version compliance via the Maven2 pom.
Finally, for your next project, my protip is to svn-ignore the files or directories you don't want in SVN before your first commit. In a Maven2 setup that would be .settings .classpath .project target (the default output directory of Maven2) and any other generated stuff (log files, gfembed directories, etc). In your case you would ignore build and dist instead of target.
You can svn-ignore files or directories with RIGHT_MOUSE->Team->'Add to svn:ignore' (I use the Subclipse plugin). Ignore instructions are stored as svn-properties on the parent directory. The properties on a directory can be viewed by RIGHT_MOUSE->Team->Show properties. You can also edit the properties directly there by clicking on the value field. Make sure there is an end of line after each property.
Now that you have already committed and then removed these files, ignoring is not going to work anymore in my experience. Somehow I have never managed to successfully ignore generated files which have ever been checked into the SVN repository; they are like zombies, always coming back from the dead. Maybe by deleting their entries physically in the SVN repo this can be achieved, but I've never done it.
In our case, we have checked in all you mentioned in the list except, .settings/.
With .classpath and .project checked in, users can quickly check out the project and fire up Eclipse on a new computer and just start working on it; the alternative being to configure the project manually and adding in all the jar dependencies painstakingly (if you use ant). Many open source projects do this.
Read this, there are some really good points to ponder about.
Good Question... Many of us are in a dilemma on whether we want to check in IDE related files or not. I normally go for checking in .classpath for eclipse and I use eclipse variables to make sure that team needs to just change the variable value and it works. We also check in .project so that team need not to create new project in their workspace.
I would omit the .project, .settings/, dist, and build.
The .classpath can be left in if you use variables instead of hardcoded paths. This is useful so you don't have to rebuild your classpath every time you check out the project.
I'm working on a uni project with a few other people using SVN. Much to my annoyance the .project file was removed from the repository since "it contains platform specific information". However, this has obviously broken my setup in Eclipse, giving me the error:
Problems occurred opening the selected resources.
The project description file (.project) for '_________' is missing. This file contains important information about the project. The project will not function properly until this file is restored.
Any suggestions? Thank you.
Simply revert the project to a revision that featured the .project file, then put in .svnignores and to back to the current revision again. Or even simpler:
svn cp -r15 .project .project
Where the number after -r is a revision featuring the .project file.
.project files don't belong in an SCM, they contain developer-specific information. Common configuration belongs in some standardized file like (e.g.) a maven pom.xml, from which a .project file is automatically generated, but things like .project, .settings, .classpath should always be in svn:ignore, which means you can keep your own copy without overwriting others
That should be easy - checkout an older revision of the project where the .project file is still available, to a temporary location and copy this old version of .project to your actual project folder. You can use the Navigator view which is more convenient for this special copy'n'paste task. (Or do it on the file system outside eclipse)
Once the .project file is back in place you can continue to work as usual.
Alternative: create an empty java project, copy the autogenerated .project to your active project and reconfigure that project.