I have been working as a programmer for approx 15 years. I have significant experience with 3 languages. Object Pascal, C# and Python. I just took a job (like two days ago) as a project manager for a Java project that has been written with the following tech stack.
Java EE
Eclipse Helios
Tomcat
Spring
MySQL
Code is in SVN
In preperation of starting the job, I read a couple of books on Java and played around with eclipse. The language doesn't bother me at all - it's very similar to C#. What I'm really struggling with now feels more like how to get started.
I've sync'd the code from the SVN repository, but literally am not sure how to proceed. I think I'm use to having solution or a project file to "open" (like in Delphi and Visual Studio). So, do I need to create a new workspace and "import" it from the file system?
I apologies for the newbie questions. I just feel a bit lost getting started here. Maybe someone that has recently come from a Visual Studio background can sympathize with me situation! :)
Thanks in advance for your help.
Well, it depends a bit on how your company's SVN is organized. For example, do they check in the Eclipse project settings, or do they expect you to check out the code and then generate Eclipse settings? Both are common approaches.
Assuming they have project settings in SVN, you should be able to just import them. You can either directly import from SVN as a new project (using the Eclipse new project wizard), or you can check out the code from SVN with an external tool (e.g. Tortoise) and then use Eclipse's import wizard to import the project. Go to Import -> General -> Existing projects into workspace, then browse to the location of your SVN working copy, and it should automatically pick up the Eclipse project(s) there.
update following up on your comments, let me expand a bit. Say, you check out a working copy from SVN using Tortoise, for example to c:\foo. You can then import any projects in that working copy into Eclipe, using the "Import existing projects into workspace" option I mentioned above. In the import wizard, you can choose if Eclipse should copy the actual code into its workspace directory, or should leave it where it is and just keep references. This is personal taste but I usually do not let Eclipse copy the code into its own workspace. That way, I can work with the code in Eclipse (and do SVN updates/commits directly from Eclipse), but also can quite easily do operations on my svn working copy outside Eclipse.
A workspace in Eclipse can contain multiple Projects.
When you open eclipse it has you select which workspace to use, and then you should be able to import the code into eclipse as a new Project. Have you tried using the Project Wizard?
You won't find an exact equivalent of the .csproj file, the closest you get is the .project & .classpath files, between them eclipse has all the information to describe a project. If your svn checkout contains the .project file, you can directly import your project into eclipse using the Import Wizard. Else you can try creating a new project and pointing it to your svn checkout.
Related
What's the right way of working with an Eclipse Java project with GIT?
I have the plugin EGIT installed and a simple java project. I did a commit/push of this java project by using the GIT bash console. I pushed only the source files.
Is that correct? Should I use Eclipse IDE somehow to make the init, commit and push? I couldn't find how to do this in Eclipse.
How should I retrieve the project from another machine? Should I use GIT console to retrieve the project or Eclipse?
I did the procedure in several ways, but they failed.
The generic answer is: whatever works for you, works.
We have a large git repository, and users with eclipse and intellij.
Some IDE users use specific plugins, such as Egit, others simply use the "default" support that most IDEs are shipped with. Such users simply go command line, or maybe, some other 3rd party tool.
Me, personally, I only rely on the IDE to show me the history of a file, or sometimes to quickly diff to revisions. Anything else I do on the command line.
From that point of view, as said: anything that works for you, works for you. You can use eclipse to manage the aspects of a git repository, but you don't have to.
Personally, I suggest to first get a good book on git, and to then extensively study the command line tooling. You also seem to be confused between the responsibilities of your IDE, and your source code management system.
I have a laptop and a desktop. I prefer using my desktop when I am at home working with my school projects.
If I upload everything on GitHub with my laptop and I'm using Eclipse or Intellij, do I need to use the same IDE/IDEA to continue working on my projects at home?
No you don't need to use the same IDE. But be careful, different ide's have different files that should not go to git. IntelliJ produces .iml files and Eclipse produce .project files. Some other files might also exist and you may not want them to go git. So, you need to define your .gitignore files carefully and you are good to go.
Unless you decide to upload IDE specific configurations into your source control, or if you don't use something like Maven or Gradle to manage your source dependencies, it won't matter.
IDE has nothing to do with your code or the machine you use, there are many IDEs you can choose from based on your personal preferences like visual-studio, Atom, sublime, notepad++ e.t.c. sure few people associate an IDE with particular language/framework, then again there is no standard for this, everyone has there own preference.
You do not need to use same IDE. The two you mentioned has property of connecting git so you can just go as you want. Just import your projects from git.
I'm trying to figure out which files to check in to version control when using Eclipse for Android development. I have a workspace with a single project. I found this which suggested that the .metadata folder did not need to be controlled (minus the comment there about launch params, however I don't mind re-picking those again on a different machine).
If I remove the .metadata folder then open Eclipse the project is no longer shown. I searched for posts on this symptom and they suggest re-importing the project. This solution doesn't make sense here, I'm trying to check in whatever is needed so another developer can open the workspace and see the project and work on it. Having them move the project then re-import it would be a bit messy.
So which files should I be version controlling so that someone else can get the latest and be able to open the project without controlling a bunch of user specific preferences?
I have had similar experience using Eclipse for version control, and decided to quit using it because it is very annoying and buggy. Now, for git, I use SourceTree, which I prefer over eclipse version control. I think you should version control the source code folders, along with configurations, and other files you program needs to function, but never the executable files. If the other person is using Eclipse, for easiness, it is good idea to include the .classpath configuration file. If not, then the other person would need to clone the repository and make the required changes so that it works with his/her IDE.
I think I've settled on the following approach. This seems to work well so far and avoids some of the headaches mentioned in my original question.
1) each developer creates an Eclipse workspace on their machine somewhere, outside of version control; only the project directory is checked into version control - the workspace is completely uncontrolled
2) developers checkout the project directory from version control (in a different directory structure than where the workspace was created) and then use File >> Import, but they leave the "copy into workspace" unchecked.
So with the above, you can checkout from version control and work with the files right where they were checked out. There's no need to move them out then import them back in. When you import with the copy option unchecked, the workspace (which itself is not controlled) is just referencing the files where they're at on disk.
The only minor downside is that any workspace stuff has to be setup individually. Other articles mention controlling the launch params, but so far this hasn't been an issue - pretty easy to pick that once the first time you launch.
So anyway, hopefully this helps someone else :) This seems to be a reasonably smooth way to do it and avoids the issues we ran into initially.
I have a repository in which I have a simple ant project (only the src directory and the build.xml file). I did a checkout of this project in a local copy. Then I opened Eclipse, created a "Java Project from existing Ant build file" and it worked fine. I can build, clean, run, generate javadocs, etc. However, my problem is that the source files in the packages, as well as the project itself, doesn't appear to be under version control in Eclipse. I can work with it fine from Cygwin, but not from the GUI.
The odd thing is that I have several regular Java projects, on the same repository which are synced fine by Eclipse, so it's not a version issue.
When I created the projects that work, I had to go to Team->Share Project... and Eclipse told me that they were already under version control and updated its configuration. However, in this current case, this isn't working. Any suggestion please?
EDIT:
I'm using svn 1.8.
UPDATE: I tried creating a regular Java project, and this time the version control looks fine, so it appears it's an issue related only to Java Project from Existing Ant build file.
The problem is that Eclipse doesn't know your project is using Subversion as a version control tool. You did a checkout outside of Eclipse, then you set up Eclipse as if this was a non-version controlled project.
To get Eclipse to recognize the project as under Subversion, you need to let Eclipse know. This means you should have said "File->New->Project, and select SVN->Checkout Project from SVN in the new project wizard. Then, Eclipse would have checked the project out in Subversion for you, and Eclipse would understand this project is in Subversion.
Unfortunately, I am not quite familiar enough with Eclipse to know how to tell Eclipse that the current project is really under version control. The best I could come up with was:
Right-click on the project and select Team->Share
Say this is a Subversion project you want to share.
Select the Repository to use
Select the folder where you want this project, and select the current folder.
You get the following warning:
Warning: The specified folder already exists in the repository. If you continue, that folder will be checked out to the existing location. Do you want to continue?
Your project will now be "checked out" over your current project. Everything should be okay because the files you have either match what is in Subversion or are modified versions of what is in Subversion.
You will be then asked to use the Synchronized view. Check "Yes", and then switch back to the Java view. Eclipse will now know your project is under Subversion and everything should work fine.
Note the use of Shoulds and Coulds. This is my way of saying that the advise given is done on an "as is" basis and I am not responsible for any damage done by following this advice, so please don't sue me.
It's basically your standard open source license.
I prefer not to use Netbeans when I write Java code for a project,
but Netbeans is perfect for refactoring, and works nicely with svn.
The project is open-source on sourceforge, so I do not want to push other people into using Netbeans. My idea is to symlink the netbeans source direcory with the directory I consider to be the trunk of my project. Is this a good/bad idea?
EDIT: I solved it by adding adding the source directory to Netbeans instead.
Did not realize one could separate the Project from source.
http://wiki.netbeans.org/AutomaticProjects may be helpful in your case, assuming you have an Ant script. So long as NB can figure out what your script is doing as far as javac and the like are concerned, it will let the IDE open your project's sources - enough to do refactoring, run unit tests, use SVN, etc. - without adding any metadata to the source tree.