If I have an eclipse java project and I want to put my source code under control what is the proper way to do it in git?
My source files are under Worspace/ProjectName/src as typically in an eclipse set up.
Should I move the files to another directory where I will do a git init? Or should I do a git init in Worspace/ProjectName/src? I am not clear what is the recommended/usual approach.
It's better to do a git init in the workspace directory because eclipse detects the git repo in its workspace(if any)
and thereby allows you to manage(index, commit, push, pull, merge, rebase, fetch) your repo through plugin (egit) without even bothering to open the terminal.
It definitely gives you a joy and ease of working in IDE.
But still depends how you want to manage your project, there many ways..
Related
I imported a huge repository from gitlab for my lab project. It is structured like this:
project_folder [master]
JRE System Library
main_project_stuff
anthome_build_stuff
com
config
doc
...etc
Most java projects I have handled are structured like this:
project_folder
src
bin
Because there is no source folder, java will not recognize any of these folders for what they are. As a result, it can't build them and give me error messages. This only works when I drag them into a src directory that I make with eclipse, which is not ok with the lab because I can't be reorganizing files on the master branch when I eventually commit to it with git.
So how can I make eclipse recognize these as src .java files that are in packages like package: com.robot.robotComponent.java? Without actually moving them into the src directory manually?
TL;DR How do I make eclipse stop thinking of these as folders and realize they are actually packages that are stored as a folder tree?
Note: This project is not configured to be used only in eclipse, but is a general project. So I have to make my own .project and .classpath files to make it readable to eclipse.
(I am using Ubuntu 14.04 but maybe that is not relevant. I got it to work by brute force making the project_folder the actual src folder, but then there are a bunch of compile errors because the project really isn't meant to necessarily be built in eclipse? It builds from the command line using run-registry command but I want it to at least show me useful errors like when I make newbie mistakes like one too many "}" or forget to implement all functions in an interface, eclipse can fix that automatically for me with a red error message. Now however I am getting many strange errors, like it can't find project_folder.SuperComponent.java which I know is there!)
Update: I guess this needs to run a registry from ant? And then build it from an ant build.xml. I'm not sure how to get the command line arguments to work with eclipse.
If you use the Eclipse Smart Import feature, the project will be detected as a Java project (even without the .project file) and automatically configured (.classpath, etc.). Instead of using File > Import... do the following:
Clone the Git repository
In the Git Repositories view right-click the Working Tree node and choose Import Projects...
Note, the more up-to-date your Eclipse IDE is, the better the automatic detection and configuration will work.
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 think Eclipse is trying to make me miserable. A couple of hours ago, my project was working and compiling well. Suddenly that all changed. Eclipse somehow wipes out all changes I have made to my files(activity, manifest etc.) I make sure to save often but when I go to run the project, I get the error that I have a build error. I checked and there was none, so I go to close Eclipse, so I can reopen and see if the errors will go away. Instead what happens is Eclipse wipes clean all my files and I end up with a project on disk with lots of blank code files. I try to run anyway, and I get the error message below.
Failed to read the project description file (.project) for 'com.example.android.nfc.simulator.FakeTagsActivity.FakeTagsActivity'. The file has been changed on disk, and it now contains invalid information. The project will not function properly until the description file is restored to a valid state.
Anyone have an idea what in the world this is about and how I can rectify this?
I would recommend to wipe out all the eclipse related configuration files(make sure you take the backup if you have manually made some changes in those) and import the project again, by following
File -> Import... -> Existing Project into Workspace
Make sure you take the backup of whole project before doing this.
When Eclipse gets stuck in some obscure status, I usually find useful to recreate the .metadata folder in workspace directory. It is a drastic solution, but it usually works for me. After that you can reimport all your projects.
This happened to me because I had a conflict in my .project file. I opened it up in a text editor and fixed the conflict (in my case, removed from ====... to >>>branch..., as well as <<<HEAD) and then I was able to open the project in eclipse.
I was just encountering this same issue (using Zend Studio 12, which is built on Eclipse). My problem was that I was creating a project from a Remote Server, and I was just downloading everything, which also included the .project file from the old project. It wasn't showing this error until I'd closed the program and tried to open it again (which usually wasn't until the next day).
I seem to have resolved it by making sure not to download the .project when initializing the project.
If the .project file is a text file, so if you have it in version control you might want to copy it over from there.
Before you trying the following make a backup of your current project state.
Assuming you don't have an old copy, you can open it in a text editor and try to see if there is something obvious wrong.
If this fails, copy the source files of your project to a fresh location (without the eclipse configuration files) and import it as a new project into eclipse.
if you still have all of your other source (.java files, AndroidManifest.xml, resources), you might be able to get your project back by simply going to the folder containing the project, removing the .project file that you say is now empty, and then using the new project wizard to recreate the project (and .project file) for you from your existing tree of source.
from the menus, select File -> New... -> Project , and then, in the first dialog, choose Android Project from Existing Code .
if you had done anything special to the .project (reliance on specific .jar files or changes to classpath), you may have to re-do these steps after you re-create your project; but at least it should pick up the code you already have.
If all the files are empty, and you have no working Backup, I can't help. I would recommend to use proper version control in the future.
Use git or mercurial, they have nice UI integrations (see tortoisegit/tortoisehg).
To decouple the build process and library management from eclipse, take a look at maven or gradle, this might help you in future projects.
If you use git, complete the merge e.g. del the head in your androidmanifest.
I also got the Same Issue in Eclipse but the real problem is i removed the actual Source project folder from source location (from which eclipse is trying to take the project) to some other place hence my eclipse is unable to get web.xml file since it is not available. Now i changed my source project folder location to the path where eclipse is trying to search for. Issue Resolved for me.
Just delete the 'servers' folder in your workspace and try again.
Alright, so I have a web service that was created using an eclipse dynamic web project. It is currently shared on a CVS repository, but the versioning system used is irrelevant. At the moment, I have literally NEVER been able to pull this project out as is and get it working. It leads to countless errors that cannot be fixed. Every time I need to work on this webservice in a new machine I have to create an entirely new dynamic project, copy over the source files, add all the necessary libraries and make the deployment assembly work correctly again. After finally making it run I share the project as the same one, stop after a second, and then synchronize again (in a way tricking eclipse into thinking this was the shared project all along).
I feel like others must have run into this problem and found a way around it. So if you have a web service or any dynamic web project, what files do you share, and how do you successfully pull it from the repository and get it to run on another machine besides what I currently do now?
Your help is much appreciated,
-Asaf
Edit: After reading some of the responses I feel that this question is actually more specific to those who use WTP to create/test their web services. Just wanted to add the clarification.
Edit2: Let me also clarify that the other 20 or so projects not using WTP are shared just fine. I am able to pull and run them with no problem. Only web service projects are an issue.
In general, you want to check in everything that's not "derived" (generated or compiled - that's usually the contents of the bin directory or other place where your code is compiled/built into). For Eclipse Java projects, you want to include the .project, .classpath, .settings, and any other similar files that Web Tools might create for Dynamic Web projects. The Eclipse CVS client will ignore files marked as Derived so you shouldn't have to worry to much about it.
Without more detail about what kind of problems you've run into, it's not possible to guess what was causing them. My only guess is that perhaps you had different versions of Eclipse and/or the WTP (Web Tools Platform) plugins installed on the different machine. That's just a wild guess, but could explain some incompatibility when you check out the project from CVS.
Bottom line, checking in those .* files is the long recommended approach from Eclipse gurus. Maven can kind of change things, but you didn't mention it so I'm assuming you aren't using it.
I am primarily sharing my experience, may be you can find some help.
Conceptually speaking, the files which the IDE can generate itself while creating new project should not be pushed. I.e the IDE specific files should not be pushed. And everything which the IDE cannot generate on its own must be pushed.
Forexample in case of eclipse, following files should not be pushed:
.settings
build
.classpath
.project
For setting the project on new machine, first pull the files from server, and then create a project from IDE using pulled files.
EDIT: If your project has external jars/libraries, then you will have to add to the classpath manually. You could also push .classpath but that might give errors while creating a new project.
I think it's easiest to use a build system and let the IDE generate the project from your build system.
Eclipse, Netbeans, and Intellij are all pretty good at building projects from maven or ant build files. With this solution you have a simple build that is easy to setup in CI (Hudson, Bamboo, whatever) and you don't have any IDE specific files checked in. If my workspace is totally different than yours, with different versions, plugins, whatever, I'm not stuck with your project file and you're not stuck with mine. My IDE creates the project appropriate for my environment and your IDE does the same for yours.
Since you mentioned having to manually add libraries, I assume you are not using any build manager (like, maven or ant) besides ecplise.
For ecplise to handle the project properly you need the source files (*.java) in their respective directories, any resources bundled with the web service (e.g. services.xml), the ".project", ".classpath", ".settings", etc. files for eclipse. This should be enough for eclipse to generate anything else necessary to build the project.
Any files/directories that are generated by eclipse during the build process (e.g. target & bin directory, *.class, *.war) should not be checked in -- they will be generated when needed during the build.
I am thinking that, since you are adding the necessary 3rd-party jars manually, these libraries might reside in a different path between computers (e.g. if the path contains the username, it will not be transferable to another computer for a different user). To fix that you can set up the classpath using an eclipse classpath variable. In Preferences->Java->Build Path->Classpath Variables set up a varable linked to the "root" folder where the 3rd party jars a stored. Then add the libraries to the project using this new variable, not their full path. To make it work on someone else's computer, you would only need to set this classpath variable to have the build path point to the correct libraries.
It might be beneficial if you migrated your project from eclipse only to a build manager (e.g. maven) that takes care of many of these issues for you. Eclipse can build a project from the configuration of the build manager, making it easier to manage the project.
I was recently given some code that was worked on by someone other than myself, and after lots of work involving hunting down external dependencies, and editing the build.xml file to get ANT to build things in a sane way, I'd like to now get the code into a subversion repository.
The team I'm working on is rather small, but the members on the team change often. So I want people to be able to start working on this code as quickly as possible. A simple checkout from the repository, and opening the project in Netbeans to have everything building and executing properly would be ideal.
How do I achieve this when there are external dependencies that are not going to be on other team members machines?
Should I place the libraries my project uses in the VCS?
How do I instruct subversion to not track generated files such as class files and jar files?
Should binary resources that are unlikely to change such as images and sounds be placed in the VCS? If not what would be the best way to distribute them?
Thank you.
1) yes. Anything needed to build and deploy the application and isn't generated by the build process goes into version control (yah, I know the maven fanz don't like that).
2) make sure everything that's generated goes into distinct directories that you exclude from version control.
3) see 1). Same thing. Same with project documentation, release notes, etc. etc.
The biggest problem of course are directory names which will be set in your IDEs configuration files and differ between development machines.
Not just the location of the project directories, but the IDE itself, JDKs and other tools, appservers, can all be different between machines. It's a constant problem.
I usually use maven cause you can have a repository for jars and dependencies this makes life easier, but since you have already refactor your code to use ANT maybe this is not what you want, to use subversion with netbeans then you might want to add another folder for jars like libs or something and then another for the binaries like audio etc. Also check for the svn plugin for netbeans it will add the ignore to the dir and just update java files.
To add files to ignore you can use
svn propset svn:ignore -F .
or you can look for the config file in your subversion home and add something like this
global-ignores=*.classs
Hope this helps