I have a Java project I'd like to commit to my SVN repository, created with eclipse.
Now, what files (aside from the source code, obviously) are necessary? In the workspace root, there is a .settings folder with many files and subfolders, and inside the project folder there are two files - .classpath and .project, and another .settings folder with a single file - org.eclipse.jdt.core.prefs.
Which of these files should be committed to SVN and which can be safely excluded?
They're all useful if you want to have consistent settings across your team.
.classpath and .project mean everyone can get up and running with a project just by importing it. Any changes to the libraries and source files included in the project will be picked up by everyone when they're checked in.
The .settings directory has things like code formatting options and what the compiler considers as warnings, errors, or OK. For consistency, I've started checking these in as well (as long as everyone on your team can agree to a standard for formatting, I guess).
I've found that the biggest limitation in sharing things across version control in Eclipse is in the library definitions. Library definitions seem to be only stored on a per-user basis, so if you reference a "library" in the .classpath file, every other user has to manually define the contents of that library (or manually import your exported library definitions file).
Edit: (Addressing #mliebelt's comment below)
You'd only commit .settings files if you're trying to keep consistency/standardisation between developers. If that isn't an issue for the project, then not committing .settings files is one less thing to worry about maintaining. Files that are specific to an individual's favourite plugin(s) probably don't need to be committed either (although I don't think it would hurt if they were, would probably be ignored?).
The two most common ones I've found worth committing are org.eclipse.jdt.core.prefs and org.eclipse.jdt.ui.prefs, which are core to any (Java) Eclipse project.
You can exclude the .settings folder, but the .project file will be useful to other developers who want to reconstruct the same exact Eclipse project. If you examine the file it should only have relative references (if it doesn't, you should modify it as such.)
In contrast to the other answers I've made better experiences with not checking in the .project file in large open source projects that I work with.
You may disagree with me, but there is one problem with shared .project files: They contain references to the project natures used in the project. The project natures again depend on the plugins installed on the local developers machine.
Example: If you use Findbugs on a Java project, a new nature gets added to your Java project. Checking that file in, modifying it on another system (with no Findbugs installed) and afterwards using it on my system again has led to the Findbugs reference being lost for me (and therefore all Findbugs checks being removed silently).
But if you can have all of your developers agree on using the same tools, then you may be able to work around this problem easily.
Related
I have a Maven project. After I make changes to the project, I package the project up into an Uber Jar file and upload that to my backups. I am wondering, if my computer were to break or I lose all the code to the project, can I get the project back using only the Uber Jar file or would the project be gone forever?
How can I open this Jar file as a project and view all the Java code inside of it?
It would be entirely gone; that jar file contains only class files, not your source files, and you can't 'recover' source files from class files (you can decompile them which is mostly useless for this purpose; all comments, most names, most structure - all gone. You can't feasibly continue your project with this).
As it isn't in there, it's not possible to 'open a jar file and see all java code inside it'.
You'll need to set up backups.
The proper way forward is to first set up version control; this ensures that you don't just have a backup of the latest state of your source files, but every state of it - you can travel back to any time. Protects against code you deleted by accident, and means you can freely remove code you think you no longer need without that nagging feeling of: Yeah but what if.... maybe later? - so stop commenting out stuff you don't need, just get rid of it. It also means if there's a bug, you can time travel to the exact point in time when you added the line, and you can review the changes made by others in a project (presumably you're writing this on your own for now, but at some point you'll work with more people than just yourself!)
Read up on git which is the version control system that 80%+ or so of the community uses, probably best not to spring for exotic options if you aren't familiar. There are a billion tutorials out there to find if you search the web.
Host your git on a site like github or bitbucket which therefore also takes care of backups. Alternatively, host it on your own server (it's not complicated; git is open source). If you can't do that either, just let git write to a local directory and then use e.g. backblaze or something similar to ensure that file is backed up.
Yes, you can view your code by using a decompiler. I have experience mostly with IntelliJ, and this IDE includes a decompiler of its own. In case you lose everything and have only the jar file. You can use this included decompiler to get your source back from your .class files. But instructions on doing that are a story for another question...
If you want to secure your code use GIT. A version control tool that is a must when it comes to programming. Google about it and after a few days of playing around with it, you will never worry about such things.
Right-click on your project.
Select Build Path.
Click on Configure Build Path.
Click on Libraries, select Modulepath and select Add External JARs.
Select the jar file from the required folder.
Click and Apply and Ok.
The IntelliJ 2017.2 documentation suggests including the .idea folder that contains that IDE’s own configuration files (excepting the workspace.xml and tasks.xml files). I can understand the sense in this, as I could incorrectly configure the project settings and want to revert.
Yet, I want to post this open-source multi-module Maven-driven project to BitBucket for public access. Obviously, not everybody uses IntelliJ as their IDE, so I do not want to force my IDE settings on them.
➠ How do open-source authors resolve this conundrum?
My suggestion that comes from experience is to always explicitly ignore (that is, add to .hgignore or .gitignore) IDE configuration files or directories.
It is not only a question of not spamming a project with configuration files for a specific IDE. The real problem begins when more that one person uses the same IDE. Depending on the IDE and on how it is configured, you can fall in a situation where each commit contains changes to these files, and will confuse all the other developer using the same IDE, which in turn will overwrite the changes again in a infinite loop.
Some of your IDE settings will be global and stored in your home directory. The ones that are project specific will survive as long as you don't change the local directory in which you cloned the repo. If you change directory, in my experience it is always tolerable to reconfigure the IDE. There are at least two situations when the local directory changes: (1) you remove the directory and clone the repository again (2) you use more than one computer.
If you are concerned for things like coding style, then the best approach is to use a command-line formatter tool that works for any editor or IDE. That tool will have its configuration file committed in the repo, since coding style is something that should be equal for all developers and files of a repo.
I check out a java project from svn repository include .classpath and .project files. And I import these codes into eclipse. But the eclipse will modify the content of .classpath file. How can I stop eclipse to do this? just write off build automatically option?
You can't. But instead of putting a JAR on the Java build path you could
choose an execution environment which should stay stable when you change
the JRE and hence the .classpath file will not change either.
.Project and .classpath files should not be checked in under svn repos.Blindly copying such files from one machine to another may be risky. These are the files that eclipse automatically constructs for you as per your project structure. If you want to edit, you can do that.
Here is the nice explanation What's in an Eclipse .classpath/.project file?
Adding information to a 2-year old question just in case of any one else is stumbling across this.
Due to insufficient detail in the original question, I am guessing that the problem experienced is due to the project's classpath pointing to a different location on the questioner's machine as on the original project author's machine. When a project uses 3rd party libraries (JARs) and is shared between different team members (as hinted at by the use of a version control tool), this is a common occurrence.
A solution to this would be to have all team members set up the location of the directory containing all 3rd party JARs to have an identical structure on all individual machines. So instead of changing the classpath, change the directory structure to that required by the classpath.
Unfortunately this is not always the best solution:
Team members may have different operating systems (Windows vs Linux) and you will not be able to have a (absolute) class path that works on all platforms (e.g. C:\libraries\3rdparty.jar vs /opt/libs/3rdparty.jar)
Team members may differ in how they prefer to organize their directory structure. Especially, if a team member places libraries into his home directory (e.g. C:\User\abcd\libraries\3rdparty.jar or /usr/abcd/libs/3rdparty.jar), another team member will struggle to replicate that directory structure.
Eclipse provides various methods to set up a project so that it can easily be shared between team members. These however require team members to all agree on the convention, and will be slightly easier if set up by the original project author right from the start. Two methods most commonly used:
Add all third-party libraries to the project itself (the usual convention is to have a /lib directory inside the project for this - on the same level as /src and /bin etc.). The classpath can now be set up to be relative to the project's root and thus usable across different setups. A variation for large multi-project-file projects would be to have a separate eclipse project containing the libraries, then add it to other projects as a dependency ("Required projects on the build path" in the "Java Build Path" dialog).
This has the benefit of being able to version control your JARs too. However, it may use up a lot of extra storage/bandwith, so may not always be desirable. For instance, I would not do this with Java Enterprise Edition JARs contained in my preferred Application Server distribution, as I may want to migrate my project in future to a new version or another product, without such dependencies - I also do not want to have my project saddled with duplicate JARs that are in any case already available in the AS distribution. So you need to think through your requirements.
Eclipse also provides the concept of a classpath variable. This may be set up to point to the root of a team member's JAR-containing directory, and be extended with subdirectories and filenames inside the classpath. This needs to be done only once, and is also accessed via the "Java Build Path" dialog.
Whenever a new team member uses the project for the first time, he needs to configure eclipse (once) to point that variable to the relevant path on his own machine.
The above mechanisms are explained in more detail on various web pages, here is one reference: http://www.informit.com/articles/article.aspx?p=367962
This question already has answers here:
.classpath and .project - check into version control or not?
(7 answers)
Closed 4 years ago.
Should I check in my .project and .classpath files?
My friend told me that I should only check in .java files and the build.xml to guarantee portability. He said ".classpath will cause you much less portability on different environment. .project is entirely your local eclipse setting"
I agree with him, but partially.
-- Not checking in .project file will make my development less efficient (I can't simply "import" a project code from a directory)
-- Not checking in .classpath file seems OK to me (?) if my build.xml is written carefully.
Anyone wants to share their experience here?
There is nothing wrong with checking in .project and .classpath. I would do so, if your build.xml isn't able to create both of the files for you. As you said, it's uncomfortable to miss these files when you try to create a new eclipse workspace.
Before you check in .classpath you should be sure that there is no absolute path in it. Convert it into a relative one with a text editor.
Edit: Or even better, use eclipse classpath variables in your otherwise absolute pathes, like #taylor-leese commented.
For my 2 cents, I would rate it as a bad practice. Projects should not be tied to an IDE, and especially should not be tied to a specific version of an IDE.
Checking in Eclipse config files might work well for simpler and short-term projects. For larger projects that are developed over several years this will generally cause more hassle, as IDE versions change, and project config files don't. Just imagine checking in a 2 year old branch with Eclipse 2.0 config files in Eclipse 4.3 with some customized libraries and m2e integration... No fun at all...
One thing I would caution against with checking in .classpath file is make sure you don't reference files outside of your project. Eclipse stores the location of these files with a full filepath, and you would need to make sure other developers had those files in exactly the same place.
The key question with all such files is "Can they be reproduced automatically?" If not, check them into source control.
In this case, I'd say "yes," unless you're using maven, which has m2eclipse and the eclipse plugin to generate them for you.
I don't really know eclipse preferences files, but with IntelliJ, those files are OS agnostics, which means that it won't ruin your portability. Unless you define libraries with a full path to your system (That would be pretty dangerous/stupid).
When you share preferences, you're sure that everyone will work with the same conditions on the project (plugins configuration, encoding, profiles [for intelliJ]) which can really be a good thing.
It doesn't bother me when some Eclipse files are here, and I think it shouldn't/doesn't really bother other developers when some hidden files just lay there.
We check in .project and .classpath. With ProjectSet's this allows us to check out complex workspaces with a single "Import Team ProjectSet"
Not checking in .project file will
make my development less efficient (I
can't simply "import" a project code
from a directory)
for this issue, you can choose to create new project and import existing source.
one issue with IDE specific files like .project is that other Developers may want to use another IDE do develop the project, so they may add another type of project files. this will make your repo messy.
I would prefer to checkin .project and .classpath.
This would be helpful when this project is being shared by multiple developers. It becomes easy and faster to setup development env. by simply importing this as existing project on any system using eclipse.
Only caution needs to be taken here is classpath's are relative to project.
I often have a similar, more general questionning. The problem essentially is :
which files am I commiting for me?
which files am I commiting for others?
→ How do I combine both objectives of "versionning"?
I offered discussing this there, so you may find more details about the problem, along with interesting solutions :)
The one I like best is the use of git submodule: keep your .project files etc. in a private commit repo. And make your final, pure, essential src production into a neat submodule nugget: a public repo.
project/ # root module
| .git # private repo
| .project
| .classpath
| momsNumber.txt
+---src/ # submodule
| | .git # public repo
| | main.java
| +---package/
| | | Etc.java
See there anyway.
There is not problem of checking in .classpath and .project files into repository. It will help developers which use Eclipse to get going faster.
Warning: Make sure your .classpath file is referencing only artifacts which either checked into the repository with the project or can be obtained automatically (such as maven artifacts).
I'm a .Net guy and used to csproj/vbproj files being the central repository for all folders/files in a .Net project.
What's the equivalent in Java explorer in Eclipse IDE? Where does it store the folders/resources and their physical paths etc?
There are a few files involved. .project and .classpath cover the main important features, and the .settings directory includes project-specific settings (e.g. different compiler warning levels etc).
Note that unlike Visual Studio solutions, Eclipse doesn't specify each and every file to compile: it assumes that if there's a .java file underneath a source folder, it should be compiled. This makes life a lot easier in terms of diffs to project files... once set up, the project files in Eclipse rarely change, whereas they change every time someone adds or removes a file in Visual Studio :(