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.
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 have a locally stored jar file that I believe I need to generate the sources in order to consume it in my project.
I am using JDK 8, IntelliJ and Maven 3.5.2
I have installed the jar file into my local .m2 folder.
Perhaps I am missing a goal in my maven lifecycle or a plugin?
Not had to use a local jar dependency before so any help appreciated (I'm a tester not a developer)
I've attached a screenshot (apologies for all the obfuscation of package names that I feel might be commercially sensitive - possibly overkill!)
Note the red underlining in the src test....folders where the classes cannot access those within the jar dependency.
I have added the dependency within the pom.xml file also and it shows no errors.
I feel I should have run something like -Dsources=target/mycool-project-3.0.17-SNAPSHOT-sources.jar when using the mvn install:install-file command (which I used originally when installing to my .m2. However I tried this with no success.
Or maybe I need to mark the resources as a root within IntelliJ
Currently in Project Structure -> Libraries I see:
Android Studio recommends using the gradle wrapper in the build work flow. However, if you are using git for version control, .jar files are ignored and are said not to be checked in, which I get. But my workflow is a little different than the average person. We are also using Team Foundation Server and git both. The gradle build gets called using a custom MSBuildTask. Here is what my .gitignore file looks like:
# Built application files
*.apk
*.ap_
# Files for the Dalvik VM
*.dex
# Java class files
*.class
# Generated files
bin/
gen/
# Gradle files
.gradle/
build/
# Local configuration file (sdk path, etc)
local.properties
# Proguard folder generated by Eclipse
proguard/
# Log Files
*.log
The way it currently works is first we pull both from TFS and our git repo into a common location, then we merge the two, check the result back into TFS and push the result back to the git repo. After this is complete, the custom MSBuildTask is executed which basically just calls "gradlew build". However, this fails because the gradle-wrapper.jar file isn't being pushed to git, its being ignored. Any ideas on how to accomplish this? Thanks in advanced!
As Peter mentioned, jars are not ignored due to your .gitignore file; I guess the jars are ignored due to a .gitignore file located in a parent directory of your project directory. Can that be the case ?
Anyhow, if that is the case, you can try using a negation in your .gitignore file, something like:
!**/*.jar
In that way, you override rules from a .gitignore file in one of the parent dirs.
I'm trying to set up a build for my team on a Jenkins box. They are using a product whose documentation says to drop 2 jar files and a .properties file in the $JAVA_HOME/jre/lib/ext directory.
Since this Jenkins build box is managed by another team and houses many builds, I feel that it is a bad idea to tell them to install these files on all the slaves that may build this project. (especially if we were to need to upgrade/change settings/etc.)
Is there a best-practice for managing this sort of thing?
Things I've tried so far:
Installing it in the $JAVA_HOME/jre/lib/ext == works.
Installing the jar files in the maven repo and dropping the properties file in src/main/resources == doesn't work (it looks in $M2_REPO/PATH/TO/JAR/jarname.properties)
If it is really necessary to deploy than into lib/ext, the easiest way would be to provide a custom jdk for your build (call it Java6_With_MyProduct), in which you provide the zipped/tar'gz'ed) jdk.
Ask your administrators to include it into the Jenkins configuration.
That way, YOUR (and only your builds) would get your extended jdk.
Alternatively, you could use the -Djava.ext.dirs system property to override the extension directory. That way, your would
copy your extension into your workspace as a prebuild step
copy the original extensions from $JAVA_HOME/jre/lib/ext into the same directory
set -Djava.ext.dirs=$WORKSPACE/myextensions as MAVEN_OPTS (only if the extension is required to actually BUILD the project)
add -Djava.ext.dirs=$WORKSPACE/myextensions to the argLine for surefire and failfast plugins
The open question is: do your really need those extensions to BUILD your project?
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