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.
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've created a Maven project in Eclipse on one PC, pushed it to Git, then deleted the local files, and then cloned it from GitHub again.
However, now all those empty folders which used to house tests, resources, etc, are gone.
Should I be worried about that? Is there some Eclipse shortcut which ensures a project conforms to the expected Eclipse structure, or should I add those directories myself?
Add them yourself. The project structure you need is a characteristic from Maven, not from Eclipse.
I do not know if these directories being missing will confuse Eclipse / Maven. I do know that, generally, build systems are smart enough to create missing directories.
However, from a Git point of view, you can force it to keep these directories by simply adding a file to them which is always present in your repository. Common examples of this are creating a "README" or a ".gitignore" inside the directory.
See this question for potential solutions:
How can I add an empty directory to a Git repository?
I'm trying to make modifications to the trunk found at https://wafle.svn.codeplex.com/svn SVN repository location. The way that I did this in Eclipse was that I used Subclipse, added a new repository location, then opened up the project and right clicked on the trunk. Then I clicked "checkout" and checked it out as a new Java project. Then I found the folder containing the source code that I want to change and recompile and I used Build Path->Make source folder. Next, I realized that I needed 190394994 jar files that were all in different places under the project's "Third Party" folder. So I used Build Path->Configure Build Path in Eclipse, then individually added each jar I needed through "Add External Jars".
My question is; did I do all of this right, and is there something I could have done more easily, such as import all the jars at once instead of individually clicking each?
Thanks.
I'm guessing that you are embellishing a little and didn't add 190 million jar files by hand. (Even at 1 jar click per second, you would be going nonstop for 2,200 days.) Incidentally, you can shift-click and choose many jars from the same directory.
The secret is in the .classpath file; that is where the build path is stored. Someone before you has probably created a fully-orbed .classpath file and stored it in SVN.
If you created this as a new Java project, it will begin with a very simple .classpath with the folder for your project's class files and the JRE. (Apparently, SVN does not overwrite it with the .classpath or you chose not to merge your local version with the one from SVN.)
Next time, you might want to overwrite your project's .classpath with that fully-orbed one on SVN. Refresh and look at the Build Path. They should be all there and in place.
First thing: rajah9 is exactly correct - there is a .classpath file already.
You just got a little hung up on a really odd svn repo layout. the java stuff is mixed in with the .net stuff. Check out the trunk and then do a file > import... then select general > existing projects into workspace. You'll want to select the Source/JNAWindowsAuthProvider/ folder.
There is already a .classpath that references the jars in the ThirdParty folder. (not quite 190 million)
Second thing: when you added the jars as external jars, it makes an absolute path to the jar file. you want to always avoid that, if you hit the add jars button it will be a relative path.
I'm working on a Java Netbeans 6.7 roject with a few developers and we're using Mercurial for version control. I was wondering what I should put in the .hgignore file (ie. what files should not be added to the repository). I know I will definitely want the src, test, and lib folders in the repository and the build folder to not be in the repository. But I'm not sure what to do about the nbproject folder.
You must ignore the following folders: build (or nbbuild), dist (or nbdist), and the nbproject/private.
And if you want others to open it with netbeans (as you do in netbeans) you must add nbproject folder.
Though nbproject/private should be ignored, nbproject should be
checked into the version control system.
If you want more information, see netbeans help on http://netbeans.org/kb/docs/java/import-eclipse.html#versioning
If you have created these projects under an existing clone/repository, the NetBeans/Mercurial integration will already have a good idea of what to include or ignore.
NetBeans will automatically include files in nbproject that are considered to be environment independent. Files that include environmental dependencies (like directory paths) are usually placed in nbproject/private directory. You probably do not need to save those to your repo.
You may want to exclude the nbproject/build-impl.xml... it is generated when the project is opened... But, if you do not have it in your repo you will run into problems if you attempt to build the project with ant, independent of the IDE.
Anything that can be generated from what you check in should not be in the repository: no .class, .war, generated .jar, etc.
I have checked out a bunch of java code using subversion 1.6 and then I imported those projects into eclipse. Subclipse 1.6 picked up the fact that the plugins are under version control, except for a few folders.
I now get a bunch of errors like:
The resource is a duplicate of
src/.svn/all-wcprops and was not
copied to the output folder
If I delete the project (from eclipse not on disk) and reimport it, that fixes the problem about half the time. But since I have dozens of projects that are having this problem, it means reimporting them 10-20 times before I get them all working. This is very painful, and I am tired of doing it every time someone adds a new plugin to svn or when I need to recreate a workspace for some reason.
Is there an easier way to fix this than delete and reimport? Or is there a way to prevent this problem in the first place?
Add the .svn folder to the Excluded list for your Source Folder.
Project->Properties
Java Build Path
Source tab
Select 'Excluded'
click
Click next to the Exclusion patterns section on the bottom
Add the .svn folder and any others that do not need to be copied to the output directory
Follow the procedure described by Kelly but define the exclusion pattern as **/.svn/*. This will recursively exclude all .svn directories from the various source folders.
This is happening because you checked out a project using an SVN client other than Eclipse and then imported the project in Eclipse and you haven't notified Eclipse that this is an SVN project (that is, Eclipse doesn't know it has to ignore the SVN meta information).
In order to fix this properly, after you have imported the project in Eclipse, have Eclipse be 'aware' of the SVN nature of the project. Do so by
Select the project and go to the Team > Share section.
A dialog will appear asking weather this is a CVS or SVN project. Select the later.
It will prompt for the credentials, enter them.
When you're done, do a clean build. The problem goes away.
Easier way to do this is:
Project > Properties
Resource > Resource Filters > Add...
Filter type > Exclude all
Applies to > Folders
Check All children (recursive)
File and Folder Attributes > Type ".svn"
Hit OK and OK again
Clean/build
------------ Simple way of filtering the output folder-------------
Window->Preferences->Java->Compiler->Building
Make sure "Filtered Resources" includes ".svn/"
The "accepted best answer" described the cause to me, but as my project was already shared, I 1. closed the project, 2. opend it again and 3. cleaned it. The .svn folder is gone and does not come back.