I want to use TortoiseSVN together with Eclipse.
For now I just want to try it out.
So I use a local folder as repository.
I have installed TortoiseSVN 1.7.13.
I created a folder called 'REPOSITORY' and chose 'Create repository here' from
the context menu.
As other websites told, I installed Subclipse 1.8.22 in Eclipse.
I use the SVNKit1.7.9 as client or connector (Whatever it is called).
I had already some projects in eclipse's workspace.
From the context menu I chose 'Team->Share Project'.
That is what other websites told to do.
It did show the normal commit dialog and so on.
The projects are marked as commited but the folder 'REPOSITORY'
is still small in size.
It seems, that the projects where not copied or moved to the repository.
At work we have a server based SVN. I just want to have something like that at home.
Did I miss something?
Isn't it the purpose of the SVN repository to hold a copy of the projects?
So the commited projects should be inside the REPOSITORY, right?
Greetings
Mike
Apparently, you have to manually import the project in Eclipse into the repository created with TortoiseSVN before actually committing to it.
This other page might help you. It gives a very detailed walkthrough of how to set up exactly the kind of local system you want. In essence:
In Eclipse, delete the project but not its contents (Delete project contents on disk unchecked). This will leave the project's folder under your workspace location untouched.
Outside Eclipse, import the project folder into the repository previously created with TortoiseSVN (Right click on folder > TortoiseSVN > Import and select the URL of the repository). Once imported, you may wish to delete the project folder.
Back in Eclipse, checkout the project from TortoiseSVN's repository (e.g. Right click on Package Explorer > Import.. > SVN > Projects from SVN).
Hope that helps.
If your project's folder structure and package structure are the same, you can use Eclipse Subversive. It's just a plugin for eclipse and provides all features of TortoiseSVN
Related
I've forked a Github project, used Eclipse to clone it locally, and imported that as a general project into Eclipse.
The accompanying .project file is an Eclipse .project file with the proper "nature" and "buildCommand" xml tags.
So it seems like a valid Eclipse project. However, I'm unable to specify a run configuration or configure the build path.
When I select the Build Path popup menu item, it says "no actions available" in grayed out text. When I select "Run/Run As" from the main menu,
it shows (none applicable). I'm wondering if the problem is that the project imported completely as source folders:
There are no packages to speak of. I created another project from scratch, and created the proper source folders and packages as needed
to match the package statements in the source code. After manually importing the source from the git repo, I can build and run that project.
If the lack of packages is indeed the problem, is there a quick way in Eclipse to convert source folders to packages?
What you did is you have probably cloned the repo in Eclipse and then Imported this project through a New Project Wizard, because in GitHub there is no existing .project (and no .classpath) files.
The "New Project Wizard" will create a set of defaults for a java project (I suspect that you selected just that), but is anaware of Maven structure, so all source folders will not be recognized and you will end up having to define them on your own. Worse, you will be unaware of any special parts of the Maven build that might be configured within pom.xml.
Because this project uses Maven for building, it would be better to use M2Eclipse while importing it. Install it using Help->Install new software.
Then there are a couple of steps required to make it use all Eclipse features.
Keep your cloned copy of the repository or clone again if you want to start from scratch. Then use File->Import feature to import a maven project into the workspace. Select Exisiting Maven Projects and point to the directory containing pom.xml file in the cloned repo. This will use Maven integration in Eclipse to generate .project and .classpath files based on pom.xml contents, so you will be able to more closely mimic Maven build in Eclipse. All source folders should be properly discovered this way. Eclipse might want to install some additional integrations for Maven features that this particular project uses. Let it, if that is the case.
Now, you will have the project operational and compiling in Eclipse, but it will not be aware that it is managed by Git... This is because M2Eclipse and Git Team provider are not integrated (at least they weren't when I last checked). In order to be able to commit to the repository in Eclipse, remove the project from workspace, but without deleting contents. Then, import from Repository view using Import Projects/Import exsisting Eclipse projects. Since necessary .project file is already generated, Eclipse will autodiscover the project and will use the right configuration prepared earlier by M2Eclipse.
In the end you will have a properly configured Maven project with Git as a team provider for it.
If this is a project meant to be built by Maven that contains a pom.xml file, install M2E before importing the project from your local cloned repository. It will handle this.
Right click at root of project select properties, in the sources tab add the folder "src/main/java" as source folder
Other way is to configure facet as java
Just by a mistake I had deleted a spring project in STS.To use it back I borrowed the same project from my friend in zip format but when I tried to import it says
Some projects cannot be imported because they already exist in the workspace
Following is the way I tried to import
file->import->general->existing projects into worspace->select archive file
and after browse when I select the zip project
Some projects cannot be imported because they already exist in the workspace
and the finish button and next button are in disabled state.Please help me
The workspace in STS/Eclipse is not automatically the same as the file structure that you have on disc in your workspace directory. You can have projects in this workspace folder or somewhere else on disc.
To get them into your project explorer (and access them from inside STS/Eclipse), you need to import them (Import Existing Projects into Workspace). Then you can select the folder where those projects are located in. In case you have those projects already in your workspace folder on disc, you can choose the workspace folder as root folder in the wizard. It will show all the projects that exist on disc in that folder and grey those out that are already imported/referenced in your workspace in Eclipse.
Make sure it is really not in workspace, also if there aren't any other projects with the same name. If not, just delete the .metadata folder or create a new workspace.
Check if you still have the project in folder of the workspace on disk. You may have deleted in STS, without checking 'Delete on disk'. So, the project may be still there in the workspace folder though its deleted in STS.
I get this issue from time to time. Usually I just open a new workspace but sounds like you don't want to loose other projects.
I simply open the.project file in my project and change the name of the project in name tag.
Good Luck!
Probably whey you 'accidentally deleted' your project, you only deleted it from the Eclipse workspace, but not from the actual workspace folder on your hard-drive (as other people pointed out, Eclipse can arbitrarily map workspace projects to files on disk, so it is possible for a project to be 'deleted' from your Eclipse workspace but still exist on disk.
The good news is the files you deleted are actually still there.
Instead of importing your project from a zip, you may just want to import those files from the workspace folder back into your Eclipse workspace.
Generally this kind of problems not occurred you can go to Project option and clean and than restart STS.
May be STS is not synched with the latest configured project.
When you launch Spring Tools Suite, it will ask you to Select directory as workspace as below:
If the directory you selected here (i.e., workspace directory) is the same as the directory where the project that you are going to import resides, then you will get Some projects cannot be imported because they already exist in the workspace.
Therefore, to solve the issue,
Close Spring Tool Suite
Create a new directory
Launch Spring Tool Suite again
And, select that as your workspace
Launch the application and you would be able to import as you mentioned in your question
It solved my problem.
Hope it helps..
Happy Coding!!
the problem is that when you delete a project maybe sts only close it.
Try View Menu --> uncheck closed projects
Now you will see all closed project, simply delete it.
To date I have done all my management of SVN via TortoiseSVN. I would like to learn a bit more about how to use Eclipse/Subclipse. The main thing I am trying to figure out is the update. The issue is this that I need to update more then what is in the Eclipse project. Here is what things look like in Subversion:
trunk
Clients
EclipseProjects
Project1
Project2
Project3
Project4
Project5
Project6
Project7
JDK
SQLScripts
The issue is that while the Eclipse workspace only contains a few of the Projects# directories, to run the application one must drop to the command line and run it and the application uses ALL the projects. I also want to be updated the other folders that are at the same level as EclipseProject: Clients, JDK, SQLScripts.
Currently with TortoiseSVN, I simply go to the trunk and do an update. How can I do that within Eclipse when the trunk is not part of the workspace?
Subclipse can only operate on what is loaded into your Eclipse workspace. You have a few options here, not in particular order:
Checkout each project separately using Subclipse. Each project will be its own SVN working copy.
Checkout "trunk" using Subclipse. Just create an Eclipse "simple project" for this checkout. The individual Eclipse projects can then be Imported into your workspace. So projects will show up twice. Once as themselves, and once as a folder beneath the trunk project. If you want to update them all at once, you can take the Update on the trunk project. But you can still take actions on individual projects too.
Same as #2, but do the checkout of trunk using TortoiseSVN. And use TortoiseSVN when you update everything. You will need to do Team > Refresh to let Subclipse know you did something in TortoiseSVN. I would still use Subclipse and import those projects into SVN. Even if you do all your commit and update actions using TortoiseSVN, there are advantage inside Eclipse to having Subclipse installed and TortoiseSVN and Subclipse can both use the same working copy fine as long as they share the same SVN version.
I use all 3 of these approaches in different scenarios.
It's actually quite simple. All you'll have to do is check out the repository using Eclipse check out tool.
In Eclipse, open Window > Show View > Other..., select SVN Repositories. Click New Repository Location, enter your SVN url, username and password. Once the repository added, do Checkout and voilà.
A little advice based on my experience : do not check out the whole trunk! Because then you will have one big folder trunk in the Project Explorer and it's frustrating open three folders trunk > EclipseProjects > ProjectXYZ everytime to actually get to your project. It's also not very visually pleasant and ordered. What I recommend is checkout the ProjectX folders, Clients, JDK and SQL Scripts folders separately. You'll have a nice flat hierarchy like this :
Clients
Project1
Project2
Project3
Project4
Project5
Project6
Project7
JDK
SQLScripts
Remember that using this technique, anything outside the scope of these folders (e.g. trunk/EclipseProjects/log.txt) won't be taken into account. If you have anything like that, you can always put it in the separate subfolder of trunk and treat it the same way as others.
There are quite a few questions on this topic, but there are no satisfactory answers unitl now, e.g this.
I'm using Eclipse Kepler (20130529-2219), with ME2 (1.4.0.20130601-0317) and Eclipse Git Team Provider (Java implementation of GIT 3.0.0.201306040240-rc3). So I started with great expectations after reading how great git is.
Firstly, I opened an existing project and removed all the .svn rubbish and commited it to a local git repository. Perfect - now it is time to push the files to a remote repository. After having some problems creating the known_hosts file on Windows the push was successful.
Now the problems started: I wanted to pull changes for the repository, but "... not configured for pull". OK, here it was discussed that this is a common issue, and you have to delete the project and then reimport it from a remote server to allow pulling.
Hence, I set up everything again and pulled the project. Until now I was always told that .project files should not be commit to version control, therefore I didn't include them. The "import -> import from git -> local"-menu does not recognize the files in the repo as a Java project. I can therefore only import the project as a general project or use the project wizzard and set up a new Maven project, which is stupid because all information already exists in the POM.xml. If I do a plain project import, Eclipse does not know that it is a Java or Maven project and throws tonnes of errors.
Question (skip detailed problem): Is there some less awkward way to import a Maven and Java project from a remote git repo when no .project file exists?
Easiest solution: do include the .project (as in this answer) in your git repo.
And do include also the .classpath, since you now can reference relative paths in it, instead of absolute path: see ".classpath and .project - check into version control or not?"
I found an alternative to keep .project file out of Git version control. As you said the pom.xml file should be enough for IDEs to figure out that a maven project it´s in place (and it is).
Let's say you have pushed your project into Git (without .project file) and now you want to import that project into Eclipse.
Make sure you have the Git repo added into Git perspective
Go to J2EE Perspective and double click on an empty space on Navigation View. Import -> Existing Maven Projects
Browse to your Git repo location and voila! Eclipse should catch all pom.xml files and determinate they are independent Maven projects
In my case this worked to pull multiple projects located at one same Git repo, each of them only storing pom.xml file (and no .project at all)
I have two eclipse project. The second one depends on the first one. When I try to rename a java class of the first project (using the rename function on the java file on the project explorer) it correctly do the refactor of that project but it doesn't changes anything on the project that depends on it.
Is there a way in eclipse to tell the renaming function to act even on the projects that are linked to the refactored one? Thanks for help.
My Eclipse version is Juno.
Update:
Forgot to mention that the projects are linked to an SVN repository. Maybe it could be relevant.
Update 2:
I add more details after mliebelt request of clarification.
My Eclipse version is Juno, Eclipse Java EE IDE for Web Developers, build id: 20120614-1722.
I've installed some plugins: subclipse, JRebel, m2e, Eclipse Web Tool Platform.
The second project is linked to the first one as a project dependency in eclipse. I have added the first project in the project tab of Java Build Path. Everything seems to work fine, even the renaming function.
Then, I tried to put the two project in two different SVN repositories. I created two repositories on the SVN server and I installed on my machine the client tortoiseSVN and the eclipse plugin subclipse. Since I didn't succeeded in importing the projects on the server directly from eclipse, I copied the projects' folders in a different location and I removed the projects from eclipse. I used tortoiseSVN to import the projects, each one on a repository with the same name of the project, and than I imported the project back to eclipse. To do that I used the eclipse "import existent project into workspace" function with the "copy project into workspace" option selected. Everything seems to work but not the renaming function.
It does work (for me), so here is what I have done to reproduce the behavior. I hope that this helps to find the error.
Create two projects, and make the second dependent on the first.
Create some source code, so that you can refactor it. Ensure that a class in Test2 is dependent on a class in Test.
Select from the context menu of the method you want to rename. Enter there a new name for the method, only then is the Preview option available. Ensure that Update references is checked.
Press the button Preview to see which classes will be changed by the refactoring.
As you can see, it works for me. Please check what is different in your context:
Define dependency different
Use different refactoring (which possibly contains a bug)
... ?
I then added the two projects to a (local) repository (I use the plugin Subversive, it that matters), and have retried the refactoring, and it works the same way. What is that "it does not work if the projects are in SVN"? The projects have to be in Eclipse, refactoring cannot be done on the Subversion repository directly.
I have made another attempt to reproduce the error, but could not. Here is what has worked for me (no screenshots included):
Installed Java EE from Eclipse (version Indigo)
Installed Subclipse 1.8 from the Eclipse Marketplace.
Defined the 2 projects as before.
Added the projects to the different Subversion repositories by using Team > Share Project...> SVN > select the repository location > Finish
I have then deleted the 2 projects, and instantiated them inside the workspace by doing the following steps:
Go to the SVN Repository Exploring perspective.
Open in the view SVN Repositories your repository locations, and select for each project from the menu Checkout....
The projects will be reinstantiated insided the workspace, and the dependency between the 2 is not lost.
After that, I am able to rename a method as I have shown above.
The problem in my workflow, described in Update2, was that, when I imported back the projects to eclipse, I used "import existent project into workspace" function.
I had to use SVN Checkout Projects from SVN instead, choosing the repositories I previously created.